Hello,
I’m trying to fix some issues with a BGP session with our MK routers, well rather than issues is behaviour tweaking. Nevertheless my issue is the following, please see the attached picture:
This is from a Looking Glass server (Telia Sonera Carrier), My question is, I can see multiple next-hops to the same prefix, the thing that bugs me is that this update seems to come from the same BGP peer. How is this possible? First time I see something like this (my experience with BGP is not that much I must admit it), I’m used to seeing on Looking Glasses (and BGP routers for that matter) only 1 next-hop address per peer.
Also the actual prefix I’m checking (showed here is only one from google, not the one I’m interested in) is supposed to be learnt from 2 different carriers (Telia is peered with both), one of them I can see here (together with other 3 - 4 updates from different peers), the other one I can’t.
looking-glass servers somehow “compress” the output and only show some of the routes, I mean, is this a common practice? I ask this because I actually need to force the use of the other carrier instead of the one being shown, and the fact that I can’t see it bugs me.
I suspect that Telia is using a new feature in some BGP implementations where more than just the best route is sent to a neighbor, hence the multiple next-hop addresses per peer… but that’s just a wild guess on my part.
Hi,
Thanks for the answer. What about my second question, any insights about it?
Enviado desde mi MotoE2(4G-LTE) mediante Tapatalk
Second question - why don’t you see the other carrier’s path in the list, even if only as a less-preferred route?
I have found it to be very normal not to see the alternative paths in LG sites.
Suppose you’re connected to Telia via border router A, and there’s another border router (B) elsewhere that peers with your other carrier. In general, the carriers will use a high local_pref value on routes learned from customers, and a low local_pref value on any peering points. If they’re not tier1, then they’ll have an even lower pref for routes via carriers they pay for transit services.
I.e. - they most prefer to send traffic on links that make them money, then prefer links that are settlement-free, and then if they MUST, they use links that COST them money.
So, as a customer of Telia, your direct path via router A is going to be their highest preference. So border router A is going to repeat your prefix to its RR, which will push that to the other RRs in the network, etc. So at border router B, there will be the prefix leading to your network via A. Border router B will receive your prefix via one of their peers. They will not like this route as much, so router B will simply tuck this path into its back pocket, and continue to assert itself as the path to your prefix via A. Basically, at this peering point, both carriers are asserting reachability to your prefixes, because neither of them uses the other as their way to reach you. Thus - this path via B doesn’t make it into the core of Telia because router B doesn’t push this path up the food chain to its RR. Thus, you won’t see that path at a LG site which looks into the other parts of the network.
It’s possible that B has sent a “second-best” path announcement to its local RR, which prefers A not B, and only repeats the A route to the other members of that group. So the B path is not present in anything the B-area RR sends up the line. Thus, in the Denver LG, no neighboring router of the Denver-area’s RR even knows about B’s path to reach you.
Thank you very much for your time. Really nice answer 
Enviado desde mi MotoE2(4G-LTE) mediante Tapatalk