]> git.puffer.fish Git - mirror/frr.git/commit
bgpd: parse label in pmsi tunnel attribute 3788/head
authorAnuradha Karuppiah <anuradhak@cumulusnetworks.com>
Tue, 12 Feb 2019 20:56:26 +0000 (12:56 -0800)
committerAnuradha Karuppiah <anuradhak@cumulusnetworks.com>
Tue, 12 Feb 2019 21:06:59 +0000 (13:06 -0800)
commit355f3c1174a9859697c89b3c07844225df29db41
tree466af3ba038cc6377c7b6b7d7d2ba2fc526d72b2
parent27f28cccedae6ccec45a6606536ac212ab063cb5
bgpd: parse label in pmsi tunnel attribute

Consider the following topo VTEP1->SPINE1->VTEP2. ebgp is being used
for evpn route exchange with SPINE just acting as a pass through.

1. VTEP1 was building the type-3 IMET route with the correct PMSI
tunnel type (ingress-replication) and label (VNI)
2. Spine1 was however only parsing the tunnel-type in the attr (was
skipping parsing of the label field altogether) -
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
root@MSP1:~# net show bgp l2vpn evpn route rd 27.0.0.15:4 type multicast
EVPN type-2 prefix: [2]:[ESI]:[EthTag]:[MAClen]:[MAC]
EVPN type-3 prefix: [3]:[EthTag]:[IPlen]:[OrigIP]
EVPN type-5 prefix: [5]:[ESI]:[EthTag]:[IPlen]:[IP]

BGP routing table entry for 27.0.0.15:4:[3]:[0]:[32]:[27.0.0.15]
Paths: (1 available, best #1)
  Advertised to non peer-group peers:
  TORC11(downlink-1) TORC12(downlink-2) TORC21(downlink-3) TORC22(downlink-4) TORS1(downlink-5) TORS2(downlink-6)
  Route [3]:[0]:[32]:[27.0.0.15]
  5550
    27.0.0.15 from TORS1(downlink-5) (27.0.0.15)
      Origin IGP, valid, external, bestpath-from-AS 5550, best
      Extended Community: RT:5550:1003 ET:8
      AddPath ID: RX 0, TX 227
      Last update: Thu Feb  7 15:44:22 2019
      PMSI Tunnel Type: Ingress Replication, label: 16777213 >>>>>>>

Displayed 1 prefixes (1 paths) with this RD (of requested type)
root@MSP1:~#
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
3. So VTEP2 didn't rx the correct label.

In an all FRR setup this doesn't have any functional consequence but some
vendors are validating the content of the label field as well and ignoring
the IMET route from FRR (say VTEP1 is FRR and VTEP2 is 3rd-party). The
functional consequence of this VTEP2 ignores VTEP1's IMET route and doesn't
add VTEP1 to the corresponding l2-vni flood list.

This commit fixes up the PMSI attr parsing on spine-1 -
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
root@MSP1:~# net show bgp l2vpn evpn route rd 27.0.0.15:4 type multicast
EVPN type-2 prefix: [2]:[ESI]:[EthTag]:[MAClen]:[MAC]
EVPN type-3 prefix: [3]:[EthTag]:[IPlen]:[OrigIP]
EVPN type-5 prefix: [5]:[ESI]:[EthTag]:[IPlen]:[IP]

BGP routing table entry for 27.0.0.15:4:[3]:[0]:[32]:[27.0.0.15]
Paths: (1 available, best #1)
  Advertised to non peer-group peers:
  TORC11(downlink-1) TORC12(downlink-2) TORC21(downlink-3) TORC22(downlink-4) TORS1(downlink-5) TORS2(downlink-6)
  Route [3]:[0]:[32]:[27.0.0.15]
  5550
    27.0.0.15 from TORS1(downlink-5) (27.0.0.15)
      Origin IGP, valid, external, bestpath-from-AS 5550, best
      Extended Community: RT:5550:1003 ET:8
      AddPath ID: RX 0, TX 278
      Last update: Thu Feb  7 00:17:40 2019
      PMSI Tunnel Type: Ingress Replication, label: 1003 >>>>>>>>>>>

Displayed 1 prefixes (1 paths) with this RD (of requested type)
root@MSP1:~#
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Ticket: CM-23790

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
bgpd/bgp_attr.c