Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

ibgp peer stats recieving routes, then drops most...

Hey Guys, I have an interesting issue.

Setup:  Two 7000 series routers.

(Fictious ips used for example)

Router one: 5.5.5.1

                              ebgp Peers with Level3 (aprox 474,000 routes)

                              ebgp Peers with 5.5.5.2

Router two: 5.5.5.2

                              ebgp peers with Earthlink (aprox 474,000 routes)

                              ibgp peers with 5.5.5.1

Problem:

               The problem is with the ibgp session.  Router one will start to recieve routes from router two, I start the session...it starts getting routes in, but but when it hits a certian amount, usually around 200,000, it drops the routes down to around 46,000 routes...and stays there.  I cannot for the life of me understand why this is happening.  I should add the session isnt dropping, just the routes.

Router two sees 474K routes from both level3 and 5.5.5.1.  No problem.

Both routers had 512M of memory.  So i figured router1 may be running out, so I upgraded it to a NPE-G1 with 1GB memory.  Same problem is happening.  And since router2 only has 512MB and is getting full routes fine, I dont think its a memory issue.

Now, if somthing goes wrong with level3, then the routes from 5.5.5.2 start increasing until they reach full routes.  Its like im hitting some sort of max limits of routes....which is why i thought memory issue.

I really apreciate help with this as its driving me crazy!

--John

Everyone's tags (3)
20 REPLIES

ibgp peer stats recieving routes, then drops most...

John,

Is 'maximum-prefixes' configured anywhere? I'm assume you probably checked that, just wanted to be sure. Also, has this always been going on, or did it happen all of a sudden.

What is the model number and IOS version of Router1?

And you have eBGP to the iBGP peer above, I'm assuming that was just a typo, and it's iBGP to iBGP from R1 to R2, then each has an eBGP to the provider?

Cisco Employee

ibgp peer stats recieving routes, then drops most...

Hi John,

Router 2 will not advertise a given prefix to router 1 if it considers router 1 to be the best path for this prefix. It sounds like router 2 considers router 1 to be the best path for most of the prefixes, hence it does not advertise these prefixes to router1.

Regards

Harold Ritter
Sr. Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México

ibgp peer stats recieving routes, then drops most...

Harold,

So, and iBGP neighbor will only send the route that it knows as best, to it's peers, unless that peer happens to be the best path according to the neighbor from whcih it was learned, which would make sense?

Do I have this correct, and does this go the same for eBGP neighbors?

Cisco Employee

ibgp peer stats recieving routes, then drops most...

Hi John,

A router does not send an update for a given prefix to a given neighbor if it considers that same neighbor as the best path for that prefix. This applies regardless it is iBGP or eBGP.

Regards

Harold Ritter
Sr. Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México
New Member

Re: ibgp peer stats recieving routes, then drops most...

I understand BGP will not send an update to a peer if it considers that neighbor a better path, but in that case it causes the problem that when level3 goes down, its missing a lot of routes that were not sent.  Somthing isnt right here.

I did a debug ip bgp on router2, and notice that it sends the routes to router1, but once it hits around 400,000 or so it starts sending deletes.  Its like at part way through the session it gets somthing from router1 that causes it to say the majority of routes are unreachable, so it deletes them:

BGP(0): x.x.x.1 send UPDATE 24.112.88.0/22 -- unreachable

and that messages runs for a zillion networks and the prefixes on router1 goes down fast...till it hits around 47K.

Possibly this info from the routers will help (Before you ask, im not filering anything between them):

On router1 (level3):

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

level3             4  3356  210048     841  1552672    0    0 13:48:23      473458

router2           4 19193  364406  404145  1552693    0    0 10:02:16    43001

savvis             4  3561   26979     839  1552693    0    0 10:30:42        37005

(savvis is only sending partial routes, so that peer is correct)

