BGP and Route Maps
This is a nice email I got from an engineer struggling with multi-homing BGP setup:
We faced a problem with our internet routers a few days back. The engineer who configured them earlier used the syntax: network x.x.x.x mask y.y.y.y route-map PREPEND to influence the incoming traffic over two service-providers.
... and of course it didn’t work.
We weren't getting the desired results so I changed the configuration from up above to: neighbor x.x.x.x route-map PREPEND and to my surprise everything started working fine as before. Is there a difference between to the two sets of configuration?
The network route-map command uses a route map to change the attributes of an IP prefix as it’s inserted in the BGP table. On Cisco IOS you can use that route map to set BGP communities and change MED, local preference and next hop (I wouldn’t change the next hop), but not AS-path. If the route-map doesn’t match the IP prefix, the attributes are not changed (but I wouldn’t use a route-map with a match statement in the network command anyway).
Neighbor route-map in|out command applies a route map to BGP updates received or sent to a neighbor. It’s not just an attribute modifying tool, it’s also a filter – if the route map doesn’t match a BGP prefix, the inbound update gets dropped before it’s inserted in the BGP table, or the BGP prefix never gets sent to the BGP neighbor.
Route map applied to a BGP neighbor can change most BGP attributes that make sense (example: you cannot change local preference if the neighbor is not in the same AS) and prepend AS numbers to the AS path (you’re not allowed to modify AS path directly, as that might bypass BGP loop prevention mechanisms).
On top of obvious sanity checks, the router applies the usual BGP route reflector safeguards: if the neighbor is a route reflector client, you cannot change any attributes of reflected routes with an outbound route-map (but you can change attributes of routes you’ve received from EBGP neighbors).
If you want to change attributes of IBGP prefixes sent to route reflector clients, you have to modify them as you receive them from other neighbors with inbound route-maps.
A quick summary of how BGP uses route maps
Moreover, as a general personal consideration about IOS style to inject prefixes in a BGP process, I think IOS has a clumsy way to do it. Summarizing, in IOS you may use three different methods:
- Manual, through the "network ... mask ..." command. You may associate to this command a route-map to change some attributes (es. MED) of the route inserted in the BGP table.
- Through aggregation through the "aggregate-address ..." command.
- Through redistribution.
This generates different methods to inject the same prefix in a BGP process, leading some time to different BGP attributes. Let me make an example. Suppose you have a directly connected network that you want to inject in a BGP process. You may do it using the "network ... mask ..." command or the “redistribute connected” command (with a route-map if you want to inject only the directly connected network we are examining). Both ways produce the same result with a small difference: if you use the "network ... mask ..." command the ORIGIN attribute is set to IGP, using “redistribute connected” command the ORIGIN attribute is set to INCOMPLETE. Does this make any sense ? In my opinion surely no ! To tell the truth, I do not even understand why IOS sets the ORIGIN to different values when you use the "network ... mask ..." and the "aggregate-address ..." commands (ORIGIN = IGP) and redistribution (ORIGIN = INCOMPLETE). Probably there are historical reasons behind that, but I do not think today this makes any sense, and this can lead you to errors since ORIGIN is part of the BGP selection process (to be sincere, I have the crazy idea that ORIGIN attribute is useless and should be taken out from BGP selection process !!!)
If you compare IOS to JUNOS, JUNOS has only one (unified) way to inject prefixes into a BGP process, which is essentially similar to the redistribution process used by IOS. You put in some way the prefix you want to inject in the BGP process in the routing table (be it a directly connected route, an aggregate route or route advertised by a dynamic routing protocol), create an “export routing policy” and then apply it to a BGP session (or a group of BGP sessions). Going back to AS_PATH prepending, you cannot make any mistake, you have only one way to do it, just use the “as-path prepend …” command as one of the possible actions in the “export routing policy”. At last, JUNOS always sets the ORIGIN attribute to IGP (giving you a knob if you want to change it).
You have to remember that BGP existed in Cisco IOS long before there were route maps (and probably before there were redistribution filters). Also, BGP was used in an environment where they cared about control and stability (so listing the networks manually made perfect sense).
Aggregation was an add-on feature (as BGP moved from classful BGP-3 to classless BGP-4) and was initially designed as a proxy functionality - a router would aggregate prefixes from other routers running BGP-3 and thus being unable to aggregate. The BGP-3 to BGP-4 migration is also where the "summary-only" keyword came from. Nobody was willing to just aggregate and hope that it would work - the classful prefixes were left in the BGP table as a safety measure.
And we all know that once you implement a feature, it's impossible to get rid of it, because there's always at least one huge network out there that relies on that feature and would break if you change the way the feature behaves.
Comparing that to Junos is unfair. It's like comparing OS/370 to Linux :-P
BTW, the "Incomplete" ORIGIN is a misnomer. It should be "Unknown".
Also, might actually make sense to set ORIGIN to "Incomplete" on route redistribution (unless you use a route-map to set it to IGP). If one router advertises a prefix with a NETWORK statement and another one through blind redistribution, it's better to listen to the one that (supposedly) knows what it's doing.
Do we still need the ORIGIN attribute? Probably not, but as I said before, there's probably a huge network out there that relies on ORIGIN for proper route selection :-P
I fear I may be missing something really obvious here but isn't this set by the very act of redistribution into BGP without any manual route-map action on top? *DONT_KNOW*
will PE send RT values associated with its BGP routes entries in the BGP route update sent towards CE?
Will these BGP update be accepted by PE VRF?
If accepted will those RT values be retained with the routing entries in PE BGP tabl?
what happens if BGP process in CE VRF is configured to send both communities to PE VRF?
Will BGP route update will be sent with RT values ?
Will these BGP update be accepted by PE VRF?
If accepted will those RT values be retained with the routing entries in PE BGP table?
However I found the routes learnt by PE from CE are having the rt values associated with it.
I am not sure what actually happen at the background. I just wanted to know what is the default IOS behaviour when BGP is configured to send community / extended community attribute from within the VRF context.
Thank you.
I found this even more confusing, you can pass some community but no others, there must be a fundamental programming/desing reason for this, it woudl be very good to know it so it can be understood and retained by my poor brain. Fulvio
[email protected]
network x.y.z.t mask a.b.c.d route-map TEST
if TEST set community to no-export, the prefix does not get send to the neighbor, never mind the community.
if TEST set community 11:11, the neighbor gets the prefix with the community set in TEST (this implies I am sending community to neighbors)
if I use the same route-map TEST with set community no-export, but I apply it via the neighbor command, the neighbor gets the prefix with the correct community (no-expoert) in this case.
In other words, it seems I can't pass the no-export community with the network command.
Hope my issue is better explained now.
I think your opening statement
The network route-map command uses a route map to change the attributes of an IP prefix as it’s inserted in the BGP table
has something to do with it, I am confused by the inconsistency of the network route-map command, it looks like it passes some but not all communities.
Fulvio
Fulvio
"The network route-map command uses a route map to change the attributes of an IP prefix as it’s inserted in the BGP table"
I am actually telling the local router not to send this prefix over EBGP....is that right?