[c-nsp] Fundamental BGP differences in 12.2.26 vs 12.2.25S?
signal at shreve.net
Tue Oct 19 11:32:07 EDT 2004
I am dealing with a situation right now, where we had a router change
from 12..2.26 to 12.2.25S.
When this happened, it appears the behavior of a certain BGP session
changed. Because I cannot
easily go back in time to when we were running the 12.2.26, I cannot
see just what differences were then
vs. now, the configurations however are the same, so I am thinking it
must be something in the IOS.
Let me briefly explain.
A customer has 2 BGP sessions to our AS. There are reasons for this,
but I wont go into them here.
He was preferring routes from Session #1 over Session #2. After
upgrading the IOS to 12..2.25S,
the routes to Session #2 are always preferred. I can of course, pull
up the BGP table and clearly see
that the routes are being preferred for Session #2 because Session #2
has no med (or med 0), and
Session #1 has a med of 20. All other things are equal.up that that
point in the BGP Selection.
As I said nothing changed in the config. And I should assume that
includes metric. So I was wondering
if for example, if something in the IOS had changed that could be
causing this. The problem was easily
fixed but here was the crux of the problem:
Customer <---------------- eBGP ---------------> Directly
The directly connected neighbor is not the "Real" BGP session where the
customer learns full routes. It only exists, so that the customer can
exchange loopback addresses for the real BGP session to be able to come
Customer <------------------eBGP Multihop ------------------> Multihop
neighbor, loopback peering
Ok, some of you may see where I am going with this, but basically the
Customer learns the eBGP multihop loopback address from its first
directly connected BGP session. Then it can bring up its multihop
session. Then the multihop session teaches the Customer about itself
(gives the customer its loopback address via bgp). The customer
prefers this advertisement over what it learned in the directly
connection session. This is bad, because there is no next-hop
reachability for the multihop loopback learned via the multihop
neighbor. This causes the entire routes learned to be invalidated (By
BGP Scanner, etc), and just starts a real mess.
Alot of things can be extracted. One is I don't like the idea of using
a BGP session merely to learn loopbacks, to bring up a multihop
session.....its asking for trouble. This choice was not in my control,
i would have used statics for the loopback reachability. Also, of
course you should not be giving the essential reachability information
of your ebgp peer from both the directly connection session AND the
ebgp session. But this doesn't explain why there were no problems in
this under 12.2.26, which is why I am trying to put this together now,
and sort out in my head why it was managing to work under 12.2.26. For
example, one explaination would be if 12.2.26 defaulted to the IETF
guidelines of "missing med = highest possible med", that would explain
it for example, but I don't think that is how 12.2.26 behaves.
If anyone has any insight on this, I would be interested in hearing
Brian Feeny, CCIE #8036, CISSP
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 186 bytes
Desc: This is a digitally signed message part
Url : https://puck.nether.net/pipermail/cisco-nsp/attachments/20041019/8e82c7bb/PGP.bin
More information about the cisco-nsp