CSM VRF Lite OSPF and IPSEC/GRE

We have a pretty complex vpn configuration. Its a site-to-site VRF-Lite GRE/IPSEC VPN that would be considered a point-to-point, each router is connected to two peers in a ring.
CSM complains about discovering this VPN configuration due to the VRF and the fact that OSPF with multiple OSPF processes is not supported.
My question is, can we still monitor the tunnels. We'd like to monitor the tunnels, but that seems impossible unless we can get CSM to see the tunnels which it currently is not.

VRF Lite and MPLS-VPN act independently so they can work independently. And there is no specific need for mapping. If link is for VRF A on PE so you can make it part of vrf A in CE as well. Both VRFs are independent of each other.
http://www.cisco.com/en/US/products/hw/switches/ps4324/products_configuration_guide_chapter09186a00801cddd9.html#1045190
THis document is for 4500 but logic holds the same.

Similar Messages

VRF-lite, NAT and route-leaking

Hello, community. I'm trying to reproduce setup with two customers (R1 and R2), PE router (R3) and common services (R4).
Here is configuration:
R1:
interface Loopback0
ip address 10.10.1.1 255.255.255.255
interface FastEthernet1/0
ip address 192.168.15.1 255.255.255.0
ip route 0.0.0.0 0.0.0.0 192.168.15.5
R2:
interface Loopback0
ip address 10.10.2.2 255.255.255.255
interface FastEthernet1/0
ip address 192.168.16.1 255.255.255.192
ip route 0.0.0.0 0.0.0.0 192.168.16.5
R3:
ip vrf VRF1
rd 1:1
route-target export 1:1
route-target import 1:1
ip vrf VRF2
rd 2:2
route-target export 2:2
route-target import 2:2
interface FastEthernet0/0
description R1
ip vrf forwarding VRF1
ip address 192.168.15.5 255.255.255.192
ip nat inside
ip virtual-reassembly
interface FastEthernet0/1
description R2
ip vrf forwarding VRF2
ip address 192.168.16.5 255.255.255.192
ip nat inside
ip virtual-reassembly
interface FastEthernet1/0
description R4
ip address 1.1.1.1 255.255.255.0
ip nat outside
ip virtual-reassembly
ip route 0.0.0.0 0.0.0.0 1.1.1.2
ip route vrf VRF1 0.0.0.0 0.0.0.0 FastEthernet1/0 1.1.1.2 global
ip route vrf VRF1 10.10.0.0 255.255.0.0 192.168.15.1
ip route vrf VRF2 0.0.0.0 0.0.0.0 FastEthernet1/0 1.1.1.2 global
ip route vrf VRF2 10.10.0.0 255.255.0.0 192.168.16.1
ip nat inside source list 15 interface FastEthernet1/0 vrf VRF1 overload
ip nat inside source list 16 interface FastEthernet1/0 vrf VRF2 overload
access-list 15 permit 192.0.0.0 0.255.255.255
access-list 15 permit 10.10.0.0 0.0.255.255
access-list 16 permit 192.0.0.0 0.255.255.255
access-list 16 permit 10.10.0.0 0.0.255.255
R4:
interface Loopback0
ip address 10.10.10.10 255.255.255.255
interface FastEthernet0/0
ip address 1.1.1.2 255.255.255.0
ip route 0.0.0.0 0.0.0.0 1.1.1.1
The configuration is not operational.
r1#ping 192.168.15.5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.15.5, timeout is 2 seconds:
Success rate is 100 percent (5/5), round-trip min/avg/max = 68/89/116 ms
r1#ping 192.168.15.5 source l0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.15.5, timeout is 2 seconds:
Packet sent with a source address of 10.10.1.1
Success rate is 100 percent (5/5), round-trip min/avg/max = 68/86/92 ms
r1#ping 1.1.1.1 source l0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 10.10.1.1
Success rate is 80 percent (4/5), round-trip min/avg/max = 292/357/400 ms
r1#ping 1.1.1.2 source l0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.2, timeout is 2 seconds:
Packet sent with a source address of 10.10.1.1
Success rate is 80 percent (4/5), round-trip min/avg/max = 160/187/216 ms
r1#ping 10.10.10.10 source l0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.10, timeout is 2 seconds:
Packet sent with a source address of 10.10.1.1
Success rate is 0 percent (0/5)
I can't ping R4's loopback address ("shared resource" or also known as "common service")
The same is with R2 ( second customer).
But I can still ping R4's loopback from R3:
R3#ping 10.10.10.10
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.10, timeout is 2 seconds:
Success rate is 100 percent (5/5), round-trip min/avg/max = 40/88/116 ms
This is routing table on R3:
R3#sh ip route | begin Gateway
Gateway of last resort is 1.1.1.2 to network 0.0.0.0
     1.0.0.0/24 is subnetted, 1 subnets
