From: vatry 2T (vatry2t@googlemail.com)
Date: Sun Jul 13 2008 - 15:10:20 ART
Thanks for the reply,
IOS is 12.4(18) Advanced Enterprise Services
Both R2 and R3 are Area Border Routers (R1 is in area 0 while R4 is in area
1). R2 and R3 have one interface on either area.
When R1 is an ASBR redistributing networks from another protocol, if you
configure:
R4 -- distance 80 10.1.1.1 0.0.0.0
it does assign AD 80 to all networks that R1 is redistributing. However, it
does it on both paths to R2 and R3, so you are still load balancing.
If all R1,2,3,4 were on the same area, that command would also assign AD 80
to all networks R4 is advertising with the network statement.
But when you try to change on R4 the distance of Inter-Area routers using
the router ID of the router that originated the network, it does not work.
I have tried configuring R2 and R3 with 2 OSPF processes, one facing R1 and
another one facing R4 and redistributing between them. It is doing exactly
the same, depending on which one is the last one to receive the update from,
it keeps the AD of both paths or it changes on both paths.
Summarizing:
- If R1, R2, R3 and R4 are on the same area, you can't select which path to
take on routes originated on R1 or beyond using the AD because you are
modifying both paths
- If R1 and R4 are on different areas, you can't select which path to take
on routes originated on R1 or beyond using the AD because the router that
originated the route is not on the same area and the distance command
doesn't change anything. If you change the AD using R2 router ID, depending
on which update comes first to R4 (R2 or R3) it will change AD of both paths
or none.
- If R2 and R3 are on different OSPF processes, the same as the last point.
It seems it's going to be a bug. I'll try changing the IOS and see if that
makes a difference.
Thanks
On 7/13/08, Marvin Greenlee <mgreenlee@ipexpert.com> wrote:
>
> The ospf distance command is used to manipulate distance for the router ID
> of the router that is originating the network into OSPF, which is not
> always
> the router that you received the update from.
>
> In this case, if R1 is originating the network into OSPF, I wouldn't expect
> changing distance for the router ID of 2 or 3 to have an effect for the
> network from R1. In your output, you show config of 'distance 80', but
> none
> of your debug shows an AD of 80. Do you have other distance commands
> configured?
>
>
> If R2 and R3 were border routers, and the connections between R1, R2, and
> R3
> were a different process that both R2 and R3 were redistributing into a
> process between R2, R3, and R4, then R2 and R3 would be the ones
> originating
> the network into OSPF, and R4 could match based on the router ID of R2 or
> R3.
>
> Marvin Greenlee, CCIE #12237 (R&S, SP, Sec)
> Senior Technical Instructor - IPexpert, Inc.
> Telephone: +1.810.326.1444
> Fax: +1.810.454.0130
> Mailto: mgreenlee@ipexpert.com
>
> Progress or excuses, which one are you making?
>
>
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> vatry2t@gmail.com
> Sent: Sunday, July 13, 2008 5:04 AM
> To: ccielab@groupstudy.com
> Subject: OSPF distance change with same cost
>
> 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