Default information originate, default route-map see-default, default sent

                                 Sent       Rcvd

  Prefix activity:               ----       ----

    Prefixes Current:          447600      43001 (Consumes 2236052 bytes)

    Prefixes Total:            546893     484358

    Implicit Withdraw:          65313      26304

    Explicit Withdraw:          33980     415053

    Used as bestpath:             n/a      29387

    Used as multipath:            n/a          0

--------------------------------------------------------------------------------------------------------

On Router2 (Earthlink):

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

Earthlink        4 13407 12458091  192897 29221737    9    0 3w2d     476983

router1           4 19193  404226  364484 29221783    0    0 10:04:26   447600

It seems router1 is correctly getting full routes from both peers...

Default information originate, default route-map see-default, default sent

                                 Sent       Rcvd

  Prefix activity:               ----       ----

    Prefixes Current:           43007     447605 (Consumes 23275356 bytes)

    Prefixes Total:            484494     547095

    Implicit Withdraw:          26375      65451

    Explicit Withdraw:         415112      34039

    Used as bestpath:             n/a     433987

    Used as multipath:            n/a          0

------------------------------------------------------------------------------------------------------------------------------

Look at how many routes router2 is withdrawing......

--John

Cisco Employee

Re: ibgp peer stats recieving routes, then drops most...

Hi John,

The path unreachable message (also known as withdraw message) seen from R2 is part of the convergence process. R2 initially advertises the routes it receives from Earthlink to R1 but after receiving those same routes from R1 and realizing that R1 is the best path, it sends a withdraw message to R1.

What I fail to understand is why it causes a problem in your scenario when Level3 goes down. In this case, when Level3 goes down, R1 should consider all of the paths received from Level3 as unreachable and send a withdraw message to R2, which in turn sees that R1 is not the best path anymore. R2 will then send its best paths received from Earthlink to R1.

So what is happening in your case? Is it just that the convergence time is too long?

Regards

Harold Ritter
Sr. Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México
New Member

Re: ibgp peer stats recieving routes, then drops most...

Correct Harold, Im assuming the issue is that when Level3 goes down, the other routes arent there, so we are partially down until they come back from R2...

Im not understanding why the routes would be withdrawn....many times I look at a sho ip bgp route and see multiple routes to a network with a * showing the best.....why wouldnt it simply leave the routes and put a * for the best one?

--John

Cisco Employee

Re: ibgp peer stats recieving routes, then drops most...

Hi John,

By default, BGP only advertise its best path and as explained before, that best path is not advertised back to the peer advertising it to us.

There is a way to change the default behavior and to make a BGP peer advertise its best path and its alternate path as well. This feature is called "BGP additional paths". It is not necessarily recommended in all scenarios though.

In your case, you should probably look at why the network takes too long to converge. Is it possible that the BGP routers are too small for the task they are being asked to do?

Regards

Harold Ritter
Sr. Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México

Re: ibgp peer stats recieving routes, then drops most...

Have you configured BGP conditional advertisements? Can you post the configuration of the BGP, from both routers? Along with any route-map etc. applied?

-Vishesh

New Member

Re: ibgp peer stats recieving routes, then drops most...

Vishesh, thanks....here you go (all ips/AS ficticious) and i deleted the other neighbors for easier reading:

router1:

router bgp 19193

no synchronization

no bgp enforce-first-as

bgp log-neighbor-changes

network x.x.x.x mask 255.255.240.0

network x.x.x.x mask 255.255.252.0

network x.x.x.x mask 255.255.248.0

neighbor internal peer-group

neighbor internal remote-as 19193

neighbor internal filter-list 2 out

neighbor 192.168.72.2 remote-as 19193

neighbor 192.168.72.2 update-source GigabitEthernet0/0

neighbor 192.168.72.2 next-hop-self

neighbor 192.168.72.2 default-originate route-map see-default

no auto-summary

route-map see-default permit 10

match ip address 10

access-list 10 permit 0.0.0.0

--------------------------------------------------------------------------------------------------------------

router2

router bgp 19193

no synchronization

bgp router-id x.x.x.x

bgp log-neighbor-changes

network x.x.x.x mask 255.255.240.0

network x.x.x.x mask 255.255.252.0