C       1.1.1.0 is directly connected, FastEthernet1/0
S*   0.0.0.0/0 [1/0] via 1.1.1.2
R3#sh ip route vrf VRF1 | begin Gateway
Gateway of last resort is 1.1.1.2 to network 0.0.0.0
     192.168.15.0/26 is subnetted, 1 subnets
C       192.168.15.0 is directly connected, FastEthernet0/0
     10.0.0.0/16 is subnetted, 1 subnets
S       10.10.0.0 [1/0] via 192.168.15.1
S*   0.0.0.0/0 [1/0] via 1.1.1.2, FastEthernet1/0
R3#sh ip route vrf VRF2 | begin Gateway
Gateway of last resort is 1.1.1.2 to network 0.0.0.0
     10.0.0.0/16 is subnetted, 1 subnets
S       10.10.0.0 [1/0] via 192.168.16.1
     192.168.16.0/26 is subnetted, 1 subnets
C       192.168.16.0 is directly connected, FastEthernet0/1
S*   0.0.0.0/0 [1/0] via 1.1.1.2, FastEthernet1/0
So the question is what is the problem cause? How to troubleshoot? What is the troubleshooting steps?

Hi Eugene Khabarov
The problem here is that at the PE we have the static route for the Major Subnet 10.10.0.0/16 pointing back to the CEs of which the destination ping IP 10.10.10.10 is part of.
We need to remove the Major X /16 route from PE and configure explicit X /32 route for the CE Loopback to make this work
no ip route vrf VRF1 10.10.0.0 255.255.0.0 192.168.15.1
ip route vrf VRF1 10.10.1.1 255.255.0.0 192.168.15.1
no ip route vrf VRF2 10.10.0.0 255.255.0.0 192.168.16.1
ip route vrf VRF2 10.10.2.2 255.255.0.0 192.168.16.1
Hope this helps to answer your query.
Regards
Varma

AAA Authentication and VRF-Lite

Hi!
I've run into a strange problem, when using AAA Radius authentication and VRF-Lite.
The setting is as follows. A /31 linknet is setup between PE and CE (7206/g1 and C1812), where PE sub-if is a part of an MPLS VPN, and CE uses VRF-Lite to keep the local services seperated (where more than one VPN is used..).
Access to the CE, via telnet, console etc, will be authenticated by our RADIUS servers, based on the following setup:
--> Config Begins <---
aaa new-model
aa group server radius radius-auth
server x.x.4.23 auth-port 1645 acct-port 1646
server x.x.7.139 auth-port 1645 acct-port 1646
aaa authentication login default group radius-auth local
aaa authentication enable default group radius-auth enable
radius-server host x.x.4.23 auth-port 1645 acct-port 1646 key <key>
radius-server host x.x.7.139 auth-port 1645 acct-port 1646 key <key>
ip radius source-interface <outside-if> vrf 10
---> Config Ends <---
The VRF-Lite instance is configured like this:
---> Config Begins <---
ip vrf 10
rd 65001:10
---> Config Ends <---
Now - if I remove the VRF-Lite setup, and use global routing on the CE (which is okey for a single-vpn setup), the AAA/RADIUS authentication works just fine. When I enable "ip vrf forwarding 10" on the outside and inside interface, the AAA/RADIUS service is unable to reach the two defined servers.
I compared the routing table when using VRF-Lite and global routing, and they are identical. All routes are imported via BGP correctly, and the service as a whole works without problems, in other words, the AAA/RADIUS part is the only service not working.

Just wanted to help future people as some of the answers I found here were confusing.
This is all you need from the AAA perspective:
aaa new-model
aaa group server radius RADIUS-VRF-X
server-private 192.168.1.10 auth-port 1812 acct-port 1813 key 7 003632222D6E3839240475
ip vrf forwarding X
aaa authentication login default group RADIUS-VRF-X local
aaa authorization exec default group X local if-authenticated
Per VRF AAA reference:
http://www.cisco.com/c/en/us/td/docs/ios/12_2/12_2b/12_2b4/feature/guide/12b_perv.html#wp1024168

887 ipsec+gre+ospf models and licenses

