|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Peering Policies and Route Servers
>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) - - - - - - - - - - - - - - - - -
|