network x.x.x.x mask 255.255.248.0

neighbor 192.168.72.1 remote-as 19193

neighbor 192.168.72.1 description ibgp-border1-non-loopback

neighbor 192.168.72.1 update-source FastEthernet0/0

neighbor 192.168.72.1 next-hop-self

neighbor 192.168.72.1 default-originate route-map see-default

no auto-summary

route-map see-default permit 10

match ip address 10

access-list 10 permit 0.0.0.0

Re: ibgp peer stats recieving routes, then drops most...

Hi John,

I want to confirm just in case you have any non-defaults, what is the Primary path for R1 for all 470K routes? And same question for R2?

I need following information from both routers -

  • show version
  • show ip bgp neighbor from R1 and R2 (for their ibgp neighborship)

I need some prefixes which are learnt from EarthLink on R2 and are sent to R1. Also, some prefixes which are learnt from EarthLink on R2 and are not sent(withdrawn) to R1. (Outputs required from both routers)

  • show ip bgp

Use following command to get the neighbors info, if you see advertised to update-groups in prefix information.

  • show ip bgp update-group

Also the outputs of debugs that you ran on both the routers.

-Vishesh

New Member

Re: ibgp peer stats recieving routes, then drops most...

vishesh:  Emailed to you for privacy..but please post solution here for the benifit of the community with ip's and as# 's removed...

--John

Re: ibgp peer stats recieving routes, then drops most...

Hi John,

I have hidden your AS and IP's

           Level3                              EarthLink

              +                                    +

              |                                    |

              |                                    |

              |                                    |

              |eBGP                                |eBGP

              |                                    |

              |                                    |

              |                                    |

        +-----+------+                      +------+-----+

        |            |                      |            |

        |            |                      |            |

        |            |                      |            |

        |   Router1  +----------------------+   Router2  |

        |  (Uplink1) |        iBGP          |  (Border2) |

        |            |                      |            |

        |            |                      |            |

        +------------+                      +------------+

From Uplink1:

uplink1-7204#sho ip bgp 1.22.189.0/24

BGP routing table entry for 1.22.189.0/24, version 763275

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

  Advertised to update-groups:

     2        

  3356 6453 4755 45528

    Level3 from Level3 (Level3 Router-ID)

      Origin IGP, metric 0, localpref 100, valid, external, best

Uplink1#sho ip bgp sum

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

Level3          4  3356  323836    2761  1957830    0    0 1d21h      473501

Border2         4 OurAS  440754  483676  1957857    0    0 1d18h       42695

uplink1-7204#show ip bgp update-group 2

  Has 1 member (* indicates the members currently being sent updates):

   Border2 

  • Uplink learns the prefix from Level3 and selects it as valid-best path and advertise to Border2

From Border2:

border2#sho ip bgp sum

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

EarthLink       4 13407 12563568  194815  29579893    0    0  3w3d       477035

Uplink1         4 OurAS 483676    440756  29579911    0    0  1d18h      447900

border2#sho ip bgp 1.22.189.0/24

BGP routing table entry for 1.22.189.0/24, version 29063430

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

  Not advertised to any peer

  3356 6453 4755 45528

    Uplink1 from Uplink1 (Uplink1 Router-ID)

      Origin IGP, metric 0, localpref 100, valid, internal, best

  13407 3356 3356 6453 4755 45528

    EarthLink from EarthLink (EarthLink ROuter-ID)

      Origin IGP, localpref 100, valid, external

  • Border2 learns about the prefix from Uplink1 and EarthLink, however it chooses the Uplink1 as best path because of smaller AS-path.
  • BGP advertises only valid-best-path from the BGP table to its neighbor, but this best path is chosen from Uplink1
  • Just like split-horizon rule in EIGRP, BGP do not advertise any prefix to a neighbor, for which the best path is already that neighbor
  • And for the same reason it is not adveritsing this prefix or I should say it has withdrawn it from Uplink1 after selecting Uplink1 as bestpath.

We can say that BGP is working at its default behavior here, however, from this post I believe you want following -

  • Level3 to be the primary path for Router1(Uplink1) and Earthlink would be primary path for Router2(Border2).
  • Router1 and Router2 should learn all prefixes from each other via iBGP and in case of failure of primary path they should route traffic from each other with the least convergence time.

To achieve this we need to leverage weight to choose the isp's as preffered path and only after that can router1 and router2 would advertise all prefixes to each other.

neighbor { ip-address | peer-group-nameweight number

Border2-

!

router bgp OurAS

neighbor EarthLink weight 1000

!

Upink1-

!

router bgp OurAS

neighbor Level3 weight 1000

!

Don't forget to soft clear inboud after making the change.


clear ip bgp EarthLink/Level3 soft in

Refer to following document for BGP best path selection algorithm -

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094431.shtml


-Vishesh

Re: ibgp peer stats recieving routes, then drops most...

Hi Vishesh,

some comments:

1) " Just like split-horizon rule in EIGRP, BGP do not advertise any prefix to a neighbor, for which the best path is already that neighbor."

This is not correct!

The "split-horizon" feature is applied only on iBGP neighbors this way:

"When a BGP speaker receives an UPDATE message from an internal peer,

   the receiving BGP speaker SHALL NOT re-distribute the routing

   information contained in that UPDATE message to other internal peers

   (unless the speaker acts as a BGP Route Reflector [RFC 2796])."

See https://supportforums.cisco.com/thread/2159140

2) If you compare the AS_PATHs on

uplink1-7204#sho ip bgp 1.22.189.0/24

BGP routing table entry for 1.22.189.0/24, version 763275

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

  Advertised to update-groups:

     2        

  3356 6453 4755 45528

    Level3 from Level3 (Level3 Router-ID)

and

border2#sho ip bgp 1.22.189.0/24

BGP routing table entry for 1.22.189.0/24, version 29063430

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

  Not advertised to any peer

  3356 6453 4755 45528

    Uplink1 from Uplink1 (Uplink1 Router-ID)

      Origin IGP, metric 0, localpref 100, valid, internal, best

  13407 3356 3356 6453 4755 45528

    EarthLink from EarthLink (EarthLink ROuter-ID)

you can see the EarthLink router received the prefix from the Level3's AS.

So the EarthLink and  Level3 providers are peering somewhere in the Internet and the best path to the prefix destination is through  Level3 even while forwarded to EarthLink originally.

Now the question is:  Should each of the routers prefer his eBGP neighbor for all prefixes received?

If yes, wouldn't it be easier to ask the providers to send just the default route instead of full BGP tables?

I think John needs to answer this question together with his LAN topology - which router is used as the default GW by the LAN devices?

But generally, the router behaviour described in the original question is correct.

Bets regards,

Milan

New Member

Re: ibgp peer stats recieving routes, then drops most...

Thank you Vishesh!  Applied the weight 1000 to both routers, and wham....look at uplink1 now:

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

Level3                        4  3356  555075    5302  2823713   30    0 3d16h      473892

Router2                     4 xxxx  626863  651686  2837483    0    0 3d12h      477535

Savvis (partial route)  4  3561   79786    5299  2837483    0    0 3d12h       35784

millan: Call me old school, but i prefer to recieve full routes at all sites.

***************** I really apreciate the help you guys, as this had me stumped. ******************

Im curious how this will affect traffic balance with the weight equal now.  We try to keep about 70% going through level3 and 30% through earthlink.  If level3 fails, 99% goes through level3.  We run OSPF on the core routers internally, and use that as well as a script mechnisim to switch which border router it points at for a default, so that in the event router1 or router2 totally goes down, traffic continues to flow.

Re: ibgp peer stats recieving routes, then drops most...

You are welcome!! John, If you want to load-balance, First you have to identify the traffic's destinations and quantity, leaving through each router.

After that you can use route-map between IBGP peers and increase the weight for specific routes; till you get traffic load-balanced between each other the way you want.