I'm choosing router for brunch office among this models - 887VA-SEC-K9 or 887VA-K9. I want this router to can IPSEC site-to-site, GRE-tunnels and OSPF. I read the datasheet but I haven't understood several things about this model so I can't choose a right model. The datasheet says that default software is Advanced Security Feature Set for all 887 routers which supports IPSEC and GRE. Then I don't understand what are differences between 887VA-SEC-K9 or 887VA-K9? What does the word "SEC" mean? The second things aren't understood - I want the router to support OSPF. The Advanced IP Services can do it but there is two options too - SL-880-AIS and L-SL-800-SEC-K9. What are differences between them?
What should I choose to implement IPSEC-GRE-OSPF among this models and licenses?

The ASR1004 router we can only send packets with a maximum MTU size of 1438 Bytes over the encrypted tunnel.

Sourced Based VRFs and IPSEC

Hi All,
I have 2 questions.
1) Does Cisco Router 7600 with SUP720 3BXL supports VRF Selection based on Source IP Address [Layer 3 VPNs]?
2) We have various clients reaching a Router and we want to forward them to a their company's VRFs, based on their source address (Given by Radius or Statically). Now, Ideally, we want to give to the customer's H.Q. the option to connect to this router using Leased Lines (or Frame Relays) or by using IPSEC (over the internet). Is this possible? Can traffic from an access server arrive to an interface and based on the source, the user will be either forwarded to a VRF or an IPSEC?
Regards.
Regards.

Hello,
a solution to xour problem could be to have a VRF aware access server and place the customers into their respective VRF right away (the feature is called Multi-VRF aka VRF-lite). IPSec and Dialer interfaces are possible. Based on authentication you could define the VRF and by having a dot1Q trunk to the 7600 which operates as the MPLS PE.
A second option is to have the trunk to the 7600, VLANs in different VRFs and to do PBR into different VLANs on the CE router/access server.
Hope this helps! please rate all posts.
Regards, Martin

VRF lite and MPLS VRFs

We have a CE router connected to PE router. The CE router is connected via 2 links to the PE router, because we need to create two VRFs on the PE for the traffic coming from the CE to separate the traffic, so we have one vrf per link. We are running OSPF between CE and PE.. Now we need to further separate the traffic up to the CE, so Im thinking of using the VRF lite on the CE.. Can MPLS work with the VRF lite, and how to map the VRF lite VRFs on the CE to the MPLS VPN on the PE?
Is there any config examples?
Thanks in advance

VRF Lite and MPLS-VPN act independently so they can work independently. And there is no specific need for mapping. If link is for VRF A on PE so you can make it part of vrf A in CE as well. Both VRFs are independent of each other.
http://www.cisco.com/en/US/products/hw/switches/ps4324/products_configuration_guide_chapter09186a00801cddd9.html#1045190
THis document is for 4500 but logic holds the same.

Running vrf-lite and dhcp server see 0.0.0.0 as giaddr

Im running vrf-lite and our dhcp server see only 0.0.0.0. Im able to ping vlan10, and see the dhcp request. Running on a 2811. I have limited access to device. Do I need to turn on Dhcp-relay? Verifing ip forward-protocol. Do i need to add " vrf WISP to my helper-address? The interface it sends Dhcp request is also within the vrf. The dhcp scope is part of Vlan10 subnet
int vlan 10
ip vrf forward WISP
ip add x.x.x.x s.s.s.192
ip helper-address x.x.x.x

Yes and no. It uses another interface thats within the same vrf Wisp. On the other end of the vrf it is forwarded to our global dhcp server. in bold is where the unicast packet are going using the defaultroute
int fast0/0.1
encap dot1q 1
ip vrf forwarding WISP
ip add 172.16.6.2 255.255.255.252
int vlan 10
ip vrf forward WISP
ip add 66.223.195.129 255.255.255.192
ip helper-address 208.138.129.49
ip route vrf WISP 0.0.0.0 0.0.0.0 172.16.6.1

VRF LITE + IPSEC

Hi this conf is VRF LITE + IPSEC. During the test we see the packets don't come back (from a different vrf) to interface with tunnel. We ping from one PC behind the tunnel ip sec (inside the vrf A) to router inside the vrf B (on the same PE). The packets seem to re-enter in the tunnel (by debug ip packet) but they really do not re-enter in the tunnel.
ip vrf B
rd 100:100
route-target export 100:100
route-target import 100:100
route-target import 100:17
ip vrf A
rd 100:17
route-target export 100:17
route-target import 100:17
route-target import 100:100
crypto keyring itea-peer vrf A
pre-shared-key address 172.16.254.110 key pat55200itea
crypto isakmp policy 1
hash md5
authentication pre-share
lifetime 3600
no crypto isakmp ccm
crypto isakmp profile itea-peer
vrf A
keyring itea-peer
match identity address 172.16.254.110 255.255.255.255 A
local-address Serial3/0
crypto ipsec transform-set InfoTn esp-des esp-md5-hmac
crypto map Itea 10 ipsec-isakmp
description ITEA
set peer 172.16.254.110
set transform-set InfoTn
set isakmp-profile itea-peer
match address Serv_Itea
ip access-list extended Serv_Itea
permit ip any 193.43.34.0 0.0.0.255 log
interface Serial3/0
ip vrf forwarding A
ip address 172.19.7.17 255.255.255.252
serial restart-delay 0
crypto map Itea
end
interface GigabitEthernet0/3
ip vrf forwarding B
ip address 2.2.2.1 255.255.255.252
duplex auto
speed auto
media-type rj45
no negotiation auto
end

so you can see ACS match:
Flusso1-New#sh access-lists Serv_Itea
Extended IP access list Serv_Itea
20 permit ip any 193.43.34.0 0.0.0.255 log (4138 matches)
Flusso1-New#
Aug 1 10:51:48: IP: tableid=6, s=193.43.34.10 (Serial3/0), d=2.2.2.1 (GigabitEthernet0/3), routed via RIB
Aug 1 10:51:48: IP: s=193.43.34.10 (Serial3/0), d=2.2.2.1, len 100, rcvd 4
Aug 1 10:51:48: IP: tableid=6, s=2.2.2.1 (local), d=193.43.34.10 (Serial3/0), routed via FIB
Aug 1 10:51:48: IP: s=2.2.2.1 (local), d=193.43.34.10 (Serial3/0), len 100, sending
Flusso1-New#sh access-lists Serv_Itea
Extended IP access list Serv_Itea
20 permit ip any 193.43.34.0 0.0.0.255 log (4139 matches)
Flusso1-New#

Question to understand VRF and VRF-lite features

Hi,
when I look at METRO switches Feature list I see that most of them support only "VRF-Lite".
Does it mean that they can't work with MPLS lables and can't be placed as PE devices in cases where we need VPN services or any kinf of "Lable-switching" services?
Which role then does those METRO switches play in a network?

Hello Konstantin,
VRF lite is a subset of MPLS L3 VPN features missing MPLS forwarding plane capabilities.
An end to end dedicated IP path is needed for each VRF, practically a VRF-lite capable device should be connected to a fully capable PE node by using a L2 trunk and dedicating at least two Vlan and two SVI for each VRF: one towards customer and one towards PE.
you get a multi VRF CE that can be shared by multiple customers
a fully capable PE node uses N+1 links for N VRFs, a multiVRF CE requires 2*N logical interfaces for N VRFs
only one MPLS enabled backbone link is needed for handling traffic of multiple VRFs in a fully capable PE node.
in metro ethernet VRF lite multi VRF CE are used as feeders sort of satellite of PE nodes to provide an access layer to customers
Hope to help
Giuseppe

Hi all, need advice on OSPF and private vlans

Hi all.
I have a project to complete and need some help on the possible solution I can use.
Basically we have ospf area 0 and the users in question are in ospf area 7 and is a stub.
I need to route the traffic from these users out through area 0 through 3 core devices, onto an external firewall interface to be placed onto the vpn that sits on it. The firewall is not included in the ospf domain.
My thinking was that the firewall has a default route back into the ospf domain so dont need to worry about traffic coming in, however my job is to segregate these users and take them out of our core network and place them onto an external network via this vpn.
Not sure how to achieve this apart from static routing redistributed but surely this does not seperate their traffic only points the route to ospf?!
I was thinking I might have to use private vlans or policy routing but when I try policy routing the policy gets ignored due to normal forwarding.
Any help and advice would be greatly appreciated.
Cheers
Steve

