Posted on February 28, 2020 6:16 pm
 |  Asked by Timothy Patrick
 |  138 views
0
0
Print Friendly, PDF & Email

Hello, I am new to Arista platform. We are evaluating interoperability between Arista and Cisco as we are predominately Cisco shop. We have setup a lab consisting of a Cisco CSR1000v router acting as the (P)rovider router in our MPLS network. Another CSR1000v acting as a (PE) device and and an Arista vEOS-lab-4.23.1F image acting as another (PE) device. There is an additional CSR 1000v acting as a route-reflector. Initial testing in bringing up OSPF/Loopback interfaces, MPLS LDP interfaces/neighbors and BGP/ VRF route leaking has been successful. I am able to see routes propagated via BBP in both PE devices but I am unable to ping between them from the VRF. If I replace the Arista with another CSR1000v I am able to ping between the PE devices on the VRFs

Included below is the config for the vEOS:

Hostname DTPCE-SWT-01
!
spanning-tree mode mstp
!
no aaa root
!
vlan 17
!
vrf instance TUSR
rd 6500:1199
!
vrf instance mgmt-vrf
!
interface Ethernet1
no switchport
ip address 192.168.252.26/30
ip ospf area 0.0.0.0
!
interface Ethernet2
shutdown
switchport access vlan 17
vrf TUSR
ip address 4.4.4.1/24
!
interface Loopback17
vrf TUSR
ip address 2.2.2.2/32
!
interface Loopback99
ip address 192.168.255.3/32
ip ospf area 0.0.0.0
!
interface Management1
vrf mgmt-vrf
ip address dhcp
!
interface Vlan17
vrf TUSR
ip address 5.5.5.1/24
!
ip routing
ip routing vrf TUSR
no ip routing vrf mgmt-vrf
!
mpls ip
!
mpls ldp
router-id interface Loopback99
no shutdown
!
router bgp 65000
router-id 192.168.255.3
neighbor 192.168.255.7 remote-as 65000
neighbor 192.168.255.7 update-source Loopback99
neighbor 192.168.255.7 send-community extended
neighbor 192.168.255.7 maximum-routes 12000
!
address-family ipv4
no neighbor 192.168.255.7 activate
!
address-family vpn-ipv4
neighbor 192.168.255.7 activate
!
vrf TUSR
rd 65000:1199
route-target import vpn-ipv4 65000:1199
route-target export vpn-ipv4 65000:1199
router-id 192.168.255.3
redistribute connected
redistribute static
!
router ospf 1
router-id 192.168.255.3
auto-cost reference-bandwidth 1000000
passive-interface default
no passive-interface Ethernet1
max-lsa 12000
!

and here is the CSR1000V config

Current configuration : 2513 bytes
!
! Last configuration change at 08:36:43 UTC Wed Feb 19 2020
!
version 16.3
no platform punt-keepalive disable-kernel-core
platform console auto
!
hostname CORE_PE
!
boot-start-marker
boot-end-marker
!
no aaa new-model
!
ip vrf TUSR
rd 65000:1199
route-target export 65000:1199
route-target import 65000:1199
!
no ip domain lookup
!
diagnostic bootup level minimal
!
spanning-tree extend system-id
!
!
!
redundancy
!
!
cdp run
!
!
interface Loopback17
ip vrf forwarding TUSR
ip address 3.3.3.3 255.255.255.255
!
interface Loopback99
ip address 192.168.255.5 255.255.255.255
ip ospf 1 area 0
!
interface GigabitEthernet1
ip address dhcp
negotiation auto
no mop enabled
no mop sysid
!
interface GigabitEthernet2
ip address 192.168.252.6 255.255.255.252
ip ospf 1 area 0
negotiation auto
mpls ip
no mop enabled
no mop sysid
!

router ospf 1
router-id 192.168.255.5
auto-cost reference-bandwidth 1000000
passive-interface default
no passive-interface GigabitEthernet2
bfd all-interfaces
mpls ldp sync
!
router bgp 65000
template peer-policy FUSION
soft-reconfiguration inbound
send-community both
exit-peer-policy
!
bgp router-id 192.168.255.5
bgp log-neighbor-changes
no bgp default ipv4-unicast
neighbor 192.168.255.7 remote-as 65000
neighbor 192.168.255.7 description CORRR-RT-01
neighbor 192.168.255.7 update-source Loopback99
!
address-family vpnv4
neighbor 192.168.255.7 activate
neighbor 192.168.255.7 send-community extended
exit-address-family
!
address-family ipv4 vrf TUSR
redistribute connected
redistribute static
exit-address-family
!
ip forward-protocol nd
no ip http server
no ip http secure-server
!
ip ssh version 2
!
control-plane
!
length 0
!
end

Routing Table for VRF on CSR

CORE_PE#show ip route vrf TUSR

Routing Table: TUSR
Codes: L – local, C – connected, S – static, R – RIP, M – mobile, B – BGP
D – EIGRP, EX – EIGRP external, O – OSPF, IA – OSPF inter area
N1 – OSPF NSSA external type 1, N2 – OSPF NSSA external type 2
E1 – OSPF external type 1, E2 – OSPF external type 2
i – IS-IS, su – IS-IS summary, L1 – IS-IS level-1, L2 – IS-IS level-2
ia – IS-IS inter area, * – candidate default, U – per-user static route
o – ODR, P – periodic downloaded static route, H – NHRP, l – LISP
a – application route
+ – replicated route, % – next hop override, p – overrides from PfR

Gateway of last resort is not set

2.0.0.0/32 is subnetted, 1 subnets
B 2.2.2.2 [200/0] via 192.168.255.3, 00:22:39
3.0.0.0/32 is subnetted, 1 subnets
C 3.3.3.3 is directly connected, Loopback17

Routing Table for VRF on vEOS
DTPCE-SWT-01#show ip route vrf TUSR

VRF: TUSR
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

Gateway of last resort is not set

C 2.2.2.2/32 is directly connected, Loopback17
B I 3.3.3.3/32 [200/0] via 192.168.255.5/32, LDP tunnel index 2, label 21
via 192.168.252.25, Ethernet1, label 17

DTPCE-SWT-01#

DTPCE-SWT-01#ping vrf TUSR 3.3.3.3
PING 3.3.3.3 (3.3.3.3) 72(100) bytes of data.

— 3.3.3.3 ping statistics —
5 packets transmitted, 0 received, 100% packet loss, time 42ms

DTPCE-SWT-01#

Ping CSR PE to CSR PE

CORE_PE#ping vrf TUSR 2.2.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 2/2/3 ms
CORE_PE#

Any assistance would be appreciated

0
Posted by Aniket Bhowmick
Answered on February 29, 2020 4:58 am

Hi Timothy,

Thanks for reaching out to us. !

First thing we need to check is if the route is programmed in the software/kernel or not.

Can you share the following output:

  • show kernel ip route vrf TUSR

Also, I don't see the following command being configured in the running config you shared:

"service routing protocols model multi-agent"

This is a mandatory command to use multi-protocol BGP feature. Can you confirm if this command is configured ?

It will be great if you can share the "show tech-support | no"  for our reference.

Thanks,

Aniket

0
Posted by Timothy Patrick
Answered on February 29, 2020 9:22 pm

Thanks for the response Aniket, I  can definitely post the info requested.  Trying a few things out I  did notice something.  If I  look at the vlan table:

DTCPE-SW-01(config-if-Et3)#show vlan bri
VLAN Name Status Ports
----- -------------------------------- --------- -------------------------------
1 default active Et2, Et3, Mt1
17 VLAN0017 active Cpu, Mt1

ip address table

DTCPE-SW-01(config-if-Et3)#show ip int bri
Address
Interface IP Address Status Protocol MTU Owner
----------------- ----------------------- ------------ -------------- ----------- -------
Ethernet1 192.168.252.26/30 up up 1500
Loopback17 2.2.2.2/32 up up 65535
Loopback99 192.168.255.3/32 up up 65535
Management1 192.168.248.67/24 up up 1500
Vlan17 5.5.5.1/24 up up 1478

and the routing table for VRF TUSR

C 2.2.2.2/32 is directly connected, Loopback17
B I 3.3.3.3/32 [200/0] via 192.168.255.5/32, LDP tunnel index 2, label 125162
via 192.168.252.25, Ethernet1, label 19
C 5.5.5.0/24 is directly connected, Vlan17
B I 8.8.8.0/24 [200/0] via 192.168.255.5/32, LDP tunnel index 2, label 125162
via 192.168.252.25, Ethernet1, label 19

everything looks good but I  can not ping any of the ip address learned by BGP (8.8.8.1, 3.3.3.3)

 

DTCPE-SW-01(config-if-Et3)#ping vrf TUSR 3.3.3.3
PING 3.3.3.3 (3.3.3.3) 72(100) bytes of data.

--- 3.3.3.3 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 44ms

DTCPE-SW-01(config-if-Et3)#ping vrf TUSR 8.8.8.1
PING 8.8.8.1 (8.8.8.1) 72(100) bytes of data.

--- 8.8.8.1 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 44ms

 

but if add an interface into vlan17 as well as add in interface on the other side I  can ping

DTCPE-SW-01(config-if-Et3)#switchport access vlan 17

 

DTCPE-SW-01(config-if-Et3)#ping vrf TUSR 3.3.3.3
PING 3.3.3.3 (3.3.3.3) 72(100) bytes of data.
80 bytes from 3.3.3.3: icmp_seq=1 ttl=64 time=13.0 ms
80 bytes from 3.3.3.3: icmp_seq=2 ttl=64 time=19.4 ms
80 bytes from 3.3.3.3: icmp_seq=3 ttl=64 time=18.8 ms
80 bytes from 3.3.3.3: icmp_seq=4 ttl=64 time=15.9 ms
80 bytes from 3.3.3.3: icmp_seq=5 ttl=64 time=13.9 ms

