Hi everyone,
I have one bgp convergence problem which confused me. The problem is as follows:
Hi Song Li,
As far as I know there are 2 mechanisms that should prevent this situation you describe from happening:
- Not advertising routes that are not in the RIB
Once AS1's peering with AS3 comes back up, the route through AS3 is learned and preferred. Therefore the route via AS2 is purged from the RIB. Once it is no longer in the RIB, AS1 cannot announce that path anymore.
- AS Path loop prevention
If AS1 still leaks the prefix to AS3, it can only announce the active path which points to AS3 itself. Therefore AS3 will see a prefix with its own ASN in the path and (should) drop the prefix. Crisis avoided.
My textbook knowledge is a bit rusty though..
Dennis Hagens
Song Li schreef op 5/6/14 5:58 AM:
Hi Dennis,
I think there are two possible convergence results:
1/ AS3 accepted route 16.1/16(2 4 5) from AS1, then it will withdraw announce of 16.1/16(5) towards AS1. And AS1 will remain 16.1/16 (2 4 5).
2/ AS1 accepted route 16.1/16(3 5) from AS3, then it withdraw 16.1/16(2 4 5), and AS3 will remain 16.1/16(5).
I simulated this case in GNS3, and only got the first kind of result, i don't know why?
Song
δΊ 2014/5/6 18:13, ISP Services ει:
I suggest you work your way down 
http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13753-25.html
Dennis Hagens
Song Li schreef op 5/6/14 1:42 PM:
You may want to Google for 'BGP Wedgie'.
https://www.nanog.org/meetings/nanog31/presentations/griffin.pdf
http://www.rfc-base.org/txt/rfc-4264.txt
Once you understand how and why they happen, your routing question
will become clear.
I have one bgp convergence problem which confused me. The problem is as
follows:+--------+
> AS5 |
+------+16.1/16 |
> +-----+--+
> >
+---+--+ |
> AS4 | |
> > >
++-----+ |
> >
> >
> >
+-----+--+ +-+-----+
> AS2 | | AS3 | 16.1/16 (5)
> ISP | | ISP |
+---^----+ +---^---+
> >
> +--------+ |
+-----+ AS1 +----+
>customer>
+--------+
16.1/16 (2 4 5)AS1 multihomed to AS2 and AS3, for some reasons AS1 disconnect from AS3,
and as a resutl the route to 16.1/16 will be 16.1/16 (2 4 5).After a while, the BGP seesion between AS1 and AS3 reestablished but
AS1 leaks the route 16.1/16 (2 4 5) to AS3. At this point,1/ AS1 will have two bgp routes for prefix 16.1/16: 16.1/16(2 4 5)and
16.1/16(3 5), according to shorter AS_PATH it will select 16.1/16(3 5)
as best route.2/ AS3 also have two bgp routes: 16.1/16(2 4 5) and 16.1/16(5),
according to local_pref it will select 16.1/16(2 4 5).in this case, AS1 and AS3 select each other as the best route to AS5, i
wonder which route will be the final best route after bgp convergence in
AS1 and AS3.
this is a bgp wedgie. is it real and caught in the wild? tim would be
cheered.
randy
Operationally speaking, AS1 should not be leaking routes from one upstream to the other. Bad route policy. Also, AS3 should not accept routes from AS1 that don't belong to it. Customer router filtering would prevent this.
How I wish this happened in real life.
We are chasing route leaks several AS's down the path that
are not even remotely connected to us on a weekly basis. But
I guess that's what they pay us for :-(.
Mark.
Operationally speaking, AS1 should not be leaking routes
from one upstream to the other. Bad route policy.
ideally it'd be nice to be valley-free... so to speak.
Also, AS3 should not accept routes from AS1 that don't
belong to it. Customer router filtering would prevent
this.
always with the route filtering... routes want to be free man, free!
How I wish this happened in real life.
We are chasing route leaks several AS's down the path that
are not even remotely connected to us on a weekly basis. But
I guess that's what they pay us for :-(.
if only there were some technology that could be used to thwart such things.
It's gotten to a point where a repeat offender has me wound
up enough to prepend his AS into some of my paths.
I wish there was a simpler way to "turn them off".
Mark.
that's bad news... config hackery is brittle.
(but fun)
Don't I know :-)... *sigh*
Mark.