Steve
Thanks, that helps.
GRE is defintely out because apart from the 6500 GRE tunneling is not supported on the Cisco switches.
It's good that area 7 is only for these users and not mixed up with other users.
So if i understand correcty the 4500 interface connecting to the 6500 is in area 0 and the interface connecting to the 3550 is in area.
Or is the 3550 connected to both areas and the 4500 totally in area 0 ?
Can you confirm the above ?
In terms of keeping them separate there are 2 possible choices. You can either -
1) use VRF-LIte, although i'm not sure whether the HP switch would support this. With VRF-Lite you are in effect creating virtual devices on the same physical device. This means each virtual device has it's own routing and forwarding table so it is quite secure because you would only populate the routing table with the routes needed so there would be no way for users to jump to thes rest of your networks.
The downside is that is can become quite complex to configure. If the 4500 is only used to connect are 7 to area 0 then that would not be a problem but the connection from the 6500 to the HP could and i don't even know whether the HP supports VRF-Lite functionality let alone how to configure it on that switch.
But it would, at least from the 4500 to 6500 to HP provide complete separation in terms of routing and forwarding. Once it got to the HP it wouldn't but that might not be an issue.
2) Use PBR (possibly together with acls). This is easier to configure ie. you configure PBR on the 4500 and the 6500 to get the traffic to the HP switch. But you do not get the actual separation you get with VRF-Lite ie. the traffic simply overrides the existing routing tables.
The other thing to bear in mind with PBR is that you also have to configure the return traffic as well so each device would need multiple PBR configs.
Again i don't know whether the HP supports PBR but it may not be an issue depending on what the routing is on the HP.
You could also use a combination of the above ie VRF-Lite between the Cisco switches and then PBR for the last hop to the HP device.
I should say i don't have a huge amount of experience with VRF-Lite but that should not necessarily stop you using it if it is what you need. There are lots of other people on here so i'm sure there will be other people who can help if i can't.
It still depends on how much separation is required. VRF-Lite is definitely seen as a way to separate traffic running across a shared infrastructure, PBR is not really seen in the same way. So it may well be worth going back to find out exactly what "segregating" user traffic means.
I don't want to confuse the issue but it's still not entirely clear what the actual requirement is.
Jon

Vrf-lite (extranet solution)

Hi,
I have a requirement of an extranet solution (ASP model) where many customer will be connected to a central site. The spoke sites do not talk to each other, not even through the central site. One option is to use 1 VRF at the central site and import routes from all other spokes sites (different RD and RT at the spopke sites). This has been rules out. so now my other alternative is to use multiple vrf on a single access link (ethernet in this case) between the CE and PE. I was thinking of using vrf-lite at the central site, but few concepts I am not clear about.
1) can i get away without using vrf-lite on the central site. PE configures individual vrf for each 1.q interface, but CE just uses 1.q without any vrf. For start I am going to have only two/three sites, so I can either map the subinterface to a separate LAN port or i could do .1q on a single LAN int and map it to the WAN subinterface. Maybe this is not the best solution,but I do not want to go for an unnecessary solution.
2) what are the advantages and disadvantages of using vrf-lite vs no vrf (if it is possible) in this scenario.
Attached is a diagram.
thanks,
Arana

Jon,
I am back with some reading on vrf lite. I am pasting a sample configure that I picked up from another post. I noticed that there is no 'network' statement or 'redistribute static'. My questions:
1) If I am running BGP with PE, what is the normal pratice to advertise my routers per vrf?
2) In the LAN do I run separate OSPF or EIGRP instances per VRF (per subinterface)? what is the best way?
3) If I have static route to other LAN routers then I will be using 'redistribute static' right? Do I have to be specific about which static route I should redistribute to that vrf. If not how does the router know which static route to redistribute to which vrf.
I have attached a diagram. The below sample does not map to my diagram.
frame-relay switching
interface serial0/0/0
encapsulation frame-relay
interface serial0/0/0.1 point-to-point
ip vrf forwarding A
ip address x.x.x.x x.x.x.x
frame-relay interface-dlci 100
interface serial0/0/0
encapsulation frame-relay
interface serial0/0/0.2 point-to-point
ip vrf forwarding B
ip address y.y.y.y y.y.y.y
frame-relay interface-dlci 101
And So on for further interfaces.
router bgp 1
no synchronization
bgp log-neighbor-changes
no auto-summary
address-family ipv4 vrf A
neighbor x.x.x.x remote-as x
no synchronization
exit-address-family
address-family ipv4 vrf B
neighbor y.y.y.y remote-as y
no synchronization
exit-address-family
Vikram,
As long as we all can share/learn/solve problems, it is perfectly fine. I don't think I qualify to give you any advise but here is what I have found in another post that might be of interest to you.
In your post you mentioned that you do not think you can run MP-BGP between the two switch through the FW. In another post I had got an indication that you can run LDP between two PE's using GRE tunnel. In your scenario you are going throuhg a FW and in that particular post the PEs are separated by a third service provider. So if you are open to explore this might be a solution for you.
Hope this piece of information helps.
thanks,
Arana

VRF Lite Issues

