cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
548
Views
5
Helpful
3
Replies
mhiyoshi
Beginner

Why VxLAN EVPN eBGP needs to configure "retain route-target all" under address-family L2 EVPN?

Dear all,

 

Now I am checking for the required VxLAN configuration under eBGP Spine. Now the following is related CCO URL below.

I know it is mandatory configuration to function correctly, however I would like to understand why it is necessary to configure

"retain route-targe all" under address-family L2VPN EVPN [global]

 

Because if it is not configure on the following topology, the connectivity can be possible within same subnet.

 

PC1---VLAN10---LEAF-1---SPINE-1-----eBGP-----SPINE-2---LEAF-2---VLAN10---PC2

*Only VxLAN Bridging Network (same segment) but it needs to use unicast ingress-replication under EVPN for future extention.

 

https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus9000/sw/7-x/vxlan/configuration/guide/b_Cisco_Nexus_9000_Series_NX-OS_VXLAN_Configuration_Guide_7x/b_Cisco_Nexus_9000_Series_NX-OS_VXLAN_Configuration_Guide_7x_chapter_0100.html 

 

Configuring BGP for EVPN on the Spine
Configure retain route-target all under address-family Layer 2 VPN EVPN [global].

Note 	
Required for eBGP. Allows the spine to retain and advertise all EVPN routes 
when there are no local VNI configured with matching import route targets.

Actually I can not imagine the condition on the above red line. no local VNI means that

Leaf does not have VLAN to VNI mapping right? if so why this is mandatory configuration....

 

I appreciate if there is any sample topology, configuration and verification.

 

Best Regards,

 

Masanobu Hiyoshi

 

 

 

 

3 REPLIES 3
horia.gunica
Beginner

Hello!

So - usually retain route target-all is commonly used in inter-as MPLS option B solutions. And it is used so that you do NOT configure all the VRF locally on the border PEs . 

 

So - taking your case :

PC1---VLAN10---LEAF-1---SPINE-1-----eBGP-----SPINE-2---LEAF-2---VLAN10---PC2

 

You configure VRF A on LEAF-1 and you then configure VRF B on LEAF-2 . VRF A and B exchange common route targets . If you don't configure "retain route-target all" on the SPINEs - then you need to deploy VRF A on SPINE-1 and VRF-B on SPINE-2 with the route targets that you want to exchange . If you do not configure then on the spines - the BGP advertisements from each other would be dropped due to a filter saying "not locally imported" . But if you configure the retain route target all feature - then it will accept ANY MP-BGP (per AF) advertisement - even if locally imported or not .

 

I hope that clarifies the issue.


Best regards!

 

Horia G.

Hello 

 

Thank you very much. So in my understanding If "retain route-target all" on the Spines, then "route-target 1 to 1 mapping" on the Leaf requires right? 

 

According to VxLAN EVPN eBGP manual requires "retain route-target all" however if there is only one L2VPN communication within VRF-A. then I think it might not be mandatory because it look functioning.. However if VxLAN Routing is necessary it is mandatory in my understanding.

 

https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus9000/sw/7-x/vxlan/configuration/guide/b_Cisco_Nexus_9000_Series_NX-OS_VXLAN_Configuration_Guide_7x/b_Cisco_Nexus_9000_Series_NX-OS_VXLAN_Configuration_Guide_7x_chapter_0100.html 

 

retain route-target all

Configure retain route-target all under address-family Layer 2 VPN EVPN [global].

Note - Required for eBGP. Allows the spine to retain and advertise all EVPN routes when there are no local VNI configured with matching import route targets.

mkilar
Cisco Employee

Hello Masanobu,

 

The documentation piece you marked red: "when there are no local VNI configured with matching import route targets" rather applies to the SPINE not the LEAF.

And it makes sense I guess - you don't usually configure any VNIs on SPINEs.

 

The configuration you are curious about: "retain route-target all" will make a difference in case of eBGP peering between LEAVES and SPINES and will allow SPINE to accept the prefix received over eBGP from LEAF.

 

Without the "retain route-target all" the prefix would not be accepted and similar debug message would be seen on SPINE:

 

SPINE_3# debug bgp updates error-handling

SPINE_3# show debug logfile BGP

bgp:  [5512] (default) UPD: Received UPDATE message from 10.100.0.1

bgp:  [5512] (default) UPD: 10.100.0.1 parsed UPDATE message from peer, len 134 , withdraw len 0, attr len 111, nlri len 0

bgp:  [5512] (default) UPD: Peer 10.100.0.1 nexthop length in MP reach: 4

bgp:  [5512] (default) UPD: Recvd NEXTHOP 10.100.1.12

bgp:  [5512] (default) UPD: Attr code 14, length 51, Mp-reach

bgp:  [5512] (default) UPD: Attr code 1, length 1, Origin: IGP

bgp:  [5512] (default) UPD: Attr code 16, length 40, Ext-community: RT:65012:100101 RT:65012:900199 SOO:10.100.1.12:0 ENCAP:8 Router MAC:7079.b32a.89a7

bgp:  [5512] (default) UPD: 10.100.0.1 Received attr code 2, length 6, AS-Path: <65012 >

bgp:  [5512] (default) UPD: [L2VPN EVPN] 10.100.0.1 Inbound import RT check action deny

bgp:  [5512] (default) UPD: Received ESI 0000.0000.0000.0000.0000 for route type 2 from peer 10.100.0.1

bgp:  [5512] (default) UPD: [L2VPN EVPN] Received rd 10.100.0.1:32868 prefix [2]:[0]:[0]:[48]:[707d.b964.9441]:[32]:[10.200.101.100]/144 from peer 10.100.0.1, origin 0, next hop 10.100.1.12, localpref 0, med 0

bgp:  [5512] (default) UPD: [L2VPN EVPN] Dropping prefix [2]:[0]:[0]:[48]:[707d.b964.9441]:[32]:[10.200.101.100]/144 from peer 10.100.0.1, due to attribute policy rejected

 

Best regards,

__

Michal

Content for Community-Ad