Re: Peering Policies and Route Servers

[Jessica Yu <jyy () ans net>]

> There is one thing that the RS can't do.
>
> If A & B are doing 3rd party peering via the RS, the fact that the
> A/RS peering is up & working and that the B/RS peering is up &
> working unfortunately does not tell you if A & B can exchange
> packets.

> If A & B are peering directly, then the fact that the peering is
> up also tells you that they can exchange packets.
>
> Luckily this sort of breakage does not happen very often.
> Unluckily, if it does break, if can be really hard to diagnose.

This could happen at a non-broadcast media NAP such as ATM nap when the
PVCs between RS-A & RS-B are up but the PVC between A-B is down.  But it's 
less likely to happen on a broadcast media NAP.

It'd be ideal that the RS is injected with some intellegence to detect the
fact that A can no long talk to B directly and thus stop passing routes between
A & B.  This will avoid the problem.  But as you pointed out, it rarely 
happens so it may not worth the effort.

 
By the way, if we flip this example around a bit: if A & B peer with the RS 
in addition to peer directly with each other and the bgp session between A & B 
broke for some reason and the connection is still there (i.e. they do not have
bgp session but still can exchange packets), A & B would benifit from the
RS.

                                                        --Jessica
                                                        (speaking for myself) 
- - - - - - - - - - - - - - - - -