Buy or Renew
Buy or Renew
Cisco + Splunk: It’s a new day for your data. Learn more.
 
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
cancel
Start a conversation
877
Views
5
Helpful
18
Replies

BGP flapping ?

James Lasky
Level 1
Level 1

‎11-05-2003 12:26 AM - edited ‎03-02-2019 11:28 AM

This is my net design, my AS is AS22222.

AS11111 <--EBGP--> AS22222(routerA)<--IBGP--> AS22222(routerB) <--EGBP--> AS33333

routerA receives 126458 nets from AS11111, routerB receives 127557 nets from AS33333.

I have something strange on my routerA. In the IBGP peering from router B nets received are flapping continually from 127557 to 66665 every minute (split horizon ??). While routerB behaviour is ok, it learns all the routes from IBGP and EBGP. If split horizon is ok, why routerB doesn't have the same behaviuor ?

routerA

show ip bgp summary

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

1.1.1.1 4 11111 3836629 148469 11662110 0 0 14w5d 126458

2.2.2.2 4 22222 28557412 1009752 11662115 0 0 00:09:31 127577

after one minute

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

1.1.1.1 4 11111 3836629 148469 11662110 0 0 14w5d 126458

2.2.2.2 4 22222 28557412 1009752 11662115 0 0 00:09:31 66665

thanks

Labels:
0 Helpful
18 Replies 18

ruwhite
Level 7
Level 7

‎11-05-2003 04:19 AM

This is most likely because of recursion in the next hop. What's probably happening is that the next hop for all of these routes is dependant on an iBGP learned route, which is then dependant on one of these iBGP learned routes itself. Try setting up a static to AS11111's next hop address (the address router A is peering to), and see if this stops the flapping. If it does, either leave the static in place, or include the link between router A and AS11111 in the IGP.

Russ.W

James Lasky
Level 1
Level 1
In response to ruwhite

‎11-05-2003 04:43 AM

Hi russ

thanks but I don't think this is the solution. The static is in place and in the case you mentioned I do not expect the 66665 nets remain in the announce...

the flapping is between 127577 to 66665, not to 0... :-(

ruwhite
Level 7
Level 7
In response to James Lasky

‎11-05-2003 11:38 AM

I wouldnt' expect the route count to go to 0 in this case, either. We'll probably need more information to solve this one, if you're certain it's not the next hop.

What I would do is to find one route which you know is flapping, and catch it while it's in the table, getting a show ip bgp x.x.x.x. Once you have this, do a show ip route for the next hop of the route, show ip route x.x.x.x.

You can also find one route which is flapping, and do a debug ip bgp updates with an access list limiting the output to this one route. Finally, check the next hop on router a, as well, to make certain you're not running into a problem with that.

Split horizon wouldn't (or shouldn't) be causing this sort of thing, but I would consider letting it go through three or four cycles before deciding that it's not going to settle down.

:-)

Russ.W

James Lasky
Level 1
Level 1
In response to ruwhite

‎11-05-2003 11:33 PM

Thanks I'll go through this idea :-)

0 Helpful

ruwhite
Level 7
Level 7
In response to James Lasky

‎11-06-2003 03:20 AM

By the way, another possibility, though remote, is that you are hitting MED churn. I doubt this is the problem, since you don't have a route reflector heirarchy (?) or confederations, which is why I originally stated it's probably a next hop problem. That it's flapping every 60 seconds indicates the problem is something that hits when BGP scanner runs, and the next hop recursion is one of the primary things that BGP scanner checks.

:-)

Russ.W

0 Helpful

James Lasky
Level 1
Level 1
In response to ruwhite

‎11-06-2003 03:27 AM

I have got the debug of a route disappearing (4.78.32.9(21)...

this is the reason...

Nov 6 11:32:36: BGP(0): 2.2.2.2 rcv UPDATE about 4.78.32.0/21 -- withdrawn

0 Helpful

ruwhite
Level 7
Level 7
In response to James Lasky

‎11-06-2003 03:36 AM

This is on router b, correct? Then we need to look at router a, and figure out why it's withrdrawing this route every 60 seconds. I assume this route is received from the eBGP peer on router b, and not from router a through iBGP (?). If so, then we need to look at a show ip bgp for the route on router a, if possible, and a show ip route for the next hop shown there.

Can we also get this on router b, while it's in the table?

:-)