Hey people. I'm trying to solve a small VRF Lite project I've been working on. Router has one public interface. I have GRE tunnels going to a VTI. I also created a second tunnel VTI and put it in a VRF so that I could have one plain GRE tunnel and also a second GRE tunnel that supports IPSEC. I can't seem to figure out how to route packets in and out of the VRF and global table. From a tunnel established on the VRF, I would like to ping one of the global table peers networks (or even a loopback interface on the router itself). Below is my config. Any help is appreciated.
ip vrf IPSEC-Customers
rd 65000:1
route-target export 65000:1
route-target import 65000:1
interface Tunnel0
bandwidth 100000
bandwidth inherit
ip address 10.1.1.1 255.255.255.0
no ip redirects
ip mtu 1500
ip nat inside
ip nhrp map multicast dynamic
ip nhrp network-id 1011
ip nhrp holdtime 30
ip nhrp registration timeout 30
ip virtual-reassembly
ip tcp adjust-mss 1400
load-interval 30
qos pre-classify
tunnel source 204.12.X.X
tunnel mode gre multipoint
tunnel bandwidth transmit 100000
tunnel bandwidth receive 100000
interface Tunnel1
bandwidth 10000
bandwidth inherit
ip vrf forwarding IPSEC-Customers
ip address 10.1.2.1 255.255.255.0
no ip redirects
ip mtu 1500
ip nhrp map multicast dynamic
ip nhrp network-id 1012
ip nhrp holdtime 30
ip nhrp registration timeout 30
ip tcp adjust-mss 1400
load-interval 30
qos pre-classify
tunnel source FastEthernet0/0
tunnel mode gre multipoint
tunnel key 50
tunnel bandwidth transmit 100000
tunnel bandwidth receive 100000
tunnel protection ipsec profile DMVPN1
interface FastEthernet0/0
bandwidth 10000
ip address 204.12.X.X 255.255.2X.X
ip access-group Outside_In in
ip nbar protocol-discovery
ip flow ingress
ip flow egress
ip nat outside
ip virtual-reassembly
load-interval 30
duplex auto
speed auto
router bgp 65000
no synchronization
bgp log-neighbor-changes
no auto-summary
address-family ipv4 vrf IPSEC-Customers
redistribute connected
redistribute static
no synchronization
exit-address-family
ip route vrf IPSEC-Customers 10.2.7.0 255.255.255.0 10.1.2.3 name Test

