Routes from BGP network statements are not tagged same as other BGP routes?

[gwhuang5398]

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

[pkhatri]

Hi Gary,

In what way was the route tagged differently ? And could you post the second bit of config that you used ?

Paresh

[Harold Ritter]

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,

[gwhuang5398]

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.

[pkhatri]

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

[Harold Ritter]

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,

[pkhatri]

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

[Harold Ritter]

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,

[gwhuang5398]

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

[Harold Ritter]

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,