Russ

0 Helpful

James Lasky
Level 1
Level 1
In response to ruwhite

‎11-06-2003 03:57 AM

No it was from routerA.

And... debugging on routerB I see

Nov 6 12:45:46: BGP(0): 1.1.1.1 send UPDATE 4.78.32.0/21 -- unreachable

routerB#sh ip bgp 4.78.32.0

BGP routing table entry for 4.78.32.0/21, version 78916090

Paths: (2 available, best #1, table Default-IP-Routing-Table)

Not advertised to any peer

12874 3257 19151 29748

213.140.31.105 from 1.1.1.1 (217.172.0.120)

Origin IGP, localpref 200, valid, internal, best

21444 6762 6461 14361 29748

217.12.176.250 from 217.12.176.250 (217.12.176.250)

Origin IGP, localpref 200, valid, external

routerB#sh ip route 4.78.32.0

Routing entry for 4.78.32.0/21

Known via "bgp 20608", distance 200, metric 0

Tag 12874, type internal

Last update from 213.140.31.105 00:01:56 ago

Routing Descriptor Blocks:

* 213.140.31.105, from 1.1.1.1, 00:01:56 ago

Route metric is 0, traffic share count is 1

AS Hops 4

routerB#sh ip route 213.140.31.105

Routing entry for 213.140.31.105/32

Known via "static", distance 1, metric 0

Routing Descriptor Blocks:

* 192.168.10.1

Route metric is 0, traffic share count is 1

0 Helpful

ruwhite
Level 7
Level 7
In response to James Lasky

‎11-06-2003 04:28 AM

Okay, on router B, could you:

access-list 25 permit 4.78.32.0 0.0.7.255

debug ip routing 25

?

I assume that 192.168.10.1, being a private address, is directly connected to this router (on the link between these two routers). Do you have synch kicked off, or is it on? Do you have log neighbor changes on? I assume the neighbors aren't flapping, but just to be certain....

B shouldn't be advertising this route to A in the first place, since B is actually using A as its best path. Unless the route a is advertising is withdrawn, then B chooses the external, then the internal shows back up, and B then withdraws the external. The problem might be on A, as well--the same debug on A might help there.

:-)

Russ

0 Helpful

James Lasky
Level 1
Level 1
In response to ruwhite

‎11-06-2003 04:54 AM

you are right 192.168.10.1 in the internal lan between my two routers (IBGP).

debugging on routerB and making a clear of the IBGP peer:

routerB#

Nov 6 13:48:23: %BGP-5-ADJCHANGE: neighbor 1.1.1.1 Down User reset

Nov 6 13:48:23: RT: del 4.78.32.0/21 via 213.140.31.105, bgp metric [200/0]

Nov 6 13:48:23: RT: delete subnet route to 4.78.32.0/21

Nov 6 13:48:23: RT: add 4.78.32.0/21 via 217.12.176.250, bgp metric [20/0]

Nov 6 13:48:32: %BGP-5-ADJCHANGE: neighbor 1.1.1.1 Up

Nov 6 13:48:33: RT: del 4.78.32.0/21 via 217.12.176.250, bgp metric [20/0]

Nov 6 13:48:33: RT: delete subnet route to 4.78.32.0/21

Nov 6 13:48:33: RT: add 4.78.32.0/21 via 213.140.31.105, bgp metric [200/0]

on routerA nothing happens...

:-(

0 Helpful

ruwhite
Level 7
Level 7
In response to James Lasky

‎11-11-2003 09:33 AM

Could you email me off line....

:-)

Russ.W

riw@cisco.com

0 Helpful

ruwhite
Level 7
Level 7
In response to James Lasky

‎11-11-2003 09:33 AM

Could you email me off line....

:-)

Russ.W

riw@cisco.com

0 Helpful

ruwhite
Level 7
Level 7
In response to James Lasky

‎11-11-2003 09:34 AM

Could you email me off line....

:-)

Russ.W

riw@cisco.com

0 Helpful

ruwhite
Level 7
Level 7
In response to James Lasky

‎11-11-2003 09:34 AM

Could you email me off line....

:-)

Russ.W

riw@cisco.com

0 Helpful
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Customers Also Viewed These Support Documents