VRF-Lite: Routing between VRF's using BGP as the Routing Protocol

Unanswered Question
Mar 12th, 2008

Hi, if i configure multiple vrf's on a physical box than configure BGP and form a EBGP neighbor with a downstream device which has no knowledge about the VRF's will I be able to see all the vrf routes above.

for eg

if i have the following topology

VRFA

|

Switch A (6500)

|VRFB

| E

FW B

| G

| P

Switch B (6500)

Switch A Config

ip vrf A

rd 1:1

rt export 1:1

rt import 2:2

!

ip vrf B

rd 2:2

rt export 2:2

rt import 1:1

!

int vl1

ip add 1.1.1.1 255.255.255.0

ip vrf forwarding A

!

int vl2

ip add 2.2.2.1 255.255.255.252

ip vrf forwarding B

!

router bgp 1

address-family ipv4 vrf A

no auto-summary

no sync

redistribute connected

!

address-family ipv4 vrf B

no auto-summary

no sync

redistribute connected

neighbor 4.4.4.4 remote-as 123

neighbor 4.4.4.4 ebgp-multihop 255

neighbor 4.4.4.4 activate

!

!Create static for ebgp neighbor towards firewall

ip route vrf B 4.4.4.4 255.255.255.255 2.2.2.2

!

I saw the neighbor establish and I even see the route gets propogated. However I see that when I look for a route say 60.60.60.0 which I am receiving from my ebgp neighbor in the routing table for VRF A I see the next hop points to the firewall. VRF A does not know about the firewall because the interface going to the firewall is in VRF B. So I redistributed connected. I still could not get it to work however thinking back I might have made a couple of mistakes like maybe not doing a redistribute connected. :-)

Can someone confirm if this configuration will work from what I have explained above?

Also wanted to confirm that the import and export RT's are what cause the routes to get exchanged between the VRF's on the same device? Is that statement true?

If I were to configure a third vrf say VRF C and just do a export 3:3 and import 2:2 will that still achieve separation between the VRF's. I can't help but think that in VRF B since all the routes will be in that routing table it defeats the purpose. Can someone please confirm if this makes any sense or will there still be separation between the VRF's. Thanks

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Loading.
James Lasky Thu, 03/13/2008 - 07:56

Hi,

if I understood correctly the uplink vlan shared between VRFs is the one connected to the fw ?

If so I think it's not correct to talk of vrf lite since in vrf lite you should get separation to the MPLS core (or firewall in this case).

In your config what happens if vrf A and upcoming vrf C have the same ip addressing ?

In this design I definitly think you should have a dot1.q trunk towards the firewall and separate every routing table per vlan on vrf base.

If helps pls rate.

Tks

Ric

Harold Ritter Thu, 03/13/2008 - 08:44

Vikram,

You need to configure "redistribute static" in VRF B for this route to be known by VRF A.

And, yes, the export and import statements basically control the distribution between local VRFs.

If you add a third VRF the best way to exchange the routes would be to import both 1:1 import 2:2 in VRF C. The same should be done in the other VRFs if you want all the routes in all VRFs. But that sounds a lot like using a global routing table, only multipled by 3 ;-)

Regards,

vdadlaney Tue, 06/10/2008 - 08:26

Hi Harold,

Its been a while since I had asked this query and am just getting back to it so apologize about the delayed response.

I have attached a sample diagram of the topology I intend to create and description of the topology in this post.

Pls ignore the 2nd leg (right hand side of the diagram for now which has the device R2-Edge, FW2 and R4-Inside). I might have some queries on that at a later time :-)

R1-Edge has 3 VRF's. VPN_A, VPN_B and FW

VPN_A is 100.100.100.100/24 - Loopback 100

VPN_B is 200.200.200.200/24 - Loopback 200

FW is the interface leading to the FW device which is in a VLAN interface ip 172.16.1.17

I have an EBGP session setup between

R1-Edge (VLAN 20 ip 1.17 in the FW VRF)

and

R3-Inside (VLAN 60 ip 0.17)

I have configured Natting on the FW device so that any traffic that originates from 10.100.100.0/24 (Loopback ip on the R3-Inside Device) gets natted to a NAT pool 172.16.10.0/24

Here are the configs from the R1-Edge Device

ip vrf FW

rd 1:1

route-target export 1:1

route-target import 123:1

route-target import 456:1

!

ip vrf VPN_A

rd 123:1

route-target export 123:1

route-target import 1:1

!

ip vrf VPN_B

rd 456:1

route-target export 456:1

route-target import 1:1

!

interface Loopback0

ip address 1.1.1.1 255.255.255.255

!

interface Loopback123

ip vrf forwarding VPN_A

ip address 100.100.100.100 255.255.255.0

