search

FRRouting / frr

The FRRouting Protocol Suite
https://frrouting.org/
Other
3.33k stars 1.25k forks source link

FRR send type3 IMET route without pmsi informations #1487

Closed auranext closed 6 years ago

auranext commented 6 years ago

Hi all,

I'm using frr 3.1 (master) on debian 8 Jessie for interoperability tests with HPE 5940 hardware VTEP The goal is to automate the creation of VTEP tunnels based on EVPN informations at this point I can tell

I notice that the Debian VTEP send type3 IMET route without pmsi informations I guess the HPE device requires the pmsi informations to mount the tunnel on its side.

as FRR wiki says pmsi support has been (or will be ?) introduced in MASTER branch https://github.com/FRRouting/frr/wiki/Major-Changes

Is it a bug ? Is pmsi field actually supported ? If yes how I can use it ?

thank you for this nice project best regards

debian-10Gbps-CLI# show bgp l2vpn evpn vni 
Advertise Gateway Macip: Enabled
Advertise All VNI flag: Enabled
Number of VNIs: 1
Flags: * - Kernel
  VNI        Orig IP         RD                    Import RT                 Export RT                
* 2          55.5.5.5        1:2                   400:2                     400:2           
debian-10Gbps-CLI# show evpn vni 2 
VNI: 2
 VxLAN interface: vxlan2 ifIndex: 16 VTEP IP: 55.5.5.5
 Remote VTEPs for this VNI:
  50.1.1.2
  51.2.1.1
 Number of MACs (local and remote) known for this VNI: 2
 Number of ARPs (IPv4 and IPv6, local and remote) known for this VNI: 0
 Advertise-gw-macip: No
BGP neighbor is 51.2.0.2, remote AS 400, local AS 400, internal link
 Member of peer-group fabric for session parameters
  BGP version 4, remote router ID 51.2.0.2
  BGP state = Established, up for 00:22:58
  Last read 00:00:00, Last write 00:00:01
  Hold time is 9, keepalive interval is 3 seconds
  Neighbor capabilities:
    4 Byte AS: advertised and received
    AddPath:
      L2VPN EVPN: RX advertised L2VPN EVPN
    Dynamic: advertised
    Route refresh: advertised and received(new)
    Address Family L2VPN EVPN: advertised and received
    Hostname Capability: advertised (name: debian-10Gbps-CLI, domain name: (none)) not received
    Graceful Restart Capabilty: advertised
  Message statistics:
    Inq depth is 0
    Outq depth is 0
                         Sent       Rcvd
    Opens:                  5          5
    Notifications:          4          0
    Updates:                5       5343
    Keepalives:         69859      83772
    Route Refresh:          0          0
    Capability:             0          0
    Total:              69873      89120
  Minimum time between advertisement runs is 0 seconds
  Update source is 55.5.5.5

 For address family: L2VPN EVPN
  fabric peer-group member
  Update group 5, subgroup 5
  Packet Queue length 0
  Community attribute sent to this neighbor(all)
  advertise-all-vni
  196 accepted prefixes

  Connections established 5; dropped 4
  Last reset 00:23:00, due to User reset
Local host: 55.5.5.5, Local port: 179
Foreign host: 51.2.0.2, Foreign port: 18548
Nexthop: 55.5.5.5
Nexthop global: ::
Nexthop local: ::
BGP connection: non shared network
BGP Connect Retry Timer in Seconds: 10
Read thread: on  Write thread: off
donaldsharp commented 6 years ago

@vivek-cumulus @mkanjari can you take a second to look at this issue?

auranext commented 6 years ago

HPE feedback confirm the HPE 5940 device behavior :

HPE 5940 devices support Type 3 routes and wait for PMSI parameters, which are used to mount the tunnel.

image

mkanjari commented 6 years ago

FRR doesn't support PMSI attribute. currently, it only carries RD, Ethernet-Tag(0), ip-address len and IP address (local tunnel IP). FRR only supports ingress replication with VxLan-EVPN. I guess since we only support ingress replication we dont really need the attribute. " When the Tunnel Type is set to Ingress Replication, the Tunnel Identifier carries the unicast tunnel endpoint IP address of the local PE that is to be this PE's receiving endpoint address for the tunnel." Here the unicast tunnel ip is already present in originator's ip address in the IMET route.

auranext commented 6 years ago

thank you for this clarification However it seems type 3 route must also carry a Provider Multicast Service Interface (PMSI) Tunnel attribute as specified in RFC 6514 the FRR roadmap announce the RFC 6514 compliance in version 3 With this consideration can you give me a clarification I anderstand pmsi field actually not supported, but it will be or not ?

auranext commented 6 years ago

Just for confirmation : With scapy I tried by injecting PMSI attributes into the (FRR) BGP UPDATE message and it works The HPE-5940 VTEP bring up his VXLAN tunnel interface

auranext commented 6 years ago

Could you clarify this information the FRR roadmap announce the RFC 6514 compliance in version 3 With the conversation consideration can you give me a clarification I anderstand pmsi field actually not supported, but it will be or not ? @donaldsharp

mkanjari commented 6 years ago

As far as I know, PMSI attribute support for VxLan-EVPN implementation is not planned for near future. Adding @vivek-cumulus for future roadmap.

lamehost commented 6 years ago

Hello,

@mkanjari

I guess since we only support ingress replication we dont really need the attribute.

I may be wrong, but i think you do.

RFC7432 paragraph 11.2 states:

  • If the PE that originates the advertisement uses ingress replication for the P-tunnel for EVPN, the route MUST include the PMSI Tunnel attribute with the Tunnel Type set to Ingress Replication and the Tunnel Identifier set to a routable address of the PE. The PMSI Tunnel attribute MUST carry a downstream assigned MPLS label. This label is used to demultiplex the broadcast, multicast, or unknown unicast EVPN traffic received over an MP2P tunnel by the PE.

Anyway, we're facing similar issues with NX-OS as routers ignore the NLRI because of the missing attribute.

2017 Dec 14 07:44:07.792315 bgp: [29045] (default) UPD: [L2VPN EVPN] Received IMET route 192.0.2.3:1:[3]:[0]:[32]:[192.0.2.3] with missing PMSI attribute from peer 192.0.2.3, ignoring it

lamehost commented 6 years ago

@mkanjari, I noticed that my comment could be mis-interpreted as i mentioned RFC7432 wich is MPLS and we're dealing with VxLAN.

I don't think that PMSI is optional at all even if the carried information is the same as the originator's IP. Agreed that the information is redundant, but it is cited multiple times even in RFC6514.

mkanjari commented 6 years ago

@lamehost,

will discuss this with @vivek-cumulus and update soon.

lamehost commented 6 years ago

@mkanjari,

Just to be sure i checked with the authors of draft-ietf-bess-evpn-overlay-10. They agree you should attach the PMSI to IMET.

Regards

mkanjari commented 6 years ago

@lamehost, Synced up with @vivek-cumulus. We will be addressing this soon. If we don't have a bug/feature request request for this already, can you please create one ?

dwiesner commented 6 years ago

Hello, I recently tested against a Nokia 7750 SR as hardware VTEP. The 7750 will not forward any multicast/broadcast traffic to FRR because the PMSI_TUNNEL attribute is missing. Adding the PMSI attribute to IMET routes generated by FRR solves this.

This is the patch I did for my test: https://github.com/dwiesner/frr/commit/79a698daefe543595861c5c111a813e78062878d

donaldsharp commented 6 years ago

@dwiesner -> This looks awesome. I would suggest submitting a PR. Additionally you need to Sign-off the commit as outlined in COMMUNITY.md ( https://github.com/FRRouting/frr/blob/master/COMMUNITY.md ). If you have any questions feel free to ask here and we'll get you set up.