Posted on June 3, 2021 2:57 am
 |  Asked by Guohong Zhou
 |  222 views
RESOLVED
0
0
Print Friendly, PDF & Email

Hi experts,

I did a test with vEOS to verify inter-VRF local route leaking for default VRF.  I followed the guide as below but didn’t get results as expected.

BGP VPN and Inter-VRF Local Route Leaking Support for default VRF

Border01#sh ip route vrf default

VRF: default
Codes: C – connected, S – static, K – kernel,
O – OSPF, IA – OSPF inter area, E1 – OSPF external type 1,
E2 – OSPF external type 2, N1 – OSPF NSSA external type 1,
N2 – OSPF NSSA external type2, B – BGP, B I – iBGP, B E – eBGP,
R – RIP, I L1 – IS-IS level 1, I L2 – IS-IS level 2,
O3 – OSPFv3, A B – BGP Aggregate, A O – OSPF Summary,
NG – Nexthop Group Static Route, V – VXLAN Control Service,
DH – DHCP client installed default route, M – Martian,
DP – Dynamic Policy Route, L – VRF Leaked,
RC – Route Cache Route

Gateway of last resort is not set

B E 2.2.2.1/32 [20/0] via 10.0.3.1, Ethernet1
C 3.3.3.1/32 is directly connected, Loopback0
B L 4.4.4.1/32 [20/0] (source VRF vrf-1) via 10.0.4.2, Ethernet2 (egress VRF vrf-1)
S 6.6.6.0/24 [1/0] via 10.0.3.1, Ethernet1
B E 10.0.1.0/30 [20/0] via 10.0.3.1, Ethernet1
B E 10.0.2.0/30 [20/0] via 10.0.3.1, Ethernet1
C 10.0.3.0/30 is directly connected, Ethernet1
C 192.168.3.0/24 is directly connected, Management1

Border01#sh ip route vrf vrf-1              >>2.2.2.1/32 in default VRF is not shown in VRF vrf-1

VRF: vrf-1
Codes: C – connected, S – static, K – kernel,
O – OSPF, IA – OSPF inter area, E1 – OSPF external type 1,
E2 – OSPF external type 2, N1 – OSPF NSSA external type 1,
N2 – OSPF NSSA external type2, B – BGP, B I – iBGP, B E – eBGP,
R – RIP, I L1 – IS-IS level 1, I L2 – IS-IS level 2,
O3 – OSPFv3, A B – BGP Aggregate, A O – OSPF Summary,
NG – Nexthop Group Static Route, V – VXLAN Control Service,
DH – DHCP client installed default route, M – Martian,
DP – Dynamic Policy Route, L – VRF Leaked,
RC – Route Cache Route

Gateway of last resort is not set

C 3.3.3.1/32 is directly connected, Loopback1
B E 4.4.4.1/32 [20/0] via 10.0.4.2, Ethernet2
C 10.0.4.0/30 is directly connected, Ethernet2
B E 10.0.5.0/24 [20/0] via 10.0.4.2, Ethernet2

Border01#sh run sec prefix
ip prefix-list pl-vrf-default
seq 10 permit 2.2.2.0/24 ge 32 le 32
ip prefix-list pl-vrf-qiyi
seq 10 permit 4.4.4.0/24 ge 32 le 32
route-map BGP-export-vrf-default permit 10
match ip address prefix-list pl-vrf-default
route-map BGP-import-vrf-qiyi permit 10
match ip address prefix-list pl-vrf-qiyi
Border01#
Border01#sh run sec bgp
route-map BGP-export-vrf-default permit 10
match ip address prefix-list pl-vrf-default
route-map BGP-import-vrf-qiyi permit 10
match ip address prefix-list pl-vrf-qiyi
router bgp 4259840301
router-id 3.3.3.1
update wait-for-convergence
update wait-install
timers bgp 10 30
distance bgp 20 200 10
maximum-paths 64 ecmp 64
neighbor Spine peer group
neighbor Spine remote-as 4259840201
neighbor Spine out-delay 0
neighbor Spine maximum-routes 0
neighbor Spine_evpn peer group
neighbor Spine_evpn remote-as 4259840201
neighbor Spine_evpn out-delay 0
neighbor Spine_evpn update-source Loopback0
neighbor Spine_evpn ebgp-multihop 3
neighbor Spine_evpn send-community extended
neighbor Spine_evpn maximum-routes 0
neighbor 2.2.2.1 peer group Spine_evpn
neighbor 10.0.3.1 peer group Spine
!
address-family evpn
neighbor Spine_evpn activate
!
address-family ipv4
neighbor Spine default-originate
no neighbor Spine_evpn activate
network 3.3.3.1/32
!
vrf default
rd 3.3.3.1:0
route-target import evpn 65000:0
route-target import evpn 65000:1
route-target export evpn 65000:0
route-target import evpn route-map BGP-import-vrf-qiyi
route-target export evpn route-map BGP-export-vrf-default
!
vrf vrf-1
rd 3.3.3.1:1
route-target import evpn 65000:0
route-target import evpn 65000:1
route-target export evpn 65000:1
neighbor 10.0.4.2 remote-as 65001
neighbor 10.0.4.2 maximum-routes 0
network 3.3.3.1/32
Border01# sh run sec vxlan
interface Vxlan1
vxlan source-interface Loopback0
vxlan udp-port 4789
vxlan vrf default vni 30000
vxlan vrf vrf-1 vni 20000
Border01#

 

0
Posted by Aniket Bhowmick
Answered on June 3, 2021 3:36 am

Hi Guohong

Can you send us the following outputs. You can collect the below outputs in a file and share the file:

  • show bgp instance vrf default
  • show bgp evpn detail
  • show version
  • show route-map BGP-export-vrf-default
  • show ip prefix-list
  • show interface vxlan 1
  • show agent IpRib ping

Query- did you rebooted the vEOS once after you configured the command "service routing protocols model multi-agent" ?

The configuration you shared looks correct. Once you send us the outputs we requested, it will give us more insight into the issue.

Regards,

Aniket

0
Posted by Guohong Zhou
Answered on June 3, 2021 9:31 am

Hi Aniket,

Thanks for your reply.  I definitely rebooted the vEOS after I configured the command " service routing protocols model multi-agent". Actually I rebooted all vEOS instances many times.

Please find attachments for info you need.

The test setup is as below.

Leaf01(VTEP)------Spine01------(VTEP)Border01(vrf-1)---------External01
Lo0: 1.1.1.1---------- 2.2.2.1 ----------------3.3.3.1 -------------------4.4.4.1
eBGP underlay & eBGP overlay. External01 is accessed through EVPN VRF vrf-1 of Border01.
The requirement is that 2.2.2.1 in VRF default and 4.4.4.1 in VRF vrf-1 can ping each other.
Leaking routes across VRF default & vrf-1 is configured on Border01.

Attachments:
0
Posted by Aniket Bhowmick
Answered on June 24, 2021 3:44 pm

Hi Guohong

I didn't find anything wrong with the outputs you shared or with the configurations so far.

But the following command under "router bgp" does seem suspicious- "update wait-install". This command is applied on default vrf (under router bgp) but not under the "vrf vrf-1" from where the route gets leaked.

Recently there was an issue we encountered (in vEOS environment) where an eBGP route was not being advertised as "update wait-install" was configured.

Here is the link for the same: https://eos.arista.com/forum/mp-bgp-evpn-not-working/

Once the command was removed, it got advertised.

The same principle might be applicable here which is why the route in default vrf is not getting leaked into vrf-1.

"update wait-install" is actually more applicable for Hardware based platforms where only if the BGP route is programmed in the Hardware, it will be further advertised to other BGP neighbours. But with vEOS, it might be leading to some issue with advertising the route (need to further confirm on this).

For now, can you try once removing the "update wait-install" command and then see if the route is leaked from default to vrf-1 ?

Regards,

Aniket

 

0
Posted by Guohong Zhou
Answered on June 25, 2021 2:16 am

Hi Aniket,

You are right. The route 2.2.2.1/32 from default VRF can be seen in vrf-1 route table after I remove "update wait-install". Thank you very much.

Border01(config-router-bgp)#no update wait-install
Border01(config-router-bgp)#
Border01(config-router-bgp)#sh ip rout vrf vrf-1

VRF: vrf-1
Codes: C - connected, S - static, K - kernel,
O - OSPF, IA - OSPF inter area, E1 - OSPF external type 1,
E2 - OSPF external type 2, N1 - OSPF NSSA external type 1,
N2 - OSPF NSSA external type2, B - BGP, B I - iBGP, B E - eBGP,
R - RIP, I L1 - IS-IS level 1, I L2 - IS-IS level 2,
O3 - OSPFv3, A B - BGP Aggregate, A O - OSPF Summary,
NG - Nexthop Group Static Route, V - VXLAN Control Service,
DH - DHCP client installed default route, M - Martian,
DP - Dynamic Policy Route, L - VRF Leaked,
RC - Route Cache Route

Gateway of last resort is not set

B L 2.2.2.1/32 [0/0] (source VRF default) via 10.0.3.1, Ethernet1 (egress VRF default)
C 3.3.3.1/32 is directly connected, Loopback1
B E 4.4.4.1/32 [20/0] via 10.0.4.2, Ethernet2
C 10.0.4.0/30 is directly connected, Ethernet2
B E 10.0.5.0/24 [20/0] via 10.0.4.2, Ethernet2

Post your Answer

You must be logged in to post an answer.