Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Persistent BGP peer flapping - do you care?

  • From: Susan Hares
  • Date: Thu Jan 17 16:17:13 2002

Chris:

Thanks for the input.  This is the revisit the
specification time.   Just to confirm your
answer, I'll paraphrase it and let you know what happened.

the persistent bgp peer flapping
happens when you (one of the paths)

        1) Error causes stop
           (bad prefix --> drop connection)

        2) BGP peer goes to IDLE state
        3) Automatic restart happens (cisco doesn't utilize the
                backoff)
        4) Open sent
        5) active
        6) error due to bad prefix still being sent
        7) Idle Hold time (time delay here)

        --> go back to #1

Specification says to slow down the cycle of
the establishing by increase the time delay
in step #7.

I think we are describing the same problem.  Could you
please confirm?

At 03:10 PM 1/17/2002 -0500, Christopher A. Woodfield wrote:
This has been bandied about before, but one should note that the "drop the
peer if an error is received" is only really effective if the session that
initiated the error does not propogate it. Most Cisco routers running common IOS images not only do not drop the session, but pass along the bad prefix, which
leads to the occasional bad route dropping peering sessions on most of
the Enterasys(*) routers on the planet.
Do the peering sessions drop once or repeatedly until
the bad prefix gets cleared out?


I guess the main question is what is considered an "error" - if the peer starts obviously misbehaving, then yet, drop the peer. But don't drop the peer due to an invalid prefix that most likely did not ori0ginate on that router - it would be much better for the 'net as a whole to
just drop the bad prefix and carry on. Maybe a
algorithm could be built in where the peer could be dropped if the number of bad
prefixes exceeds a set threshold...

The algorithms for what constitutes a "drop" can be an implementation
detail or be specified as an optional portion of the next version
of the BGP specification.


In short, the "drop the session when you get a bad prefix" only works its intended
purpose when every router that speaks BGP does this. If that can't be had, we
should really revisit the spec in that regard.
The specification says "recommended" (should) now and as we noted with
cisco, not all vendors implement it.   We are documenting
existing practice so recommended/should will remain.

If you think it is a very serious operational issue, you
can always input to the idr mailing list that the "should" needs
to be "must" due to an operational issues.


Thanks again for answering the cry for help!

Sue






Discussion Communities


About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home


Merit Network, Inc.