Hello,
The tunnel source and destination must be in the same vrf for this to work. In another case you can use a tunnel to ride over a vrf if required.
So your global table would then become a vrf, i am not sure if we can do this with the global table... :-/ Using your example below:
ip vrf IPSEC-Customers
rd 65000:1
route-target export 65000:1
route-target import 65000:1
ip vrf GLOBAL
rd 1:1
interface Tunnel0
ip vrf forwarding GLOBAL
bandwidth 100000
bandwidth inherit
ip address 10.1.1.1 255.255.255.0
no ip redirects
ip mtu 1500
ip nat inside
ip nhrp map multicast dynamic
ip nhrp network-id 1011
ip nhrp holdtime 30
ip nhrp registration timeout 30
ip virtual-reassembly
ip tcp adjust-mss 1400
load-interval 30
qos pre-classify
tunnel source 204.12.X.X
tunnel mode gre multipoint
tunnel bandwidth transmit 100000
tunnel bandwidth receive 100000
interface Tunnel1
bandwidth 10000
bandwidth inherit
ip vrf forwarding IPSEC-Customers
ip address 10.1.2.1 255.255.255.0
no ip redirects
ip mtu 1500
ip nhrp map multicast dynamic
ip nhrp network-id 1012
ip nhrp holdtime 30
ip nhrp registration timeout 30
ip tcp adjust-mss 1400
load-interval 30
qos pre-classify
tunnel source FastEthernet0/0
tunnel mode gre multipoint
tunnel key 50
tunnel bandwidth transmit 100000
tunnel bandwidth receive 100000
tunnel protection ipsec profile DMVPN1
tunnel vrf GLOBAL
interface FastEthernet0/0
ip vrf forwarding GLOBAL
bandwidth 10000
ip address 204.12.X.X 255.255.2X.X
ip access-group Outside_In in
ip nbar protocol-discovery
ip flow ingress
ip flow egress
ip nat outside
ip virtual-reassembly
load-interval 30
duplex auto
speed auto
I haven't tested this myself but I have come across this in my studies. In theory this should work.
hope this helps
Bilal (CCIE #45032)

Using VRF-Lite in 6509 as Really Expensive IPS ByPass

I have an IPS (Intrustion Prevention) unit that is causing me some problems with some of my servers in my ServerFarm. I would like to route most of my to/from ServerFarm traffic through the IPS, but use some policy-based routing with an ACL (preferably, a policy-based ACL) to allow some servers to bypass the IPS.
So, I thought of taking my Cisco 6509 and making it into a Really Expensive Optical ByPass switch for this small group of servers. The challenge is that the IPS runs strictly at Layer 2. So if I connect the IPS in a loop to the 6509, I must change the MAC addresses on these interfaces on the 6509 so that each address is unique -- as well as assign unique IPs to each of the two interfaces, but the addresses must share the same L3 subnet. Of course, this leads to overlapping addresses on the 6509, which it does not like. So, I want to see if I can try a little VRF-lite to remove the overlapping address problem.
To accomplish the bypass segment, I take a piece of fiber and just connect two ports together on the 6509, changing the MAC addresses and assigning the "overlapping" IPs (which is "solved" by placing the different ports in different VRFs, on just one port in the Global table and the other port in a standalone VRF). If I can do this without running this piece of fiber, I'd be welcome to the idea.
I can fire up OSPF on all of my interfaces, raising the cost of the IPS Bypass link, and use the route-maps to try to route the Bypass traffic correctly. Unfortunately, the route-maps are not behaving. The traffic moves across the two links (one with IPS, one without) assymetrically, which isn't what I want.
I am uploading a diagram that will show a simplified example of what I am doing. Here is my config below. Does anyone have any ideas on what I am doing wrong, or a better way to do this? (I tried a VACL approach, but I could not redirect the traffic properly):
ip vrf Srv
description ServerNets
rd 65000:10
object-group ip address IPS-Ignore
host 192.168.20.2
interface GigabitEthernet1/3
ip address 192.168.200.1 255.255.255.0
ip policy route-map ServerNetIngress
interface GigabitEthernet1/9
description ServerNets
no ip address
ip flow ingress
interface GigabitEthernet1/9.20
description PublicServerNet
encapsulation dot1Q 20
ip vrf forwarding Srv
ip address 192.168.20.1 255.255.255.128
ip flow ingress
ip policy route-map ServerNetEgress
interface GigabitEthernet1/15
description IPS-ByPass-Global
mac-address 0015.c7c9.c10f
ip address 192.168.15.73 255.255.255.252
ip flow ingress
ip ospf cost 100
interface GigabitEthernet1/17
description IPS-ByPass-Srv-VRF
mac-address 0015.c7c9.c111
ip vrf forwarding Srv
ip address 192.168.15.74 255.255.255.252
ip flow ingress
ip ospf cost 100
interface GigabitEthernet1/19
description IPS-Scrub-Global
mac-address 0015.c7c9.c113
ip address 10.0.0.2 255.255.255.252
ip flow ingress
interface GigabitEthernet1/21
description IPS-Scrub-Srv-VRF
mac-address 0015.c7c9.c115
ip vrf forwarding Srv
ip address 10.0.0.1 255.255.255.252
ip flow ingress
router ospf 10 vrf Srv
router-id 192.168.10.1
log-adjacency-changes
capability vrf-lite
network 192.168.0.0 0.0.255.255 area 0
router ospf 1
router-id 192.168.0.1
log-adjacency-changes
network 192.168.0.0 0.0.255.255 area 0
ip access-list extended IPS-Bypass
permit ip addrgroup IPS-Ignore any
permit ip any addrgroup IPS-Ignore
route-map ServerNetIngress permit 100
description ByPassIPS
match ip address IPS-Bypass
set global
set ip next-hop 192.168.15.74 10.0.0.1
route-map ServerNetEgress permit 100
description ByPassIPS
match ip address IPS-Bypass
set ip vrf Srv next-hop 192.168.15.73 10.0.0.2
I obfuscated my addresses, so don't let that throw you off too much.
Clarke Morledge
College of William and Mary

Thank you for the suggestion. Just using the "set ip next-hop" in the respective route-map is sufficient and gets the job done. Unfortunately, my problem is more with how the policy-based ACLs (PBACLs) work; i.e. the lines with the object-group syntax in the config. My contact with the TAC tells me that PBACLs are not really supported to do policy-based routing. So because the PBACL is not working correctly all of the time, things don't get matched properly in the route-map for the policy-based route to get correctly applied.
This is really too bad since the PBACL looks to be a quite handy feature. In my example -- at least in theory -- I should be able to make but one change to the "object-group" in order to properly handle the policy-based routing involving the two different route-maps. Alas, this is not as easy as I hoped for since making changes to the PBACL apparently produces unpredictable results -- and the TAC just tells me that the feature is not supported for what I want to do.

Extending VRF-lite to 6500??

Hello,
I have a simple scenario, where there is a 6500 connected to a router (ISP end), which we have planned to implement vrf-lite on.... there are basically 2 VLANs on the LAN, one production and one guest... we need to isolate the routing table instances between the production and guest.. we have planned to configure trunk between the 6500 and PE router at the ISP end. 6500 acts as a CE here.
Now, I want to extend the VRF information from the PE to the 6500 CE, since the layer 3 VLANs terminate on the 6500. i will define the same VRF information on the 6500 and isolate VRF routing tables for the guest/production vlan on the LAN also.. I know we will require to configure VRF, RD, BGP etc on the PE router and do a "ip vrf forwarding" on the subinterface of the router. What is the configuration required on the 6500 to extend the VRF-lite information to the end vlans ????? does anyone have any sample configs or links to which i can refer ?
Raj

Well,
first a sample config (not from a 6500, but you should be able to get the idea):
ip vrf Cust1
rd 65000:1
ip vrf Cust2
rd 65000:2
interface FastEthernet0/0.100
encapsulation dot1Q 100
ip vrf forwarding Cust1
ip address 10.1.1.1 255.255.255.252
interface FastEthernet0/0.200
encapsulation dot1Q 200
ip vrf forwarding Cust1
ip address 10.1.2.1 255.255.255.252
interface FastEthernet0/0.300
encapsulation dot1Q 300
ip vrf forwarding Cust2
ip address 10.20.1.1 255.255.255.252
interface FastEthernet0/0.333
encapsulation dot1Q 333
ip vrf forwarding Cust2
ip address 10.1.1.1 255.255.255.252
!On a 6500 you could also have:
interface vlan 400
ip vrf forwarding Cust2
ip address 10.1.123.1 255.255.255.252
router rip
address-family ipv4 vrf Cust1
version 2
network 10.0.0.0
no auto-summary
exit-address-family
address-family ipv4 vrf Cust2
version 2
network 10.0.0.0
no auto-summary
exit-address-family
The separation in the control plane (routing etc.) is achieved through the normal VRF configuration. Overlapping IPs and such are supported by having separate IP routing tables per VRF and VRF aware routing protocols like RIP, OSPF, etc.
In the data plane traffic is sorted by layer2 encapsulation. In the example above, the dot1Q VLAN tag will deliver the same functionality as the MPLS VPN labels. If f.e. an IP packet with destination 10.1.1.1 arrives, the VLAN tag 100 or 333 will allow the VRF-lite CE to determine, whether it belongs to Cust1 or Cust2. The same differentation will take place for traffic from the CE to the PE. So the PE config is practically the same, BUT in addition MP-BGP and route-targets and MPLS towards the core is used.
So no MPLS is needed on the VRF-lite CE router, no labels will be used, hence VRF-lite.
The PE will not be the PHP LSR in the MPLS sense, because it is the LAST router in the MPLS network.
Instead of the FastEthernet also VLAN interfaces can be used. The number of interfaces per VRF or the number of VRFs are limited by memory.
Hope this helps! Please use the rating system.
Regards, Martin

Need help on VRF lite

I have implement VRF lite feature for one of the customer...it's working fine..But i m not so clear of following command ...........Can any one explane the same.
router ospf 511 vrf abc
capability vrf-lite <--------What is use of this command..is this is reletaed to BGP to OSPF redistribution..?

Hi,
VRF lite converts the router into multiple virtual routers each one with its separated routing table, interfaces and routing protocols.
The OSPF Support for Multi-VRF on CE Routers feature provides the capability of suppressing provider edge (PE) checks that are needed to prevent loops when the PE is performing a mutual redistribution of packets between the OSPF and BGP protocols. When VPN routing and forward (VRF) is used on a router that is not a PE (that is, one that is not running BGP), the checks can be turned off to allow for correct population of the VRF routing table with routes to IP prefixes.
When the OSPF process is associated with the VRF, several checks are performed when link-state advertisements (LSAs) are received. PE checks are needed to prevent loops when the PE is performing a mutual redistribution between OSPF and BGP interfaces. In some situations, performing PE checks might not be desirable. The concept of VRFs can be used on a router that is not a PE router (that is, a router that is not running BGP). With the capability vrf-lite command, the checks can be turned off to allow correct population of the VRF routing table with routes to IP prefixes.
This command suppresses the Provider Edge (PE) specific checks on a router when the OSPF process is associated with the VRF.
HTH, please do rate all helpful posts,
Mohammed Mahmoud.

CSM VRF Lite OSPF and IPSEC/GRE

Similar Messages

Maybe you are looking for