Refer to following document, it contains some good case studies about BGP -

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a00800c95bb.shtml

And as mentioned in my post earlier following document contains BGP best path selection algorithm -

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094431.shtml

-Vishesh

Re: ibgp peer stats recieving routes, then drops most...

Hi Milan,

I am sorry, I agree with you about the BGP Split-horizon rule, but I didn't mention it in my post. I mentioned "Just like split-horizon rule in EIGRP"

I mean by that is "A local router propagates only the routes that are selected as best  to the Ebgp and Ibgp neighbors. However, the router never sends a route  back on the same BGP session upon which it was received and selected as a best-path for that prefix. When it picks a neighbor as the best next-hop, the router makes sure  that the neighbor is not pointing back to the local router. In order to  make this backward destination unreachable, a withdraw message is sent  to that neighbor." Which is exactly the case here.

But in Cisco's implemention this rule is bend a little and the route can be advertised to the neighbor who himself is the best-path for the prefix, if that neighbor is part of an update-group and the update-group contains other neighbors to whom we need to send the route. This update-group method is implemented to save memory cycles and processor consumption on the routers.

Second part is the ISP are peering, but that again won't affect route selection process in BGP. As these routers are not advertising the 470K routes back to the ISPs. Also, this is just one of the 470K routes.

Now the question is:  Should each of the routers prefer his eBGP neighbor for all prefixes received?

If yes, wouldn't it be easier to ask the providers to send just the default route instead of full BGP tables?

I think John needs to answer this question together with his LAN  topology - which router is used as the default GW by the LAN devices?

I agree with all these questions, but I am being a TAC engineer provide resolution based on the problem, I do not make any recommendations on design changes unless explicitly required.

So I think based on John's comment earlier in the post, "I understand BGP will not send an update to a peer if it considers that  neighbor a better path, but in that case it causes the problem that when  level3 goes down, its missing a lot of routes that were not sent.   Somthing isnt right here." increasing the weight would work.

-Vishesh

Re: ibgp peer stats recieving routes, then drops most...

Hi Vishesh,

1) ad "A local router propagates only the routes that are selected as best  to the Ebgp and Ibgp neighbors. However, the router never sends a route  back on the same BGP session upon which it was received and selected as a best-path for that prefix. When it picks a neighbor as the best next-hop, the router makes sure  that the neighbor is not pointing back to the local router. In order to  make this backward destination unreachable, a withdraw message is sent  to that neighbor." Which is exactly the case here.

I don't think this is the case here.

As Router2 is picking a prefix received from Router1 via iBGP as the best one. So the next-hop is Router1 (using next-hop self), not the Router2 itself (the local router).

BTW, where does this mechanism come from? I've not found it in any BGP RFC, is it Cisco proprietary?

IMHO, the withdrawn is sent because the best path which had been advertised from Router2 to Router1 originally was the eBGP one received from his ISP originally. But now the best path is an iBGP one received from Router1. As iBGP received prefixes should not be advertised via iBGP, Router2 has no path to advertise anymore so the previously advertised path has to be withdrawn, I guess?

2) I agree preferring the eBGP received prefixes has a good sense.

But as shown in the example above, not always.

Possibly it would make a sense to prefer the eBGP prefixes received from the ISP but not those containing the other ISP AS number within the AS_PATH?

So to prefer eBGP prefixes not containing  _3356_  on Router2?

And vice versa, to prefer eBGP prefixes not containing  _13407_  on Router1?

Best regards,

Milan

Re: ibgp peer stats recieving routes, then drops most...

Hi Milan,

      AS 3                         AS 4

       +                             +

       |                             |

       |                             |

       |ebgp                         |ebgp

       |                             |

  +----+-----+                 +-----+----+

  |          |                 |          |

  |          |                 |          |

  |    R1    |                 |    R2    |

  |          +-----------------+          |

  |          |      ibgp       |          |

  |          |      AS 12      |          |

  +----------+                 +----------+

