• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

Cisco VRF examples

D

DarkOne_BW

Limp Gawd
Joined
Apr 21, 2002
Messages
472
I'm looking for anyone that wouldn't mind posting their VRF config for me to contemplate. I've got a Catalyst 6500 that I'm trying to "split" into multiple virtual routers but I can't seem to find a really good howto on the process. Due to the complexity of my routing, simply using VLANs will not suffice.

Thanks!
 
Is this for MPLS VPNs? Or VRF Lite? This will only be on a single switch? What's the goal?
 
Vito_Corleone said:
Is this for MPLS VPNs? Or VRF Lite? This will only be on a single switch? What's the goal?
Click to expand...
Theres actually no difference except for the bgp configuration(vpnv4 address family) when configuring VRF lite/full VRF(MPLS).

Darkone,

Why is your routing too complex for VLANs? VRF's are extremely straightforward.. literally, create the VRF, add the VRF to the interfaces that you want, configure your routing protocol to run on said VRF, define RD, import and export accordingly.

EX.

ip vrf TEST
rd 1001:1000
route-target export 1001:1111
route-target import 10002:1000
int l100
ip vrf forwarding TEST

the routing protocol configuration differs depending on protocol obviously.
 
xphil3 said:
Theres actually no difference except for the bgp configuration(vpnv4 address family) when configuring VRF lite/full VRF(MPLS).
Click to expand...

The lack of MPLS/LDP is another difference. I'm aware of these, I'm just trying to get an understanding of what he's trying to accomplish, and whether or not he really needs VRFs.
 
Vito_Corleone said:
The lack of MPLS/LDP is another difference. I'm aware of these, I'm just trying to get an understanding of what he's trying to accomplish, and whether or not he really needs VRFs.
Click to expand...
The LDP configuration is irrelevant when you're configuring VRF's . Again, weather your configuring L3VPN's or VRF lite the VRF configuration is identical. Dont be so defensive, im attempting to learn you something! :rolleyes:
 
Vito_Corleone said:
Not defensive, just clarifying. And, if LDP is irrelevant how is BGP relevant?
Click to expand...
BGP isn't relevant, neither is LDP.. this is the point.

OP, sorry for the derailment... feel free to explain why you think you need VRF's. If my example isn't straightforward.. use the googlebox.
 
I've been down the google road for the better part of today.

My routing is too complex in that I need either
1) source-based routing (PBR)
or
2) distribution routers at each site
3) a means to have multiple distinct route groups in a single switch

Here's the reason if you're interested: My server farm accesses the Internet directly with quite a few established 1-1 NATs defined in my firewall. My clients route to a content filter (Untangle) then out the same connection the servers use. I've been doing this with a distribution layer running on HP procurve switches at the sites (remote sites use Untangle as a default gateway with a route to the server farm) but the routing engine in the HP is too weak to sustain the packets-per-second that I need it to handle. For those HP lovers, I can tell you that where the HP failed a Cisco 3550 was able to handle the load. I have definitive proof that you do indeed get what you pay for.

In trying to get away from all these switches acting as distribution routers I'd like to move that task onto the far superior SUP720 that's sitting in my new 6500 series. I'd like to see a working config as casual reading in hopes that I can have that "TaDa!" moment when I realize it's something simple like forgetting to issue a "no shutdown".

If VRF isn't what I need to use to establish multiple virtual routers in the Cat, then I'd love to be advised on what to google next.
 
I'm lost, not really sure what your goal is here. Hopefully xphil3 can offer some guidance.
 
Data center: 172.16.0.0/16
Untangle box: 172.16.0.2
ASA 5540: 172.16.0.3
6500 (core): 172.16.0.1 with GW as 172.16.0.3

remote site 1: 172.17.8.0/21 with GW as 172.16.0.2
remote site 2: 172.17.16.0/21 with GW as 172.16.0.2
etc.

I want the remote sites to always have a default gateway of 172.16.0.2. The core will have a default gateway of 172.16.0.3.

When the devices are physically seperated it is simple to have the remote site router have a different default gateway as the core, but when it all happens in the 6500 I don't know how to have different default gateways defined. My understanding is that VLANs cannot do this, but that VRF can.
 
If you're doing ethernet from the 6500 to the remote sites, you can do this with VLANs. Put extra NICs in the Untangle box. Put each one of those NICs in those remote VLANs, as well as your routed remote site ports. Or better yet, if Untangle supports trunking.. use that. I've never used the the product so I'm not sure.

Then, take the IPs you assigned to the 6500 for those routed ports and assign them to the new Untangle box NICs instead.

Otherwise, if you can't add more NICs, don't want to use PBR, or still want to use VRFs, xphil3's config will get you rolling. Here's how you would put BGP on top of that:
router bgp XXXX
address-family ipv4 vrf TEST
(regular BGP network/neighbor commands)

Also, if you need them to also be able to access other networks on the 6500 directly without hitting the Untangle box, you'll need to assign those VLAN SVIs another IP address and either run a routing protocol on the remote sites or put statics.
 
I think I've about got this figured out but I've run into something I'm not entirely clear about.

I can establish the VRF and assign to interfaces, and machines on those interfaces can route within the VRF and ping other devices on the same VRF, but I can't ping to the 6500's address on VLAN1, nor can I ping the VRF IP addresses from the console. Surely there's a need to route from the core to the VRF, but I can't seem to find how that route statement should look. I get errors when issuing ip route commands that involve VRF and the loopback interface.
 
DarkOne_BW said:
I can establish the VRF and assign to interfaces, and machines on those interfaces can route within the VRF and ping other devices on the same VRF, but I can't ping to the 6500's address on VLAN1, nor can I ping the VRF IP addresses from the console. Surely there's a need to route from the core to the VRF, but I can't seem to find how that route statement should look. I get errors when issuing ip route commands that involve VRF and the loopback interface.
Click to expand...
Completely normal, when you create a virtual forwarding base its just that.. a completely separate "RIB" within the router(as it was always explained to me), If you want intracommunication, loop a cable between the two ports(one in the vrf, one in your management VLAN) and you're golden. This is the way I have had to get this working before.

Like vito, Im very lost as well. It doesn't sound like you know exactly what you want or the technologies that will accomplish what you think you may want. It appears that you want remote side to be pushed through a content filter, personally.. the best way to do this is with some kind of VPN, perhaps GRE. I dont see VRF's leading to what you described what you want to do.
 
I guess my next question would be: Is it possible to route between two VRFs?

You're correct that I want the remote sites pushed through the content filter. I've been doing this with physically separated devices but want all that to live virtually on the core switch, thus eliminating the distribution routers at each site.
 
DarkOne_BW said:
I guess my next question would be: Is it possible to route between two VRFs?
Click to expand...
Yes, using the way that I mentioned or route leaking between your VRF's.

DarkOne_BW said:
You're correct that I want the remote sites pushed through the content filter. I've been doing this with physically separated devices but want all that to live virtually on the core switch, thus eliminating the distribution routers at each site.
Click to expand...
This can be done with GRE VPN and proper routing. No need for VRF's at all.
 
VRFs are what you would use when connecting to a provider network, and performing eBGP peering with them, while using 10.*/8 space or other RFC1918 aggregates. You see, the provider may be peering with other private networks, also using RFC1918 space, so hence you have to find a way to uniquely tag the routes as they come in, or else lose the ability to distinguish between your 10.*/8 space and someone else.

Nowadays, MPLS wire services are helping eliminate that need.

If what you're looking for is something with a hypervisor, capable of virtualizing the entire routing engine, then you need to be looking into something like a Nexus 7010/7018.
 
n725075089-288918-2774-tm.jpg
 
BakedA|aska said:
Nowadays, MPLS wire services are helping eliminate that need.

If what you're looking for is something with a hypervisor, capable of virtualizing the entire routing engine, then you need to be looking into something like a Nexus 7010/7018.
Click to expand...
MPLS for customer transit traffic will still require VRF's at the PE's, obviously not within the core due to label switching, especially if we're allowing CPE to advertise RFC1918 ranges to our PE's.

Also, I wouldn't recommend the nexus for router virtualization at all. The Nexus is a data center networking core switch, port density and speed. A better recommendation would have been the ASR1000 for lower end virtualization.
 
Yeah I still don't trust my 7010/8s for advanced routing, nor will I ever really. But like you said it doesn't matter anyway. All I use them for is to advertise some server/VM VLANs that are directly connected.

Off topic, but I must admit that vPC is kind of cool -- it's finally maturing into something more stable with the recent releases.
 
Okay, so I've been playing with a few attempts at getting this working but I'm stuck. Here's a snippet of what I've got so far:

Code: 
ip vrf Site1
rd: 10:1
route-target export 10:1
route-target import 10:1

interface GigabitEthernet1/1
switchport
switchport access vlan 10
switchport mode access
no ip address

interface VLAN 1
description "Data Center"
ip address 172.16.0.1 255.255.0.0

interface VLAN 10
description "Site 1"
ip vrf forwarding Site1
ip address 172.17.8.1 255.255.248.0

I'm assigning VRFs to VLANs because I intend to do some trunking config down the road.

I do not understand how to get traffic from Site1 (172.17.8.0/21) to route to endpoints in the Data Center (172.16.0.0/16). How/where do you assign an IP address that is seen both by VLAN1 and the VRF? Does this get mapped somehow in BGP? I tried several things but couldn't get it working.
 
The point of VRFs is that the traffic is completely separate. You have separate routing tables. VRFs are not what you want.
 
yeah, i don't think you want VRF's. can you post a diagram of what you're trying to accomplish?
 
DarkOne_BW said:
Okay, so I've been playing with a few attempts at getting this working but I'm stuck. Here's a snippet of what I've got so far:

Code: 
ip vrf Site1
rd: 10:1
route-target export 10:1
route-target import 10:1

interface GigabitEthernet1/1
switchport
switchport access vlan 10
switchport mode access
no ip address

interface VLAN 1
description "Data Center"
ip address 172.16.0.1 255.255.0.0

interface VLAN 10
description "Site 1"
ip vrf forwarding Site1
ip address 172.17.8.1 255.255.248.0

I'm assigning VRFs to VLANs because I intend to do some trunking config down the road.

I do not understand how to get traffic from Site1 (172.17.8.0/21) to route to endpoints in the Data Center (172.16.0.0/16). How/where do you assign an IP address that is seen both by VLAN1 and the VRF? Does this get mapped somehow in BGP? I tried several things but couldn't get it working.
Click to expand...

See earlier post

xphil3 said:
Completely normal, when you create a virtual forwarding base its just that.. a completely separate "RIB" within the router(as it was always explained to me), If you want intracommunication, loop a cable between the two ports(one in the vrf, one in your management VLAN) and you're golden
Click to expand...
 
That's not so much of an option when you consider the total number of intercommunication loops that would be necessary. The nature of the network is such that Site1 will need to be able to route from Site2-Site11 as well as the DataCenter site. That's chewing up a LOT of ports for something that I would expect can be handled as an internal redirect.
 
I really despise your setup overall since it goes against what VRFs are supposed to be, but I don't blame you for wanting to avoid PBR. Really wish you'd post a diagram though cause I'm making assumptions and after some drinks tonight who knows if this makes any sense.

DISCLAIMER: You will need to test this a lot more than I did.

As an alternative to the physical method... you can redistribute static routes. Essentially, it's localized route leaking.. which I don't know has ever been done. You replace each of those ports xphil3 was suggesting with one of these statics instead.. it's still a nuisance/ugly method, but here it is anyway: (for simplicity, I'm not paying attention to your site addresses)

Code: 
int vlan 100
ip vrf forwarding Site1
ip addr 1.1.1.1 255.255.255.0
int vlan 200
ip vrf forwarding Site2
ip addr 2.2.2.1 255.255.255.0
int vlan 300
ip vrf forwarding Site3
ip addr 3.3.3.1 255.255.255.0
.

and so on..

For Global RIB:
ip route 1.1.1.0 255.255.255.0 Vlan100 1.1.1.1
ip route 2.2.2.0 255.255.255.0 Vlan200 2.2.2.1
ip route 3.3.3.0 255.255.255.0 Vlan300 3.3.3.1
.

For Site1 VRF RIB:
ip route vrf Site1 2.2.2.0 255.255.255.0 Vlan200 2.2.2.1
ip route vrf Site1 3.3.3.0 255.255.255.0 Vlan300 3.3.3.1
ip route vrf Site1 4.4.4.0 255.255.255.0 Vlan400 4.4.4.1
.

For Site2 VRF RIB:
ip route vrf Site2 1.1.1.0 255.255.255.0 Vlan100 1.1.1.1
ip route vrf Site2 3.3.3.0 255.255.255.0 Vlan300 3.3.3.1
ip route vrf Site2 4.4.4.0 255.255.255.0 Vlan400 4.4.4.1
.

and so on...
then

router bgp X
  redistribute static metric 1    ! global RIB
 address-family ipv4 vrf Site1
  redistribute static metric 1
 address-family ipv4 vrf Site2
  redistribute static metric 1
 address-family ipv4 vrf Site3
  redistribute static metric 1
.
and so on...

You don't get the error that your next hop is the router itself because of the way VRFs truly separate routing tables. It works, I tested this on my lab mpls sup7200-3bxl cores. No crazy CPU spike or crashes, but I only messed with it for a few minutes with nothing but simple ICMP.

Good luck... I would schedule some down time to test if you don't have a lab :cool:. I also hope nothing like this odd will be on the CCIE lab.
 
That did the trick for me! I completely replicated my network and have been setting up for a load test. The thing that was holding me up was the misunderstanding of the route command. I didn't realize you could route x.x.x.x x.x.x.x interface IP. My last steps are to quickly build a cacti box to monitor my sustained throughput/CPU load and to build EtherChannels on my redundant wireless links.

I didn't have time today to draw out a network map, and now that I'm at home I don't have a visio equivalent for use in OS X. I won't have any time tomorrow to build it either, so for now no diagram.

Thanks to the contributors for this project. Any of you that are near / coming through Oklahoma City anytime soon are welcome to a free lunch or cookies!
 
Cool -- glad it worked out for you.

The main issue with it is that it scales terribly. For each VLAN you add... you gotta way too many statics.
 
You must log in or register to reply here.
Back
Top