cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
17240
Views
57
Helpful
6
Replies

Route distinguisher and VRF-ID

olly ahmed
Level 1
Level 1

Hi guys,

Good day !

As far as I know MP-BGP need route distinguisher (rd) for every VRF to separate every VRF routes in bgp table. But in my nexus 7k I did not found any rd configured for any VRF. But bgp table maintains different table for every VRF. When I see VRF information by

show vrf

command I saw a VRF-ID but in IOS can see rd value when give

show ip vrf

command. My question is how MP-BGP in nexus maintain separate table for every VRF whether no route distinguisher (rd) configured for any VRF.

1 Accepted Solution

Accepted Solutions

Hi Olly,

The route distinguisher is only required when you use the

address-family vpnv4 or vpnv6

in your BGP configuration. This is because VPNv4 and VPNv6 address families collect all routes from all VRFs and carry them in a single BGP session to a given neighbor. This is where route distinguisher comes into play - to make network address X from VRF 1 look different than the same network address X from VRF 2 when these VRFs and their networks are advertised one by one within a single BGP session to a neighbor.

If you have BGP neighbors defined under vrf vrf-name context in BGP process in NX-OS, they are not using VPNv4 or VPNv6 address family; rather, they're using what is known in IOS as

address-family ipv4 vrf vrf-name (or address-family ipv6 vrf vrf-name)

. This configuration does not require the use of route distinguishers because these BGP neighbors exchange exclusively the contents of the given VRF, and their all operation is tied to the particular VRF they are configured in - whatever they learn, they put into the given VRF, and whatever they advertise, they advertise from the given VRF. Hence, the route distinguisher is not required there - the separation is given by the configuration itself.

In NX-OS, the route distinguisher is configured in vrf context mode but you need to have

feature-set mpls and feature mpls l3vpn

configured beforehand.

Please feel welcome to ask further!

Best regards,
Peter

View solution in original post

6 Replies 6

Amit Goyal
Level 1
Level 1

Hi Olly,

I believe the Nexus 7K device which you are working on must be configured only for vrf lite only.

"Configuring route distinguisher is NOT at all required in VRF lite scenario but it is required for MPLS VPNs". 

Please note that if you are using Nexus7k for VRF lite (in case of route leaking), MPLS license is also not mandatory. You can simply configure route-target just by enabling BGP feature. You will be able to configure

rd 

command after enabling feature mpls l3vpn, which will require MPLS license.

Please rate if it helps.

HTH

-Amit

Hi Amit, 

Thanks for your reply.

Yes, my Nexus 7k is configured for VRF-lite. But I have BGP configured and there are different bgp neighbors for differnet VRFs. And as far as I know, in IOS routers if we want to distinguish different VRF routes in bgp table then we need to configure route distinguisher (rd) for every VRF as without rd bgp can not differentiate VRFs' routes. My question is how Nexus 7k differentiate between VRFs in bgp table ?

Thanks

Olly

Hi Amit / anyone, can help me to understand above concept.

Hi Olly,

The route distinguisher is only required when you use the

address-family vpnv4 or vpnv6

in your BGP configuration. This is because VPNv4 and VPNv6 address families collect all routes from all VRFs and carry them in a single BGP session to a given neighbor. This is where route distinguisher comes into play - to make network address X from VRF 1 look different than the same network address X from VRF 2 when these VRFs and their networks are advertised one by one within a single BGP session to a neighbor.

If you have BGP neighbors defined under vrf vrf-name context in BGP process in NX-OS, they are not using VPNv4 or VPNv6 address family; rather, they're using what is known in IOS as

address-family ipv4 vrf vrf-name (or address-family ipv6 vrf vrf-name)

. This configuration does not require the use of route distinguishers because these BGP neighbors exchange exclusively the contents of the given VRF, and their all operation is tied to the particular VRF they are configured in - whatever they learn, they put into the given VRF, and whatever they advertise, they advertise from the given VRF. Hence, the route distinguisher is not required there - the separation is given by the configuration itself.

In NX-OS, the route distinguisher is configured in vrf context mode but you need to have

feature-set mpls and feature mpls l3vpn

configured beforehand.

Please feel welcome to ask further!

Best regards,
Peter

Hi peter,

Thanks for sharing valuable knowledge. Now it is more clear than previous. On more question can I configure separate bgp neighbor for separate vrfs in IOS router too ?

BR

Olly

Hi Olly,

You are welcome!

can I configure separate bgp neighbor for separate vrfs in IOS router too ?

Yes, absolutely. This is used very often - providers like to use BGP as a PE/CE protocol in L3VPNs, because they run BGP anyway, and using BGP up to the customer saves them the need to run a per-customer IGP instance and perform redistribution.

As an example, consider the following configuration of an IOS-based router:

router bgp 65000
 address-family ipv4 vrf FirstVRF
  neighbor 1.2.3.4 remote-as 65001 ! eBGP neighbor
  neighbor 5.6.7.8 remote-as 65000 ! iBGP neighbor
  neighbor 5.6.7.8 update-source Loopback1
 exit-address-family
 !
 address-family ipv4 vrf SecondVRF
  neighbor 4.3.2.1 remote-as 65002 ! eBGP neighbor
  neighbor 8.7.6.5 remote-as 65000 ! iBGP neighbor
  neighbor 8.7.6.5 update-source Loopback2
 exit-address-family

Note, however, that in IOS, you might be required to configure unique RDs for each VRF even if you are not using VPNv4 or VPNv6 address families and so the RD is not really used in BGP messages. Different operating systems may have slightly different configuration requirements.

Best regards,
Peter

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco