BGP route not being advertised

Unanswered Question
Dec 13th, 2007


I have a route that I am trying to advertise to an external provider via BGP, but with no success.

- This is an EBGP connection;

- I have the route in my IGP table (OSFP);

- I have given the network statement in BGP to advertise the route;

- I have modified the prefix-list to include the new route to advertise.

However, even after all these changes above I cannot see the route being advertised to the provider.

Does anyone know what could be causing this issue please???

Thank in advance.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Jon Marshall Fri, 12/14/2007 - 00:16


Could you post relevant BGP config and a copy of the routing table.


adil.javid Fri, 12/14/2007 - 00:39

Sure, here is the relevant config:

network route-map set-med-xxx-xxx

neighbor remote-as 64960

neighbor password 7 131610401F045427387426

neighbor update-source Vlan70

neighbor soft-reconfiguration inbound

neighbor prefix-list ThomsonFinancial_Accept in

neighbor prefix-list SG-To-Thomson out


ip prefix-list SG-To-Thomson seq 70 permit

Routing table:

xxxxx#sh ip bgp

*> 193.10.200 100 32768 i

Jon Marshall Fri, 12/14/2007 - 00:41


If you do a "sh ip route" is there an entry there. Could you post it.


adil.javid Fri, 12/14/2007 - 00:45

Yes, it is present in the IGP table:

xxxxx#sh ip route | i

O IA [110/212] via 193.10.200 , 1w5d, Vlan10


Jon Marshall Fri, 12/14/2007 - 01:05


Sorry to keep asking for things but could you post full config of router as there is a route-map entry for example that is not included.


adil.javid Fri, 12/14/2007 - 01:10


No problem, I appreciate your help. The route-map is as follows:


route-map set-med-xxx-xxx permit 10

set metric 100



marikakis Thu, 12/20/2007 - 13:37


Try to avoid using the include in combination with the ip route command as you just did.

If the router that you issue such a command to also happens to have a large number of routes, you can potentially freeze the poor machine.

It is much safer and you even type less characters if you just type in: show ip route

This was obviously not a suggestion for solution of a problem that has already been solved. It just reminded me of my first big mistake in a router that was carrying many thousands of routes.

Kind Regards,


milan.kulik Fri, 12/14/2007 - 14:48


I see a discreapancy in the subnet mask used:

ip prefix-list SG-To-Thomson seq 70 permit


network route-map set-med-xxx-xxx

Which means /24 mask used if nothing else specified.

If I understand correctly,

network mask route-map set-med-xxx-xxx

should have been used.



Danilo Dy Sun, 12/16/2007 - 19:58


ASN 64512 to 65534 is reserved by IANA for private use.

It can be use by SP and its downstream if the downstream doesn't have its own AS.



CSCO10758684 Mon, 12/17/2007 - 09:14

Hai Dandy,

I was little confused with Privet As and Public its clear ..that was my mistake ...thanks a lot


mheusing Fri, 12/14/2007 - 02:21


a couple of basic questions:

1) your BGP session is up, I guess?

2) How do you check that the route is not advertised?

3) your prefix-list statement has seq 70, post everything up to that entry!

4) Is the provider applying input filters blocking 211.14/16?

As a general remark: please do not cut or edit outputs unless you need to for security reasons. In this case, please replace the relevant statements.

I am assuming you would not be posting here, if you would not look for help. This usually means, that something relevant to the problem is not seen or understood. In this case to only post, what you are thinking is important will likely not reveal the underlying problem.

Regards, Martin

Danilo Dy Fri, 12/14/2007 - 20:01


After you've done with Milan and Martin's recommendation, don't forget to reset BGP so that your upstream will receive the changes that you've made. i.e.

clear ip bgp soft out

Another recommendation (not related to your problem) is to use aggregation. i.e.

aggregate-address summary-only

BTW, I see it being advertise as 211.14/21 using RIPE looking-glass. Are you changing the current advertisement from /21 to /16?



adil.javid Tue, 12/18/2007 - 02:49


Thanks for everones inputs.

Last night we tried a clear BGP soft and both ends and the route started to be propogated.

Thanks to all.

shiva_ial Tue, 12/18/2007 - 01:01

may be synchronisation issue

your route will not be advertised to service

provider(another EBGP)until all IGP routers are aware of the route (all routers have same kind of information about the route)

so to override this

use no synchronisation command

experts can correct me if i am wrong, gives a learning edge as well

Kevin Dorrell Tue, 12/18/2007 - 02:17

You are right that if he is using synchronisation, the IGP should be aware of the route. Also that switching off synchronisation will remove that restriction. But I think that in this case the router does have a route. (Although Milan's issue about the mask still needs to be investigated.)

You might be interested to know that in the case of OSPF and BGP, synchronisation has one further special constraint. With most IGPs, the IGP just needs to know a route to the prefix, and BGP will be allowed to use it. But with OSPF, the originating router id must be the same as the BGP router id.

We could see all this information if the original poster could post a specific show ip bgp for the route in question.

Kevin Dorrell


marikakis Thu, 12/20/2007 - 14:21


I think the discrepancy in the subnet mask did not matter after all, because the prefix filter allowed "more" networks than the /24 implied by the lack of subnet mask in the network bgp command.

In any case, the exact intended mask should have been known and used, rather than depending on luck in order to see a route being advertised, without paying attention to the mask that accompanies it.

The bgp implied a /24 network origination, the IGP route knew about a /16 and filter allowed a /16. So, I guess that the route that is actually being advertised after all is a /24.

Anyway, if you advertise less networks than you are assigned, problem will be in your network with some parts of it at some point being unreachable. Advertising more that you are assigned and your bgp peers finding it out is the humiliating scenario.

Kind Regards,


milan.kulik Fri, 12/21/2007 - 00:15


IMHO, an exact match beween BGP network command and a routing table is necessary to advertise a prefix.

And also

ip prefix-list SG-To-Thomson seq 70 permit

does not permit /24 if LE or GE options are not used.

I agree with Kevin

show ip bgp longer

would help to see what's going on there exactly.



marikakis Fri, 12/21/2007 - 05:05

"An exact route in the routing table is required for a network statement with a mask in order for it to be installed into a BGP table." from

Network statement did not have a mask as you have pointed out earlier in this discussion.

Wierd things can also happen with auto-summary enabled:

Do you have any other documentation pointer that says something different?

You are right about the prefix-list, I have not looked at it thoroughly.

If we had all the config (that prefix-list could have other entries that allow the prefix to be advertised)

or some feedback about what actually changed besides a soft clear of the BGP session, perhaps we could solve the mystery.

Kind Regards,


Kevin Dorrell Fri, 12/21/2007 - 05:23

Welcome back Marikakis! Looking forward to reading your postings once again.

Kevin Dorrell


marikakis Sun, 12/23/2007 - 05:36

Hello Kevin! I always consider this forum great and great you are all of you people that spend so much of your time helping others! I hope I will soon have more time to catch up with your postings as well!

milan.kulik Sun, 12/23/2007 - 14:02


AFAIK, the BGP network ... command without mask opion is treated classfull, i.e.


should be the same as

network mask

And even with auto-summary enabled, the prefix advertised would also be classful, i.e.

I agree without knowing more config details and sh ip bgp longer output we can only guess what's really happenning there.




This Discussion