cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
385
Views
0
Helpful
5
Replies

Upstream router retain BGP advertisement even when filtered

crisisman
Level 1
Level 1

Dear All,

Would appreicate if anyone can help me with some BGP problem.

I am doing BGP with a customer. He stopped his advertisement from me but my upstream router still shows that his advertisement is still going to them through me. That is even after I have set up a distribute-list to prevent the route from going out through me. On my router, it shows that I am not passing those unwanted block to my upstream.

Over at my upstream end, though they received those routes from me, it is only valid and not best but a show IP BGP indicate that path taken is through me to my customer.

I have tried to reset the BGP with soft option but to no avail and only without it is the whole advertisement working fine again, meaning those dropped advertisement is not going through me to my upstream anymore.

I am believe the soft option retains those routes in the router memory so that there is no need to get them again. But what I am rather puzzled about is that would not the constant updates of the BGP table be able to flush out those retained inside the memory? In fact, the whole problem last for over 3 days until we risk clearing the BGP session as doing that would have adverse effects on my connection to my customers due to my company operation nature.

Would appreciate very much if anyone can help me to assist me in finding out the root cause of this problem. Thanks.

Vincent

5 Replies 5

ruwhite
Level 7
Level 7

Are you running soft-rconfiguration? If you are, you shouldn't if all your peers are capable of doing route refresh.

Other than this, I'm not certain what you are saying is happening--you are saying that although you've stopped advertising a customer's route, it's still being advertised to you from your upstream? "He stopped his advertisement from me but my upstream router still shows that his advertisement is still going to them through me." ??

Or do you mean that they have stopped advertising to you, but your upstream still claims to be learning this route from you? I'm not certain how this could be--could you post a show ip bgp for the route in question from your BGP speaker that connects to your upstream? How are you checking for the existance of the route in your upstream provider's router? Can you post that information?

Russ.W

Dear Russ,

Thanks for your reply.

I am running soft-reconfiguration inbound on with all my peers.

Let me show you what I am giving to my upstream and what they are getting fomr me. It is a long one.

My advertisement to my upstream:

BGP table version is 4227925, local router ID is 81.52.240.254

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete

NetworkNext HopMetric LocPrf Weight Path

*> 81.52.240.0/210.0.0.0032768 i

r>i202.22.204.0/23172.16.0.201000 ?

*> 202.55.168.00.0.0.0032768 i

*> 202.55.169.00.0.0.0032768 i

*> 202.59.160.0202.59.160.1980 17727 i

*> 202.59.161.0202.59.160.1980 17727 i

*> 202.59.162.0202.59.160.1980 17727 i

*> 202.59.163.0202.59.160.1980 17727 i

*> 202.59.164.0202.59.160.1980 17727 i

*> 202.59.165.0202.59.160.1980 17727 i

*> 202.59.166.0202.59.160.1980 17727 i

*> 202.59.168.0202.59.160.1980 17727 i

*> 202.59.169.0202.59.160.1980 17727 i

*> 202.59.170.0202.59.160.1980 17727 i

*> 202.59.171.0202.59.160.1980 17727 i

*> 202.59.172.0202.59.160.1980 17727 i

*> 202.59.173.0202.59.160.1980 17727 i

*> 202.59.174.0202.59.160.1980 17727 i

*> 202.59.175.0202.59.160.1980 17727 i

*> 202.65.239.00.0.0.0032768 ?

r>i202.138.240.0/22 172.16.0.201000 ?

r>i202.138.254.0172.16.0.201000 ?

*> 202.141.160.0/23 0.0.0.0032768 ?

r>i202.143.32.0/22172.16.0.201000 ?

*> 202.150.224.0/22 202.59.160.1980 17727 10114 i

*> 202.150.228.0/22 202.59.160.1980 17727 10114 i

*> 202.150.232.0/22 202.59.160.1980 17727 10114 i

*> 202.150.240.0/22 202.59.160.1980 17727 10114 i

*> 202.150.244.0/22 202.59.160.1980 17727 10114 i

*> 202.150.248.0/22 202.59.160.1980 17727 10114 i

r>i202.159.64.0/19172.16.0.201000 ?

*> 203.77.208.0/23202.59.160.1980 17727 18393 i

*> 203.105.154.0/23 81.52.240.5800 64553 i

*> 203.105.156.0/23 81.52.240.5800 64553 i

*> 203.128.66.0202.59.160.1980 17727 18103 i

*> 203.128.67.0202.59.160.1980 17727 18103 i

r>i203.190.0.0/22172.16.0.201000 ?

r>i210.23.64.0172.16.0.201000 ?

r>i210.23.65.0172.16.0.201000 ?

r>i210.23.66.0172.16.0.201000 ?