Note in this example that BGP Split Horizon is disabled via route-reflector client, still R2 withdraws the prefixes from R1, if R2 opts to choose R1 as valid best path.

R2

R2#show ip bgp summary | be InQ

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

12.0.0.1        4    12      32      38       19    0    0 00:00:03        3

24.0.0.4        4     4      26      19       19    0    0 00:04:11        3

R2#show ip bgp | be Net

   Network          Next Hop            Metric LocPrf Weight Path

* i3.3.3.1/32       12.0.0.1                 0    100      0 3 i

*>                  24.0.0.4                 0             0 4 i

* i3.3.3.2/32       12.0.0.1                 0    100      0 3 i

*>                  24.0.0.4                 0             0 4 i

* i3.3.3.3/32       12.0.0.1                 0    100      0 3 i

*>                  24.0.0.4                 0             0 4 i

R2#

*Mar  1 00:36:40.835: BGP(0): 24.0.0.4 rcvd UPDATE w/ attr: nexthop 24.0.0.4, origin i, metric 0, path 4

*Mar  1 00:36:40.835: BGP(0): 24.0.0.4 rcvd 3.3.3.3/32

*Mar  1 00:36:40.835: BGP(0): 24.0.0.4 rcvd 3.3.3.2/32

*Mar  1 00:36:40.839: BGP(0): 24.0.0.4 rcvd 3.3.3.1/32

*Mar  1 00:36:40.843: BGP(0): Revise route installing 1 of 1 routes for 3.3.3.1/32 -> 24.0.0.4(main) to main IP table

*Mar  1 00:36:40.843: BGP(0): Revise route installing 1 of 1 routes for 3.3.3.2/32 -> 24.0.0.4(main) to main IP table

*Mar  1 00:36:40.847: BGP(0): Revise route installing 1 of 1 routes for 3.3.3.3/32 -> 24.0.0.4(main) to main IP table

R2#

*Mar  1 00:36:40.847: BGP(0): 12.0.0.1 NEXT_HOP is set to self for net 3.3.3.1/32,

*Mar  1 00:36:40.851: BGP(0): 12.0.0.1 send UPDATE (format) 3.3.3.1/32, next 12.0.0.2, metric 0, path 4

*Mar  1 00:36:40.851: BGP(0): 12.0.0.1 NEXT_HOP is set to self for net 3.3.3.2/32,

*Mar  1 00:36:40.855: BGP(0): 12.0.0.1 send UPDATE (prepend, chgflags: 0x820) 3.3.3.2/32, next 12.0.0.2, metric 0, path 4

*Mar  1 00:36:40.855: BGP(0): 12.0.0.1 NEXT_HOP is set to self for net 3.3.3.3/32,

*Mar  1 00:36:40.855: BGP(0): 12.0.0.1 send UPDATE (prepend, chgflags: 0x820) 3.3.3.3/32, next 12.0.0.2, metric 0, path 4

Event - routes from 24.0.0.4 have been advertised with a longer AS-Path, R2 chooses R1 as the best path and withdraws the prefixes from R1.

R2#show ip bgp summary | be InQ

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

12.0.0.1        4    12      38      46       25    0    0 00:06:21        3

24.0.0.4        4     4      34      25       25    0    0 00:10:29        3

R2#show ip bgp

   Network          Next Hop            Metric LocPrf Weight Path

*>i3.3.3.1/32       12.0.0.1                 0    100      0 3 i

*                   24.0.0.4                 0             0 4 4 3 i

*>i3.3.3.2/32       12.0.0.1                 0    100      0 3 i

*                   24.0.0.4                 0             0 4 4 3 i

*>i3.3.3.3/32       12.0.0.1                 0    100      0 3 i

*                   24.0.0.4                 0             0 4 4 3 i

R2#

*Mar  1 00:37:10.943: BGP(0): 24.0.0.4 rcvd UPDATE w/ attr: nexthop 24.0.0.4, origin i, metric 0, path 4 4 3

*Mar  1 00:37:10.943: BGP(0): 24.0.0.4 rcvd 3.3.3.3/32

