From: Petr Lapukhov (petr@internetworkexpert.com)
Date: Sun Jul 13 2008 - 12:05:54 ART
What IOS version are you using on the router that manipulates the ADs? There
is a bug CSCeh46993 which affects OSPF distance manipulation in IOS 12.3T
and 12.4 trains. Just to make it sure, I verified that with 12.2T image. It
does work fine it old images, while causes all sorts of weird behavior with
12.4 images.
With correctly working OSPF implementation you should see debugging output
(debug ip routing) like the following:
RT: closer admin distance for 10.0.0.1, flushing 1 routes
RT: add 10.0.0.1/32 via 155.1.146.6, ospf metric [10/2]
RT: NET-RED 10.0.0.1/32
RT: NET-RED queued, Queue size 4
-- Petr Lapukhov, CCIE #16379 (R&S/Security/SP/Voice) petr@internetworkexpert.comInternetwork Expert, Inc. http://www.InternetworkExpert.com
2008/7/13 <vatry2t@gmail.com>:
> Hi, > > Imagine a router R1 connected to two routers (R2 and R3) and those two > routers > connected to a single fourth router (R4) (1 - 2 - 1 scenario). After > configuring OSPF, the R4 is load balancing routes originated on R1. > > R1 lo0 is 10.1.1.1 > R2 lo0 is 10.1.2.2 > R3 lo0 is 10.1.3.3 > R4 lo0 is 10.1.4.4 > > R4 routes: > > O IA 10.1.1.1/32 [110/129] via 19.1.2.2, 00:12:59, Serial2/3 (through > R2) > [110/129] via 19.1.3.3, 00:12:59, Serial2/2 (through > R3) > > When I go to R4 > > access-list 1 permit 10.1.1.1 > router ospf 1 > distance 80 10.1.2.2 0.0.0.0 1 (to prefer route to R1 loopback 0 > through > R2) > > This is the output of debug ip routing > > *Apr 15 23:25:39.789: RT: add 10.1.1.1/32 via 19.1.2.2, ospf metric > [10/129] > *Apr 15 23:25:39.789: RT: NET-RED 10.1.1.1/32 > *Apr 15 23:25:39.789: RT: add 10.1.1.1/32 via 19.1.3.3, ospf metric > [110/129] > *Apr 15 23:25:39.789: RT: NET-RED 10.1.1.1/32 > > It seems it is changing the administrative distance of the route learned > from > R2 but when you look at the routing table is still the same: > > Routing entry for 10.1.1.1/32 > Known via "ospf 1", distance 110, metric 129, type inter area > Last update from 19.1.3.3 on Serial2/3, 00:00:07 ago > Routing Descriptor Blocks: > 19.1.2.2, from 10.1.2.2, 00:00:07 ago, via Serial2/3 > Route metric is 129, traffic share count is 1 > * 19.1.3.3, from 10.1.3.3, 00:00:07 ago, via Serial2/2 > Route metric is 129, traffic share count is 1 > > If you look at the last update, it is coming from R3. If you shut down both > links from R4 to R3 and R2, first no shutdown link to R3 and then no > shutdown > link to R2, the distance of both learned routes is changed to 10 because > the > last update is from R2 (which we have manually changed the administrative > distance) > > Routing entry for 10.1.1.1/32 > Known via "ospf 1", distance 10, metric 129, type inter area > Last update from 139.1.13.1 on Serial2/2, 00:00:01 ago > Routing Descriptor Blocks: > * 19.1.2.2, from 10.1.2.2, 00:00:01 ago, via Serial2/3 > Route metric is 129, traffic share count is 1 > 19.1.3.3, from 10.1.3.3, 00:00:01 ago, via Serial2/2 > Route metric is 129, traffic share count is 1 > > I have tried configuring all the routers on the same area, configuring > multipoint interfaces instead of point-to-point subinterfaces, configuring > traffic coming on different interfaces but the result is the same. Either > it > keeps the metric unchanged on both paths or it changes to both paths, > depending > on which router it gets the last update from. > > Could anybody help with that? It's driving me crazy. > > Thanks for that! > > > _______________________________________________________________________ > Subscription information may be found at: > http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Mon Aug 04 2008 - 06:11:54 ART