r>i210.23.67.0172.16.0.201000 ?

r>i210.23.68.0172.16.0.20 1000 ?

r>i210.23.70.0172.16.0.201000 ?

r>i210.23.71.0172.16.0.201000 ?

This is what my upstream claim is getting from me as I request them to show it to me:

BGP table version is 39907554, local router ID is 193.251.128.30

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal

Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

* 81.52.240.0/21 193.251.129.186 0 0 17927 i

* 202.22.204.0/23 193.251.129.186 0 17927 ?

* 202.55.168.0 193.251.129.186 0 0 17927 i

* 202.55.169.0 193.251.129.186 0 0 17927 i

* 202.59.160.0 193.251.129.186 0 17927 17727 i

* 202.59.160.0/20 193.251.129.186 0 17927 17727 i

* 202.59.161.0 193.251.129.186 0 17927 17727 i

* 202.59.162.0 193.251.129.186 0 17927 17727 i

* 202.59.163.0 193.251.129.186 0 17927 17727 i

* 202.59.164.0 193.251.129.186 0 17927 17727 i

* 202.59.165.0 193.251.129.186 0 17927 17727 i

* 202.59.166.0 193.251.129.186 0 17927 17727 i

* 202.59.167.0 193.251.129.186 0 17927 17727 i

* 202.59.168.0 193.251.129.186 0 17927 17727 i

* 202.59.169.0 193.251.129.186 0 17927 17727 i

* 202.59.170.0 193.251.129.186 0 17927 17727 i

* 202.59.171.0 193.251.129.186 0 17927 17727 i

* 202.59.172.0 193.251.129.186 0 17927 17727 i

* 202.59.173.0 193.251.129.186 0 17927 17727 i

* 202.59.174.0 193.251.129.186 0 17927 17727 i

* 202.59.175.0 193.251.129.186 0 17927 17727 i

* 202.65.239.0 193.251.129.186 0 0 17927 ?

* 202.75.96.0/23 193.251.129.186 0 17927 17727 i

* 202.75.98.0/23 193.251.129.186 0 17927 17727 i

* 202.75.100.0/22 193.251.129.186 0 17927 17727 i

Network Next Hop Metric LocPrf Weight Path

* 202.75.104.0/22 193.251.129.186 0 17927 17727 i

* 202.75.108.0/22 193.251.129.186 0 17927 17727 i

* 202.138.240.0/22 193.251.129.186 0 17927 ?

* 202.138.254.0 193.251.129.186 0 17927 ?

* 202.141.160.0/23 193.251.129.186 0 0 17927 ?

* 202.143.32.0/22 193.251.129.186 0 17927 ?

* 202.150.224.0/22 193.251.129.186 0 17927 17727 10114 i

* 202.150.228.0/22 193.251.129.186 0 17927 17727 10114 i

* 202.150.232.0/22 193.251.129.186 0 17927 17727 10114 i

* 202.150.240.0/22 193.251.129.186 0 17927 17727 10114 i

* 202.150.244.0/22 193.251.129.186 0 17927 17727 10114 i

* 202.150.248.0/22 193.251.129.186 0 17927 17727 10114 i

* 202.159.64.0/19 193.251.129.186 0 17927 ?

* 203.77.208.0/23 193.251.129.186 0 17927 17727 18393 i

* 203.105.154.0/23 193.251.129.186 0 17927 i

* 203.105.156.0/23 193.251.129.186 0 17927 i

* 203.128.64.0 193.251.129.186 0 17927 17727 18103 i

* 203.128.65.0 193.251.129.186 0 17927 17727 18103 i

* 203.128.66.0 193.251.129.186 0 17927 17727 18103 i

* 203.128.67.0 193.251.129.186 0 17927 17727 18103 i

* 203.128.68.0 193.251.129.186 0 17927 17727 18103 i

* 203.128.69.0 193.251.129.186 0 17927 17727 18103 i

* 203.128.70.0 193.251.129.186 0 17927 17727 18103 i

* 203.128.71.0 193.251.129.186 0 17927 17727 18103 i

* 203.128.72.0 193.251.129.186 0 17927 17727 18103 i

* 203.128.73.0 193.251.129.186 0 17927 17727 18103 i

* 203.128.74.0 193.251.129.186 0 17927 17727 18103 i

* 203.128.75.0 193.251.129.186 0 17927 17727 18103 i

* 203.128.76.0 193.251.129.186 0 17927 17727 18103 i

* 203.128.77.0 193.251.129.186 0 17927 17727 18103 i

Network Next Hop Metric LocPrf Weight Path

* 203.128.78.0 193.251.129.186 0 17927 17727 18103 i

* 203.128.79.0 193.251.129.186 0 17927 17727 18103 i

