cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
416
Views
0
Helpful
1
Replies

Delete extcommunity not working for attribs announced by unwary ASes

decode.chr13
Level 1
Level 1

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

 

1 Reply 1

decode.chr13
Level 1
Level 1

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.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: