[33245] in North American Network Operators' Group
BGP Persistent Route Oscillation Condition
daemon@ATHENA.MIT.EDU (Clayton Fiske)
Thu Jan 4 23:32:51 2001
Date: Thu, 4 Jan 2001 20:29:06 -0800
From: Clayton Fiske <clay@bloomcounty.org>
To: nanog@merit.edu
Message-ID: <20010104202906.Y450@bloomcounty.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Errors-To: owner-nanog-outgoing@merit.edu
In reference to:
http://www.ietf.org/internet-drafts/draft-mcpherson-bgp-route-oscillation-00.txt
I keep trying to see if I'm overlooking something. The first Type
I Churn example (using route reflectors) has either omitted something,
or is inconsistent in the following 2 steps:
---
2) Rd receives the UPDATE from Ra, which leaves Rd with the
following installed in its BGP table:
NEXT_HOP
AS_PATH MED IGP Cost
-----------------------
* 6 100 0 12
6 100 1 5
Rd then marks the '6 100, 0, 12' route as best because it has
a lower MED. Rd sends an UPDATE message to its neighbors to
let them know that this is the best route.
3) Ra receives the UPDATE message from Rd and now has the
following in its BGP table:
NEXT_HOP
AS_PATH MED IGP Cost
-----------------------
6 100 0 13
6 100 1 4
* 10 100 10 5
The first route (6 100, 0, 13) beats the second route (6 100,
1, 4) because of lower MED, then the third route (10 100, 10,
5) beats the first route because of lower IGP metric to
NEXT_HOP. Ra sends an UPDATE message to its peers to let them
know its new best route.
---
In step 2, the first route is chosen because of a lower MED, but the
lower IGP cost of the second route is ignored.
In step 3, the third route is chosen by lower IGP cost, despite having
a higher MED than the first.
Am I simply forgetting something here?
-c