* 203.128.80.0 193.251.129.186 0 17927 17727 18103 i

* 203.128.81.0 193.251.129.186 0 17927 17727 18103 i

* 203.128.82.0 193.251.129.186 0 17927 17727 18103 i

* 203.128.83.0 193.251.129.186 0 17927 17727 18103 i

* 203.128.84.0 193.251.129.186 0 17927 17727 18103 i

* 203.128.85.0 193.251.129.186 0 17927 17727 18103 i

* 203.128.86.0 193.251.129.186 0 17927 17727 18103 i

* 203.128.87.0 193.251.129.186 0 17927 17727 18103 i

* 203.128.88.0 193.251.129.186 0 17927 17727 18103 i

* 203.128.89.0 193.251.129.186 0 17927 17727 18103 i

* 203.128.90.0 193.251.129.186 0 17927 17727 18103 i

* 203.128.91.0 193.251.129.186 0 17927 17727 18103 i

* 203.128.92.0 193.251.129.186 0 17927 17727 18103 i

* 203.128.93.0 193.251.129.186 0 17927 17727 18103 i

* 203.128.94.0 193.251.129.186 0 17927 17727 18103 i

* 203.128.95.0 193.251.129.186 0 17927 17727 18103 i

* 203.190.0.0/22 193.251.129.186 0 17927 ?

* 210.23.64.0 193.251.129.186 0 17927 ?

* 210.23.65.0 193.251.129.186 0 17927 ?

* 210.23.66.0 193.251.129.186 0 17927 ?

* 210.23.67.0 193.251.129.186 0 17927 ?

* 210.23.68.0 193.251.129.186 0 17927 ?

* 210.23.70.0 193.251.129.186 0 17927 ?

* 210.23.71.0 193.251.129.186 0 17927 ?

Total number of prefixes 81

I know it is a bit heavy so to aid u better, the problematic ones are from the AS 17727. Notice the difference in our prefixes. Mine is about 44, while my upstream is 81. Also it is only valid and not valid and best.

In fact, even after I have implement a distribute-list the routes are still going through. Therefore, I am really very puzzled.

I would really appreciate if you can assist me on this issue.

Vincent

My first suggestion would be to stop using soft configuration, and switch to route refresh. It will take up a lot less memory on your routers, less processing time, etc.

Next, could you post a show ip bgp 203.128.90.0? I'd probably open a TAC case, rather than handling this here, since it sounds like it might be rather more complicated.

Russ.W

Hi Russ,

Thanks for looking into this matter for me.

Correct me if I mistaken your intention. You are suggesting that I do not use soft-reconfiguration inbound on all my BGP setup with my peers?

How do I implement route refresh? I don't seems to find that command in the list of commands available.

This is the result as per your request:

Poseidon#sh ip bgp 203.128.190.0

% Network not in table

Poseidon#

The problem is happening rather consistently. I need to clear IP BGP with my upstream all the time whenever that customers wanted to de-advertise a route.

Also another thing that I find interesting is that the table version for my customer always remain at zero and never increase. Please see below:

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd

81.52.240.58 4 64553 6831 20084570 0 0 0 2d17h 4

81.52.240.253 4 17927 27255 27541 6499540 0 0 1w2d 15

193.251.129.185 4 5511 2025890 28041 6499540 0 0 11:48:16 127256

202.55.169.9 4 17769 1335 1536 6499540 0 0 22:10:50 1

202.59.160.198 4 17727 7169 1262294 0 0 0 1d16h 18

I appreciate all the assistance you are giving me. Thanks for your help.

Vincent

Route refresh is described here:

http://www.cisco.com/en/US/products/sw/iosswrel/ps1830/products_feature_guide09186a0080087b3a.html

Although we call it something like soft reset (?) for some reason I don't understand. It's not something you would configure, you would just kill off soft reconfiguration. The IETF documentation on how it works is here:

http://www.ietf.org/rfc/rfc2918.txt

I meant to ask for 203.128.90.0, which should be one of the routes your provider is claiming you're sending them, but you don't show in your local table. I'd like to make certain it's not there, just not in the routing table. Could you check it three times, about 30 seconds apart each time, to make certain it's not flapping?

Is your upstream dampening you? Just curious--if they were, and you were flapping, you'd eventually drop routes out of their table, and it doesn't seem like that's happening. It's not really pertinent to the problem at hand, though.

The table version being 0, and the other symptoms you're seeing, could all be a result of soft-reconfiguration, though it sounds like a bug in the soft reconfiguration code someplace or another, perhaps. At the moment, I'd try without it, and see if the problem clears up, as long as you know, for certain, that all the peers support route refresh.

:-)

Russ.W