Open Paikanx opened 4 years ago
EVPN-MPLS is not currently supported but it's something I'm working on. I ssupect there is some VXLAN-based check that is going on in your reflector which is causing these routes to be binned. If you get a moment could you attach bgp logs for the failiing period, perhaps with debug bgp zebra
enabled and maybe we can fix it for the RR case.
Hello,
Thanks for your answer, below is the output of various debug commands (including those you asked). As far as i can see, 'debug bgp zebra' send no output:
# show deb
Zebra debugging status:
Zebra EVPN-MH ethernet segment debugging is on
Zebra EVPN-MH nexthop debugging is on
BGP debugging status:
BGP zebra debugging is on
BGP EVPN-MH ES debugging is on
BGP EVPN-MH route debugging is on
2020/10/14 09:51:16 BGP: [EC 33554501] 10.255.255.255 Unexpected afi/safi/next-hop afi: IPv4/multicast/2 in Extended Next-hop capability, ignoring
2020/10/14 09:51:16 BGP: %ADJCHANGE: neighbor 10.255.255.255(Unknown) in vrf default Up
2020/10/14 09:51:21 BGP: 10.255.255.255 rcvd UPDATE w/ attr: nexthop 10.255.255.255, localpref 100, extcommunity RT:65000:4058 ESI-label-Rt:AA, path
2020/10/14 09:51:21 BGP: 10.255.255.255 rcvd UPDATE wlen 0 attrlen 73 alen 0
2020/10/14 09:51:21 BGP: 10.255.255.255 rcvd RD 10.255.255.255:1 Unsupported EVPN prefix l2vpn evpn
2020/10/14 09:51:21 BGP: 10.255.255.255 rcvd UPDATE w/ attr: nexthop 10.255.255.255, localpref 100, extcommunity ES-Import-Rt:1c:34:da:96:12:ed UNK:6, 0, path
2020/10/14 09:51:21 BGP: 10.255.255.255 rcvd UPDATE wlen 0 attrlen 71 alen 0
2020/10/14 09:51:21 BGP: 10.255.255.255 rcvd RD 10.255.255.255:0 [4]:[01:1c:34:da:96:12:ed:00:0f:00]:[10.255.255.255]/320 l2vpn evpn
2020/10/14 09:51:21 BGP: 10.255.255.255 rcvd UPDATE w/ attr: nexthop 10.255.255.255, localpref 100, extcommunity RT:65000:4058, path
2020/10/14 09:51:21 BGP: 10.255.255.255 rcvd UPDATE wlen 0 attrlen 65 alen 0
2020/10/14 09:51:21 BGP: 10.255.255.255 rcvd RD 10.255.255.255:4058 Unsupported EVPN prefix l2vpn evpn
2020/10/14 09:51:21 BGP: 10.255.255.255 rcvd UPDATE w/ attr: nexthop 10.255.255.255, localpref 100, extcommunity RT:65000:4058 SoO:10.255.255.255:4058, path
2020/10/14 09:51:21 BGP: 10.255.255.255 rcvd UPDATE wlen 0 attrlen 81 alen 0
2020/10/14 09:51:21 BGP: 10.255.255.255 rcvd RD 10.255.255.255:4058 [2]:[1c:34:da:96:12:ec]/320 label 384017 l2vpn evpn
2020/10/14 09:51:21 BGP: 10.255.255.255 rcvd UPDATE w/ attr: nexthop 10.255.255.255, localpref 100, extcommunity RT:65000:4058, pmsi tnltype 6, path
2020/10/14 09:51:21 BGP: 10.255.255.255 rcvd UPDATE wlen 0 attrlen 69 alen 0
2020/10/14 09:51:21 BGP: 10.255.255.255 rcvd RD 10.255.255.255:4058 [3]:[10.255.255.255]/320 l2vpn evpn
2020/10/14 09:51:21 BGP: 10.255.255.255 rcvd UPDATE wlen 0 attrlen 6 alen 0
2020/10/14 09:51:21 BGP: bgp_update_receive: rcvd End-of-RIB for L2VPN EVPN from 10.255.255.255 in vrf default
sorry missed this reply - I'll take a look at this when I get some cycles.
sorry missed this reply - I'll take a look at this when I get some cycles.
Hello,
Any news about RFC7432 implementation ?
Thanks,
[x] Did you check if this is a duplicate issue? [x] Did you test it on the latest FRRouting/frr master branch?
Describe the bug Hello, not sure if it's a bug or simply something that is not implemented yet. We are currently testing using FRR as Route Reflector for EVPN/MPLS. It works well as long as there is no ES used in the network. When ES is involved (either Single-homed or Multi-Homed) unicast trafic won't work if a host is in an ES. It seems to be due to FRR "eating" RT-1 MPLS label received from a peer:
Below is the BGP update message sent to FRR
And below is the BGP update send to other RR peer for the same ES-AD:
To Reproduce Steps to reproduce the behavior:
Local Outgoing Prefix Outgoing Next Hop Bytes Label Label or ID Interface Switched
25268 Exp-Null-v4 EVPN:4058 A.A.A.A 0 Exp-Null-v4 EVPN:4058 B.B.B.B 0