[c-nsp] Fundamental BGP differences in 12.2.26 vs 12.2.25S?

[Brian Feeny]

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 
connected neighbor

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 
up.

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 
about it.

Brian

---------------------------------------------
Brian Feeny, CCIE #8036, CISSP
Network Engineer
ShreveNet Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : https://puck.nether.net/pipermail/cisco-nsp/attachments/20041019/8e82c7bb/PGP.bin