Peering Policies and Route Servers
Jessica Yu
jyy at ans.net
Thu May 2 13:50:16 UTC 1996
>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)
More information about the NANOG
mailing list