05-24-2023 12:30 AM
Hello,
Our peering network is build over SR EVPN using https://xrdocs.io/design/blogs/latest-peering-fabric-hld architecture, using Internet in a VRF and l2vpn evpn address family.
After migrating first peering router (leaf) we started seeing in aggregation routers (spine) cef unresolved prefixes.
Our peering inbound route-policy has among others also this statements:
delete extcommunity rt all
delete extcommunity color all
delete extcommunity bandwidth all
delete extcommunity soo all
Looking closely at this prefixes we see that extcommunity contain Vxlan attributes:
Extended community: Encapsulation Type:8 Router MAC:0000.ac15.c605 RT:8423:xxx
BGP routing table entry for 92.40.182.0/23, Route Distinguisher: 8423:xxx
Paths: (1 available, best #1)
Not advertised to any peer
Path #1: Received by speaker 0
Not advertised to any peer
39737 3.9459
89.47.225.109 from 89.47.225.109 (89.44.235.4)
Origin incomplete, metric 0, localpref 2000, valid, external, best, group-best, import-candidate
Received Path ID 0, Local Path ID 1, version 31182232
Community: 8714:65010 8714:65012 39737:1 39737:40207
Large Community: 8423:39737:2000
Extended community: Encapsulation Type:8 Router MAC:0000.ac15.c605 RT:8423:xxx
Of course because our aggregation routers do not have that mac address the CEF cannot resolve next hop, so our temporary solution is to drop all this prefixes at the peering point. The bad thing is we have to look for CEF unresolved errors and add these prefixes manually to drop prefix-set
We were seeing the same at different looking glasses (Telia, Level3, etc), but now when writing this I see that they are also dropping some of these prefixes.
Example of one still present in Telia:
https://lg.twelve99.net/?type=bgp&router=ffm-b5&address=107.6.127.0/24
So far our prefix-set looks like this:
prefix-set bgp-drop-bad-attributes-prefix
# AS32475
107.6.127.0/24,
# AS18526
158.51.111.0/24,
# AS49981
191.96.128.0/24,
# AS8315
193.189.141.0/24,
# AS206216
194.87.169.0/24,
# AS20326
208.91.108.0/23 ge 24,
# AS206067
94.197.104.0/21,
188.30.0.0/15 ge 21,
92.40.0.0/15 ge 21
end-set
Surprisingly one of the ASes is a big mobile provider from UK...
My questions in this matter would be:
1) Is there a different "delete/overwrite" statement that we can use in inbound policy to delete the attributes?
2) Is there a way to match prefixes with these attributes so we can automatically drop them?
3) If Q1/Q2 has no answer, is it possible to implement in future software?
Thanks
06-14-2023 03:09 AM
Solved by migrating back to VPNv4/v6 families from L2VPN EVPN for the moment.
If there are solutions in the future, maybe you can update this topic.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide