02-06-2006 10:42 AM - edited 03-03-2019 01:43 AM
I have a question if BGP treats the routes it advertised by using the network statements the same way as the routes it learned or redistributed.
Here is what I did:
bgp 65113
network 1.2.3.4 mask 255.255.255.0
redistribute static route-map STATIC_INTO_BGP
ip route 1.2.3.4 255.255.255.0 null0
ip route ....
route-map STATIC_INTO_BGP permit 10
match ip address prefix-list STATIC_INTO_BGP
set community 65113:100
I had all the static routes, including the one to null0, in the prefix-list STATIC_INTO_BGP. So those routes could be tagged with the community value.
I found out that all the routes in the prefix list were tagedd correctly except for the one to null0 (the one advertised by the BGP network statement). I had to create a seperate prefix list just for this route and add to the route map to have it tagged correctly.
So my question is: is this how BGP supposed to function or did I do it incorrectly?
Thanks a lot
Gary
02-06-2006 11:04 AM
Hi Gary,
In what way was the route tagged differently ? And could you post the second bit of config that you used ?
Paresh
02-06-2006 01:13 PM
you should use a route-map on the network statement to assign a community to this prefix.
network 1.2.3.4 mask 255.255.255.0 route-map STATIC_INTO_BGP
Hope this helps,
02-06-2006 02:02 PM
I had to create a prefix-list "Null0_into_BGP" to get the null0 static route tagged with the same community value as other static routes in the prefix-list STATIC_INTO_BGP, although this null0 route was in the STATIC_INTO_BGP prefic-list too.
I guess "network 1.2.3.4 mask 255.255.255.0 route-map STATIC_INTO_BGP" may be the solution, but I can't try it again since the router is in production already.
I'm just not too clear about why the routes advrtised by the BGP network statements were not tagged the same way as other routes redistributed into BGP. They were all in the BGP table and were all permitted in the same prefix-list.
02-06-2006 02:19 PM
OK, I think I understand and I have seen this behaviour before. When you have 'network' statements for routes that are being redistributed by other means, the network statement takes preference. That is why your route did not get tagged. It was not because it was a route to Null0. If you remove the network statement, you will see that the route will be tagged properly.
Hope that helps - pls rate the post if it does.
Paresh
02-06-2006 02:24 PM
Why would you use a network statement anyway since you already have a static route covering that prefix. Just remove the network statement and let that prefix be redistributed by the "redistribute static" statement.
By the way, the format of the network statement you use is incorrect. I know 1.2.3.4 is not your real prefix but with a mask of 255.255.255.0 the network should be 1.2.3.0. If you use the same format with the real prefix, it could cause issues.
Hope this helps,
02-06-2006 02:38 PM
Hi Harold,
I find it a major annoyance that the parser will accept this incorrect form of the network mask without a warning...
Is there a chance that this behaviour could be fixed.
Paresh
02-06-2006 03:20 PM
Hi Paresh,
I totally agree with you that this is very annoying. This issue is being fixed by CSCeg57155.
Here's the error message you get post CSCeg57155:
R1(config-router)#netw 1.2.3.4 mask 255.255.255.0
% BGP: Incorrect network or mask configured
Hope this helps,
02-08-2006 07:14 AM
Thanks all for the help. I agree that if the static route is redistributed into BGP, there's no need to have a BGP network statement again.
How about this scenario:
I have a static route:
ip route 1.2.3.0 255.255.255.0 null0
I don't redistribute it into BGP, instead I use a network statement:
bgp xxxxx
network 1.2.3.0 mask 255.255.255.0
I create a prefix list and route map to tag it:
ip prefix-list set-community permit 1.2.3.0/18 le 32
route-map set-community permit 10
match ip address prefix-list set-community
set community xxxxx:100
Would this set the right community for 1.2.3.0/24 (and other length in the range 18-32)? IN thise case, I used a network statement not a redistribution.
Thansk
Gary
02-08-2006 09:52 AM
In this case, the route-map has to be applied to the network statement and would only apply to 1.2.3.0/24, unless you have other network statements for other prefixes.
PS: 1.2.3.0/18 on the prefix-list is invalid by the way.
Hope this helps,
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