no ip route-cache cef

no ip route-cache

!

interface Loopback456

ip vrf forwarding VPN_B

ip address 200.200.200.200 255.255.255.0

!

interface FastEthernet0/0

!

interface FastEthernet0/1

switchport trunk native vlan 10

switchport mode trunk

duplex full

speed 100

!

interface FastEthernet0/2

switchport access vlan 20

duplex full

speed 100

!

interface Vlan10

ip address 172.16.1.1 255.255.255.252

!

interface Vlan20

ip vrf forwarding FW

ip address 172.16.1.17 255.255.255.240

no ip route-cache cef

no ip route-cache

standby 1 ip 172.16.1.19

standby 1 priority 105

!

router bgp 65000

no synchronization

bgp router-id 1.1.1.1

bgp log-neighbor-changes

no auto-summary

!

address-family ipv4 vrf VPN_B

no auto-summary

no synchronization

network 200.200.200.0

exit-address-family

!

address-family ipv4 vrf VPN_A

no auto-summary

no synchronization

network 100.100.100.0 mask 255.255.255.0

exit-address-family

!

address-family ipv4 vrf FW

neighbor 10.0.0.17 remote-as 64512

neighbor 10.0.0.17 ebgp-multihop 3

neighbor 10.0.0.17 activate

no auto-summary

no synchronization

exit-address-family

!

ip route vrf FW 10.0.0.17 255.255.255.255 172.16.1.21

Here's the output of the VRF routing table

------------------------------------------

R1-Edge#sh ip route vrf VPN_A

100.0.0.0/24 is subnetted, 1 subnets

C 100.100.100.0 is directly connected, Loopback123

172.16.0.0/24 is subnetted, 1 subnets

B 172.16.10.0 [20/0] via 10.0.0.17 (FW), 04:33:53

------------------------------------------

R1-Edge#sh ip route vrf VPN_B

C 200.200.200.0/24 is directly connected, Loopback456

172.16.0.0/24 is subnetted, 1 subnets

B 172.16.10.0 [20/0] via 10.0.0.17 (FW), 04:34:20

-----------------------------------------

R1-Edge#sh ip route vrf FW

B 200.200.200.0/24 is directly connected, 05:00:47, Loopback456

100.0.0.0/24 is subnetted, 1 subnets

B 100.100.100.0 is directly connected, 04:56:32, Loopback123

172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks

C 172.16.1.16/28 is directly connected, Vlan20

B 172.16.10.0/24 [20/0] via 10.0.0.17, 04:34:55

10.0.0.0/32 is subnetted, 1 subnets

S 10.0.0.17 [1/0] via 172.16.1.21

Questions in next post. thx

vdadlaney Tue, 06/10/2008 - 08:28

Question 1

From your previous response you mentioned that I would need a redistribute connected however from the output above it seems I don't need it.

The next hop for internal route 172.16.10.0/24 points to 10.0.0.17 however the VRF's VPN_A and VPN_B know that 10.0.0.17 resides in the FW VRF. I don't need a specific route for 10.0.0.17 in these VRF's. I see it working however I am not sure if this is the right behavior. Can you please confirm if this seems correct?

Question 2

Per your previous post you mentioned that if I have 3 VRF's which is what I have in this case than the table is multiplied by 3. My goal with this design is to separate each vrf and not allow one vrf to talk to the other. I am not going to allow VPN_A routes into VPN_B however all routes from all VRF's will reside in the FW VRF and I don't see any way around that. Any comments on if there is a better way to do this. I cannot involve the firewall in any routing/default gateway type scenario.

Question 3

Finally since i do not have any LDP or VPNv4 sessions would this be considered vrf lite. An earlier post by 5rsalbego mentioned that this would not be considered vrf lite. I am not sure if that relates to this design however this was the design I had in mind even earlier.

Thx for your help

mohammedmahmoud Wed, 06/11/2008 - 00:12

Hi Vikram,

1. redistribution or network commands under the address-family can do the job, and moreover if you are using eBGP for the VRFs you should already be receiving the routes via BGP and require no redistribution or network commands on the local router (except for the connected interfaces).

2. The FW VRF is a central VRF and should have routes from both VRFs and both VRFs should have only the FW routes, and thus no route leaking is done between the two VRFs, check the attached simple example (VRF "a" is the central VRF).

3. VRF-Lite is simply the use of VRFs without using any label switching (which is your case).

BR,

Mohammed Mahmoud.

vdadlaney Wed, 06/11/2008 - 08:31

Hi Mohammed,

Thank you so much for replying. I have created loopbacks for the various VRF's and have issued a network statement under the relevant address-family under the BGP process to inject the route into BGP.

I understand that because of the import RT that i have under the VRF these various routes in the VPNs are getting into the FW VRF however I am concerned with the route coming from the opposite end.

