In order to reannounce those tagged routes, I created the following routing filter:
/routing filter
(...)
add action=accept bgp-communities=MYASN:100 chain=IXPTRANSIT-OUT comment="Reannounce prefixes with BGP community MYASN:100"
add action=discard chain=IXPTRANSIT-OUT
I applied that filter to the BGP session on which I’d like to reannounce the routes learnt, but my RB does not reannounce anything (even if I remove the discard action in my IXPTRANSIT-OUT routing filter).
Both BGP sessions are in the same instance. I do not have any other instance running, the default one is disabled.
Here is a more complete extract of the config (I didnt paste the whole Equinix sessions, just 3 for the example): MYPREFIX#n and MYCUSTPREFIX#n are real IP networks on the config, same for MYASN or MYCUSTASN which are real 16bit ASN
/routing bgp instance
set default disabled=yes
add as=MYASN client-to-client-reflection=no name=Vedege redistribute-other-bgp=yes router-id=194.117.xxx.xxx
/routing filter
add action=accept append-bgp-communities=MYASN:100 chain=EQUINIX-IN comment="Add BGP communitie MYASN:100 to peering routes" set-bgp-local-pref=400 set-bgp-med=10 set-route-comment=EQUINIX
add action=accept chain=EQUINIX-OUT prefix=MYPREFIX#1 prefix-length=23
add action=accept chain=EQUINIX-OUT prefix=MYPREFIX#2 prefix-length=22
add action=discard chain=EQUINIX-OUT
(...)
add action=accept append-bgp-communities=MYASN:5000 chain=CUST-IN comment="Accept route #1 from AW, and set 600 for localpref, and append MYASN:5000 community" prefix=MYCUSTPREFIX#1 set-bgp-local-pref=600
add action=accept append-bgp-communities=MYASN:5000 chain=CUST-IN comment="Accept route #2 from AW, and set 600 for localpref, and append MYASN:5000 community" prefix=MYCUSTPREFIX#2 set-bgp-local-pref=600
add action=accept append-bgp-communities=MYASN:5000 chain=CUST-IN comment="Accept route #3 from AW, and set 600 for localpref, and append MYASN:5000 community" prefix=MYCUSTPREFIX#3 set-bgp-local-pref=600
add action=discard chain=CUST-IN comment="Deny any at the end"
add action=accept append-bgp-communities="" bgp-communities=MYASN:100 chain=IXPTRANSIT-OUT comment="Reannounce prefixes with BGP community MYASN:100" match-chain=""
add action=discard chain=IXPTRANSIT-OUT
/routing bgp peer
add comment="Peering Equinix HE IPv4" in-filter=EQUINIX-IN instance=Vedege max-prefix-limit=100000 max-prefix-restart-time=15m name=peering-eqx-he-ipv4 out-filter=EQUINIX-OUT remote-address=195.42.144.104 remote-as=6939 ttl=default
add comment="Peering Equinix Widevoip IPv4" in-filter=EQUINIX-IN instance=Vedege max-prefix-limit=100 max-prefix-restart-time=15m name=peering-eqx-widevoip-ipv4 out-filter= EQUINIX-OUT remote-address=195.42.144.16 remote-as=42456 ttl=default
add comment="Peering Equinix Renater IPv4" in-filter=EQUINIX-IN instance=Vedege max-prefix-limit=1000 max-prefix-restart-time=15m name=peering-eqx-renater-ipv4 out-filter=EQUINIX-OUT remote-address=195.42.145.38 remote-as=2200 tcp-md5-key=xxxxxxxxx ttl=default
(...)
add comment="Transit partial Cust" in-filter=CUST-IN instance=Vedege name=transitpartial-aw-ipv4 out-filter=IXPTRANSIT-OUT remote-address=185.56.xx.xx remote-as=MYCUSTASN ttl=default
We do something similar, tag communities (append) on inbound routes, and use this info in filters to outbound routes .
one thing I have noticed is that when you append communities, e.g. a route has multiple communities on it, the MT filters don’t work…
However, this is not a problem if you are not appending but replacing communities (i.e. only one community tag on the route)
But what gets even more interesting is that, if your filters are setup to use two parameters to identify the route, (e.g. prefix & bgp-communities or AS# and Communities.) then the filters work correctly (with the multiple community tags on the route).
We have had to become creative in working around this…
BTW, I see you are tagging your route with a Comment… you can use that in your filter as well, not elegant, but it will work.
if you are going to use Route Comment, then just use Route Comment, and not communities, in your filter.
Make sure that the route is active on your router, that you are advertising from.
I had a couple of more options available to select the routes.
e.g. ASN on the peering fabric
chain=xx-mia-out bgp-as-path=^12345_* bgp-communities=“” invert-match=no
action=accept set-bgp-prepend-path=“” append-bgp-communities=“”
add action=accept append-bgp-communities="" bgp-communities=MYASN:100 chain=IXPTRANSIT-OUT comment="Reannounce prefixes with BGP community MYASN:100" match-chain=""
I think the issue is that your appending a blank community in the same filter rule as your match. I seem to remember having a similar issue once before. Try changing this to set-bgp-communities=“” if the desired action is to remove the community before advertizing it. If that still doesn’t work you could use the match rules to jump into a chain with one rule to accept and remove the community.
While setting up a new CCR1015-12G (running 6.38.1) for a client, I seem to be running into a variant(?) of this.
What I’m doing is very simple and done fairly frequently in Carrier networking. Learn routes from upstream, tag them with ASN:, and then match that tag when sending the route to another peer.
Good news (at least in my case) is that it seems to partially work, but seems to ignore prefixes (with completely same/similar attributes) at random. I tried the comment hack posted, matches the same routes…
Is the MT filtering implementation really this wonky? =/
)