Closed auranext closed 6 years ago
@vivek-cumulus @mkanjari can you take a second to look at this issue?
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.
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.
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 ?
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
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
As far as I know, PMSI attribute support for VxLan-EVPN implementation is not planned for near future. Adding @vivek-cumulus for future roadmap.
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
@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.
@lamehost,
will discuss this with @vivek-cumulus and update soon.
@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
@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 ?
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
@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.
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