Everything is working however if you take a look at the route below it says the next hop is 10.0.0.17 and in brackets it says (FW) which I assume means that the next hop is known via the FW vrf. Is that normal behavior? The 10.0.0.17 route is not known in the VPN_A vrf.

R1-Edge#sh ip route vrf VPN_A

B 172.16.10.0 [20/0] via 10.0.0.17 (FW), 04:33:53

Finally do you think there is any other way to optimize this setup. I mean the routes from the individual vrf's are going to be in the vrf routing table and the FW vrf. That would mean that it would use up additional memory and resources in addition to the route being in the BGP table for the respective vrf. The routing protocol used per vrf will vary but will be either RIP, BGP or even static. For now we can assume that it will be EBGP. The FW vrf will always exchange routes via EBGP.

One more question. I do apologize for asking so many questions. If you look at the diagram I had attached, a redundant leg is also going to be built with the similar setup and the outside switches are going to be interconnected mainly to exchange keepalives for the FW's but also to have an IBGP session. This was the setup originally (without VRF's) however wondering that with the addition of VRF's how should the setup be. I mean should I run IBGP just between the loopbacks in the FW VRF. Also the link between the switches is a trunk link and I am running HSRP for every VLAN(VRF). The link itself isn't assigned to a VRF however I see the keepalives are exchanged. Wondering if that is the right behavior? Thanks for your help.

mohammedmahmoud Wed, 06/11/2008 - 11:11

Hi,

You are very welcomed, Only FW VRF can communicate with the other 2 VRFs but they can't communicate with each other, this is the purpose of the central services VRF setup like the scenario that i've attached.

A BGP learned route that is leaked to another VRF will always have the original VRF identified since its next-hop is in another VRF, this is a fact of BGP, thus seeing the (FW) is normal.

Finally i believe that this is the optimum way of doing central services, it won't differ using IGP, static routes or BGP, as long as you remember to redistribute or use network command with IGP and static routes.

BR,

Mohammed Mahmoud.

vdadlaney Wed, 06/11/2008 - 14:25

Thx for your response. Any suggestions on the redundant leg (trunk link between the 2 outside switches) and using HSRP as per my last question in my previous post. Thx

vdadlaney Mon, 06/16/2008 - 14:25

Is it possible to import/export routes that reside in the vrf table into a global table and vice-versa?

For eg: If I receive routes via eBGP in a VRF how can I transfer those routes into the global unicast bgp table and the routing table.

and

if i receive routes via eBGP in the global BGP table hence the route is also in the global routing table than how can i transfer that route into a vrf BGP table and routing table?

The reason I am asking is that as per the diagram I had posted I was wondering if I can get rid of the FW vrf that I am using which is essentially like the Global RT for me. It seems that might simplify things a bit. Does anyone see any issues with this design?

The only thing I can think of would be that I would have to somehow make sure that routes from one vrf's doesn't get leaked into another vrf. Any simple way to do this besides using route-maps and prefix-lists.

The whole idea of this design is to separate each vrf from the other and avoid being a transit using vrf's. I realize ACL's and route-maps would achieve the objective very simply in non-vrf scenario's however the ACL's tend to get too large and managing them becomes tougher over time.

Thx for your help.

vdadlaney Thu, 08/21/2008 - 10:25

I have run into an issue that I just noticed on this design. I am a bit stumped as the solution I am coming up with seems a bit more complicated . As mentioned before I have 2 legs in this design. The primary leg on its own works fine however the problem comes in from the redundant second leg. I have an iBGP session between the primary and secondary device in the FW vrf. However due to my rt imports and exports the route seems to be going back into the VPNA routing table on the redundant leg switch. This actually defeats the purpose of implementing this design.

The solution as of now that I can think of would be to introduce 2 additional VRF's in addition to the FW vrf with different RT imports and exports. Use 1 of the additional vrf's to import all the routes received from the external sources and use the other to import routes received from the internal side.

Attached are my configs and relevant show commands. If you look at the show ip bgp vpnv4 output on R2-Edge you will see that the route 100.100.100.0/24 is in the VPN_B table however that route is learnt from VPN_A on R1-Edge.

Can someone please let me know if there is a simpler way to prevent the routes from leaking back to other customers as well as to the same customer via the redundant leg. Don't want to use distribute-lists etc

Thx for your help.

vdadlaney Mon, 08/25/2008 - 06:01

I managed to make this work by creating a BGP VPNv4 session between the redundant outside edge devices. However had to run LDP between that link. Is there any way to run the BGP VPNv4 session without LDP since these switches are directly connected. If possible I would also not like to run VPNv4 either but am not sure if that's possible. Thx

Actions

This Discussion