I’m facing an irritating issue with bgp and communities.
I receive some routes from a peer, I set a bgp (extended) community and prefix length (21-24) on them. I receive the routes accordingly (ip route print detail where received-from=PEER shows all prefixes and bgp-ext-communities set)
Next I advertise these routes to another peer using this community but only prefixes 21 and 22 are advertised, the /24 prefixes are not. There are no prefix length filter affecting this advertisement.
If I advertise the /24 prefixes manually they work as expected.
Is anyone facing this same issue?
add in 08/11/2017
All peers are eBGP (different AS numbers)
The routes that are recieved will be announced to an Ibgp peer (requiring full mesh of all ibgp routers). Only active will be anounced from i ibgp route reflect perspective when using RR.
the ebgp perspective is controlled by the networks statments in the bgp instance. Syncronice controlling that nets are reachable before announcing ie: active rotes
So for clarity, there’s R1 (the router where you’re doing this configuration), Peer1 (the one sending you the /21../24 prefixes) and Peer2, which is the one that R1 refuses to send /24 prefixes to unless you manually originate them at R1.
Is Peer2 advertising paths to the /24 prefixes to R1? If so, and if R1 prefers Peer2 to reach these prefixes, then R1 is not going to advertise this path to Peer2 because Peer2 is the actual route to the destination that R1 would use.
Do you mean that you’re not supposed to be receiving routes from peer2 or that you actually are not?
Here’s my line of thinking:
if there’s no filtering involved, then eBGP will send everything in the table to any other eBGP peer, except for the prefixes which were learned from the other peer which are superior to any other paths in the table. Your filters obviously permit the prefix because if you originate the route yourself, then your router will advertise the /24. The reason this would override a path learned from Peer2 is because the BGP best path selection algorithm. 1: use highest weight (almost certainly irrelevant). 2: use highest local_pref. (almost certainly irrelevant). 3: prefer paths originated within the self-same router. This step #3 would mean that your own originated /24 would trump any paths learned from eBGP so long as your in-filters aren’t doing anything with weight or local_pref.
It could be other things, of course. The next most likely case is that the in-filter you have configured on Peer1 isn’t doing something quite right.
Does it show that all of these prefixes are active in the routing table?
If the /24 prefixes learned from PEER aren’t actually active in the routing table, then this means that some other source’s routes are being preferred over the ones learned from Peer1. I was thinking that perhaps your in-filter from Peer1 was not applying the community to the /24 prefixes but when I re-read the above from your original post, this seems to not be the case.
Another possibility is that there may be some OTHER prefix getting applied to the /24 prefixes which are interfering with their ability to pass the out-filter on Peer2.
One thing about the above statement isn’t quite clear in my mind: What do you mean when you say that you set a prefix length? You can’t (to my knowledge) modify the prefix length on paths learned. I assume that you are referring to the third blank on the “Matchers” tab in the filter rule, “Prefix Length:” I just want to make sure that you’re clear in your understanding that the fields in the “Matchers” tab don’t actually do anything to prefixes. They are constraints on the prefixes which will match the rule. Fields in the “Actions” and “BGP Actions” are the only ones which apply any values or changes to the prefixes learned/sent by the router.
Anyway, if you check into these and still see everything seems correct, then I suggest your next post include the relevant excerpts from the following exports:
/routing bgp peers export (just post the entries having to do with Peer1 and Peer2 - feel free to sanitize the information a little bit)
/routing filter export (same as above - only include commands having to do with any filters on Peer1, Peer2, or the local BGP process’s out-filter
/ip route print detail where dst-address in x.x.x.0/21 (if there are multiple /21 blocks, then do this for each of them, obviously)
Finally, I will say that I’ve been involved with threads here where it ends up being a bug in the behavior of the ROS implementation of various routing protocols. Your case could be such a one.
Okay - I’ve removed the chain name and some defaults that get shown in exports to make the above a little more readable for further discussion.
I think the problem comes from rules 0 and 1. Unfortunately, you did not post the contents of the chains they jump into, but I suspect that’s because you didn’t realize they were getting called on your customer’s routes.
Analysis of your rule chain:
In English, rule 0 could be stated like this: "For all prefixes of length 21: Do no as-path prepending, override the prefix’s extended communities with values 65000:12989 + 65000:266347. After doing this, go into filter chain “myown-ipv4-prefixos1-allow” for further processing.
Rule 1 is the same, but jumps into chain …prefixos2… for all prefixes of length 24.
Rule 2 says allow all routes whose extended community is 65003:50
Rule 3 says allow all routes whose extended community is 65003:80
Finally, rule 5 is the default-reject.
The way this is built, ALL prefixes of length 21 match rule 0 (including your customer’s prefixes of that length. Note that they’ll be re-tagged with the ones specified in rule 1)
ALL prefixes of length 24 match rule 1, get their communities re-assigned, and go into the prefixos2 chain.
I suspect that something in the chain “myown-ipv4-prefix0s2-allow” is the problem.
Here’s what is happening:
Your customer’s’ /21 prefix(es) are getting re-branded with your own extended community by rule 0, and then eventually being permitted by something in my-own-prefixos1.
Your customer’s /22 and /23 prefixes don’t match rules 0 or 1, so they get accepted by rule 3 (and are not re-branded)
Your customer’s /24 prefixes get re-branded by rule 1, and then further scrutinized by the my-prefixos2 chain, which is apparently not accepting your customer’s /24 prefixes.
Don’t forget how rule chains work (here and in firewalls too)
If all match criteria are true, then all actions of that rule are performed on the item in question.
Your rules 0 and 1 have only one criteria: prefix-length must be 21 or 24, respectively. No other criteria are specified.
If you trust your in-filters from your customers to always be correct, then you can fix this quite easily by moving the “allow routes with customer extended communities” rules to earlier positions in this chain than your rules that filter your own prefixes. This means that if there’s a route stamped with extended community 65003:80, you trust that the stamp is valid and send whatever the prefix is.