--- 3.3.3.3 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 57ms
rtt min/avg/max/mdev = 13.026/16.258/19.415/2.546 ms, pipe 2, ipg/ewma 14.428/14.565 ms
DTCPE-SW-01(config-if-Et3)#ping vrf TUSR 8.8.8.1
PING 8.8.8.1 (8.8.8.1) 72(100) bytes of data.
80 bytes from 8.8.8.1: icmp_seq=1 ttl=64 time=15.3 ms
80 bytes from 8.8.8.1: icmp_seq=2 ttl=64 time=13.3 ms
80 bytes from 8.8.8.1: icmp_seq=3 ttl=64 time=12.8 ms
80 bytes from 8.8.8.1: icmp_seq=4 ttl=64 time=12.8 ms
80 bytes from 8.8.8.1: icmp_seq=5 ttl=64 time=12.6 ms

--- 8.8.8.1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 60ms
rtt min/avg/max/mdev = 12.644/13.420/15.386/1.015 ms, pipe 2, ipg/ewma 15.009/14.355 ms

So for the VLAN interfaces I  could understand because the interface would be up/down if not active ports or trunks were associated with the vlan but I  don't understand why it would be that way for the loopback interfaces.

The strange thing is that I  can have a vlan interface show up/up on the vEOS even if there are no ports in the VLAN

 

Hi Timothy!

I was testing the same today with a similar topo as yours and the key point is what you've already found!. You need an Ethernet interface in that VRF to make things work, having only an SVI or loopback in that VRF you'll have only partial L3 functionality. Can't exactly remember why, but pinged the mpls gurus and can find out!

As soon as I connected a host to my vEOS instance everything started to work. The vlan was up because it was attached to the Mt1 (mpls tunnel) interface (if you have at least one port besides Cpu, the SVI should be active, which doesn't necessarily mean that traffic forwarding will work). This was a good exercise! :)
Thanks,
Tamas

(Tamas Plugor at February 29, 2020 9:36 pm)
1
Posted by Aniket Bhowmick
Answered on March 1, 2020 3:54 am

Hi Timothy,

This behaviour (VPN route not programmed in software if there is no Physical interface in vlan) is nothing new and have seen in multiple cases and testings. I understand there it doesn't make sense that the SVI shows as up (when only ma1 was present) but still the routes are not programmed. From a discussion it was found that if there is no Physical interface in any of the Vlan, then the VRF is not active in the kernel space. There should be atleast one Vlan/SVI in the vrf which has a L2 port to make the VRF active.

You can see whether the route is programmed in Kernel or not using the command- "show kernel ip route vrf <vrf>"

The route will show as "blackhole" in the above output if VRF is not active.

Once the VRF is active (after ensuring there is a L2 port present in Vlan), the VPN-v4 routes are programmed in Kernel successfully pointing.

Thanks,
Aniket

Aniket, would you suspect the same results(Traffic not passing) if a port channel was used ln lieu of a physical port? I was able to bring up the port-channel and ping across it with layer 2 but not ping from the VRF to the other VRF across PE-P-PE routers.

The route looks to be programmed In the kernal

blackhole 0.0.0.0/8 proto gated scope nowhere 
10.252.249.40/29 dev vlan2199 proto kernel scope link src 10.252.249.41  ** This Works across Port Channel **
unreachable 127.0.0.0/8 proto gated scope nowhere 
182.168.232.0/24 dev fwd0 proto gated  ** Times Out **
VRF: RBIO

Again if I remove the port channel and go back to the physical port it works. I am using Ver 4.22.3M as I l know there are issues with Trunking in the 4.23 code.

1     default                          active    Mt1
1699  VLAN1699                         active    Cpu, Et3, Mt1
2199  VLAN2199                         active    Cpu, Mt1, Po101

(Timothy Patrick at March 3, 2020 3:28 am)
in vEOS-lab you'll need a front-panel facing port, if you just connect a host (a VPC) for example you should be good, you can just do something like
interface ethernet3
   description Host1
   switchport access vlan 17

note that you don't actually have to configure vrf forwarding TUSR on the interface, because the SVI is already in it. that works fine for me, can ping from PE to PE in vrf and from host to host too

(Tamas Plugor at March 3, 2020 1:02 pm)
0
Posted by Timothy Patrick
Answered on March 1, 2020 10:30 pm

Thank you both for your responses. I  appreciate you both taking the time to look at this. Is similar tricks to working with port channels in vEOS I  have another post in the forum with issues pinging a vlan interface across a port channel. If I  remove the port channel and just bring up a vlan with the physical interface I  can  ping across vlan interface. I  was hoping to bring up a couple of vEOS without having to a ton og interfaces so I  was hoping to take advantage of the port channel solution.

 

Thanks Again!!!

Post your Answer

You must be logged in to post an answer.