[c-nsp] EVPN/VXLAN on ASR9001 - BGP announcements not working

Gert Doering gert at greenie.muc.de
Sun Mar 29 05:52:03 EDT 2020


Hi,

I'm trying to make EVPN via VXLAN encapsulation work between two ASR9001
(with the goal of eventually making it work between ASR9001 and Arista
boxes, but right now I'm failing ASR9001 <-> ASR9001 already).

As warmup, I tried EVPN with MPLS encapsulation, and that is much better
documented and very straightforward to set up (basically, all the defaults
work - configure neighbours that have labels, ensure RDs match, attach
EVI <n> to bridge-domain <n>, done)... so, BGP works, IGP works, 
bridge-group setup works.


With VXLAN, it "should" be similarily straightforward, but I'm overlooking
something.  Namely, both sides create their l2vpn evpn BGP routes, and
the neighbours talk to each other, but neither side is willing to export
anything but Type 4 routes (ESI).

Tried with and without ESI config, without explicit RT config, with 
lots of different RT combinations... no avail, routers are not announcing.


The two boxes are 195.30.3.251 and 195.30.3.252 (you'll see that in the
RDs below, and redacting BGP output never helps debugging).

This is what I have in BGP right now on 195.30.3.252:

RP/0/RSP0/CPU0:M52#sh bgp l2vpn evpn 
...
   Network            Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 195.30.3.251:0
*>i[4][0040.0000.0000.0034.3502][32][195.30.3.251]/128
                      195.30.3.251                  100      0 i
Route Distinguisher: 195.30.3.252:0 (default for vrf ES:GLOBAL)
*> [1][195.30.3.252:1][0040.0000.0000.0052.0002][4294967295]/184
                      0.0.0.0                                0 i
*>i[4][0040.0000.0000.0034.3502][32][195.30.3.251]/128
                      195.30.3.251                  100      0 i
*> [4][0040.0000.0000.0052.0002][32][195.30.3.252]/128
                      0.0.0.0                                0 i
Route Distinguisher: 195.30.3.252:2799 (default for vrf v2799)
*> [1][0040.0000.0000.0052.0002][0]/120
                      0.0.0.0                                0 i
*> [2][0][48][3cfd.febd.7835][0]/104
                      0.0.0.0                                0 i
*> [2][0][48][3cfd.febd.7835][32][10.27.99.2]/136
                      0.0.0.0                                0 i
*> [2][0][48][a80c.0d56.503f][0]/104
                      0.0.0.0                                0 i
*> [3][0][32][195.30.3.252]/80
                      0.0.0.0                                0 i

P/0/RSP0/CPU0:M52#sh bgp l2vpn evpn su
Neighbor        Spk    AS MsgRcvd MsgSent   TblVer  InQ OutQ  Up/Down  St/PfxRcd
195.30.3.251      0  5539      21      21      480    0    0 00:15:28          1

RP/0/RSP0/CPU0:M52#sh bgp l2vpn evpn neigh 195.30.3.251 advertised-routes 
Sun Mar 29 11:37:43.281 MEDST
Network            Next Hop        From            AS Path
Route Distinguisher: 195.30.3.252:0
[4][0040.0000.0000.0052.0002][32][195.30.3.252]/128
                      195.30.3.252    Local           i

so both sides symmetrically announce the Type 4 ESI DR election route
(which isn't really relevant as all ESIs are single-homed right now),
but refuse to announce anything else.


The neighbour config is trivial:

interface Loopback30
 description VXLAN/EVPN endpoint
 ipv4 address 195.30.3.252 255.255.255.255

router bgp 5539
 neighbor 195.30.3.251
  remote-as 5539
  description m34/evpn-vxlan-test
  update-source Loopback30
  address-family l2vpn evpn
   encapsulation-type vxlan
  !
 !
!

(no matter of what policy statements or import/export statements I 
added there had any positive effect)


So is the EVPN config:

RP/0/RSP0/CPU0:M52#sh run evpn
Sun Mar 29 11:40:23.694 MEDST
evpn
 evi 2799
  bgp
  !
  advertise-mac
   bvi-mac
  !
 !
 interface TenGigE0/0/2/2
  ethernet-segment
   identifier type 0 40.00.00.00.00.00.52.00.02
  !
 !
 interface Bundle-Ether102
  ethernet-segment
   identifier type 0 40.00.00.00.00.00.52.00.01
  !
 !
 source interface Loopback30
!


no explicit configured RDs or RTs (I did try about everything...), but 
the default values seem to make sense, for example for the Type 3:

BGP routing table entry for [3][0][32][195.30.3.252]/80, Route Distinguisher: 195.30.3.252:2799
Versions:
  Process           bRIB/RIB  SendTblVer
  Speaker                480         480
Last Modified: Mar 29 11:23:56.823 for 00:18:44
Paths: (1 available, best #1)
  Not advertised to any peer
  Path #1: Received by speaker 0
  Not advertised to any peer
  Local
    0.0.0.0 from 0.0.0.0 (193.149.44.20)
      Origin IGP, localpref 100, valid, redistributed, best, group-best, import-candidate
      Received Path ID 0, Local Path ID 1, version 480
      Extended community: RT:5539:2799 
      PMSI: flags 0x00, type 6, label 24022, ID 0xc31e03fc


"Not advertised to any peer" << and *this*...


For reference, here's the bridge group and the NVE config, but those
are also trivial enough so I assume the issue is "in BGP", not somewhere
there:

l2vpn
 bridge group vlandb
  bridge-domain v2799
   interface TenGigE0/0/2/2.2799
   !
   routed interface BVI2799
   !
   evi 2799
   !
   member vni 102799
   !
  !

Interface nve1
 member vni 102799
  host-reachability protocol bgp
 !
 overlay-encapsulation vxlan
 source-interface Loopback30
!



Oh, finally, this is on 32bit IOS XR 6.5.3.sp2 - in case this matters...


So... any ideas or suggestions what to try next?  Or "just give up on 
this and go with EVPN/MPLS instead" (which would not help me with the
larger goal "connect a remote location that only has Arista gear")?

thanks,

gert

-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
                             Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany                             gert at greenie.muc.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 630 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20200329/a073c1a6/attachment-0001.sig>


More information about the cisco-nsp mailing list