*Mar  1 00:37:10.947: BGP(0): 24.0.0.4 rcvd 3.3.3.2/32

*Mar  1 00:37:10.947: BGP(0): 24.0.0.4 rcvd 3.3.3.1/32

*Mar  1 00:37:10.951: BGP(0): Revise route installing 1 of 1 routes for 3.3.3.1/32 -> 12.0.0.1(main) to main IP table

*Mar  1 00:37:10.951: BGP(0): Revise route installing 1 of 1 routes for 3.3.3.2/32 -> 12.0.0.1(main) to main IP table

*Mar  1 00:37:10.955: BGP(0): Revise route installing 1 of 1 routes for 3.3.3.3/32 -> 12.0.0.1(main) to main IP table

R2#

*Mar  1 00:37:10.955: BGP(0): 12.0.0.1 send unreachable 3.3.3.1/32

*Mar  1 00:37:10.959: BGP(0): 12.0.0.1 send UPDATE 3.3.3.1/32 -- unreachable

*Mar  1 00:37:10.959: BGP(0): 12.0.0.1 send UPDATE 3.3.3.2/32 -- unreachable

*Mar  1 00:37:10.959: BGP(0): 12.0.0.1 send UPDATE 3.3.3.3/32 -- unreachable

R2#show run | se router bgp

router bgp 12

no synchronization

bgp log-neighbor-changes

neighbor 12.0.0.1 remote-as 12

neighbor 12.0.0.1 route-reflector-client

neighbor 12.0.0.1 next-hop-self

neighbor 24.0.0.4 remote-as 4

neighbor 24.0.0.4 prefix-list n0thing out

no auto-summary

=================================================================================

R1

R1#show ip bgp summary | be InQ

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

12.0.0.2        4    12      51      42        4    0    0 00:10:34        3

13.0.0.3        4     3      29      27        4    0    0 00:24:19        3

R1#show ip bgp  

   Network          Next Hop            Metric LocPrf Weight Path

* i3.3.3.1/32       12.0.0.2                 0    100      0 4 i

*>                  13.0.0.3                 0             0 3 i

* i3.3.3.2/32       12.0.0.2                 0    100      0 4 i

*>                  13.0.0.3                 0             0 3 i

* i3.3.3.3/32       12.0.0.2                 0    100      0 4 i

*>                  13.0.0.3                 0             0 3 i

After Event

R1#

BGP(0): 12.0.0.2 rcv UPDATE about 3.3.3.1/32 -- withdrawn

BGP(0): 12.0.0.2 rcv UPDATE about 3.3.3.2/32 -- withdrawn

BGP(0): 12.0.0.2 rcv UPDATE about 3.3.3.3/32 -- withdrawn

R1#show ip bgp summary | be InQ

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

12.0.0.2        4    12      46      38        4    0    0 00:06:54        0

13.0.0.3        4     3      25      23        4    0    0 00:20:39        3

R1#show ip bgp         

   Network          Next Hop            Metric LocPrf Weight Path

*> 3.3.3.1/32       13.0.0.3                 0             0 3 i

*> 3.3.3.2/32       13.0.0.3                 0             0 3 i

*> 3.3.3.3/32       13.0.0.3                 0             0 3 i

So, believe me or not what I had explained is correct. And I do not read rfc's, but 1 thing I am sure of is this is how it works, on Cisco platforms, I have never tested this on other platforms.

-Vishesh

Re: ibgp peer stats recieving routes, then drops most...

Hi Vishesh,

you are right.

I made a simple test with eBGP in my lab it the withdrawn was also sent!

So split horizon with poison-reverse was implemented for BGP by Cisco in fact?

I found this feature also mentioned in this Cisco Press book:

http://www.ciscopress.com/store/bgp-design-and-implementation-9781587051098

on page 283, e.g.

Interestingly no other BGP book/RFC mentioned that.

Good to discuss here to learn something new!

Thanks,

Milan

1373
Views
5
Helpful
20
Replies
CreatePlease to create content