From: Alberto Riopa (alriopaccie@gmail.com)
Date: Sat Jan 12 2008 - 14:51:30 ARST
Hi,
This must be indeed a bug. I tested in 123-23 (yes, I know, a bit old :-) )
and as soon as you apply the distance command everything works: all the
traffic is redirected via R1:
Rack1R5(config-router)#do sir ospf
139.1.0.0/24 is subnetted, 14 subnets
O IA 139.1.11.0 [105/74] via 139.1.15.1, 00:00:02, Serial0/0.51
O IA 139.1.13.0 [110/128] via 139.1.15.1, 00:00:02, Serial0/0.51
O IA 139.1.2.0 [105/202] via 139.1.15.1, 00:00:02, Serial0/0.51
<------- Check it out
O IA 139.1.0.0 [105/138] via 139.1.15.1, 00:00:02, Serial0/0.51
O IA 139.1.6.0 [105/139] via 139.1.15.1, 00:00:02, Serial0/0.51
O IA 139.1.7.0 [105/139] via 139.1.15.1, 00:00:02, Serial0/0.51
O IA 139.1.23.0 [110/128] via 139.1.25.2, 00:00:02, Serial0/0.52
150.1.0.0/16 is variably subnetted, 8 subnets, 2 masks
O IA 150.1.7.7/32 [110/139] via 139.1.15.1, 00:00:02, Serial0/0.51
[110/139] via 139.1.25.2, 00:00:02, Serial0/0.52
O IA 150.1.6.6/32 [110/139] via 139.1.15.1, 00:00:02, Serial0/0.51
[110/139] via 139.1.25.2, 00:00:02, Serial0/0.52
O IA 150.1.3.3/32 [110/129] via 139.1.15.1, 00:00:02, Serial0/0.51
[110/129] via 139.1.25.2, 00:00:02, Serial0/0.52
O 150.1.2.2/32 [110/65] via 139.1.25.2, 00:00:04, Serial0/0.52
O 150.1.1.1/32 [110/65] via 139.1.15.1, 00:00:04, Serial0/0.51
If we shutdown the interface, there we go: everything via R2, as expected:
Rack1R5(config-router)#int se0/0.51
Rack1R5(config-subif)#shut
Rack1R5(config-subif)#
*Mar 1 04:21:35.084: %OSPF-5-ADJCHG: Process 1, Nbr 150.1.1.1 on
Serial0/0.51 from FULL to DOWN, Neighbor Down: Interface down or detached
Rack1R5(config-subif)#
*Mar 1 04:21:39.988: %LINEPROTO-5-UPDOWN: Line protocol on Interface
Tunnel0, changed state to down
Rack1R5(config-subif)#do sir ospf
139.1.0.0/24 is subnetted, 13 subnets
O IA 139.1.11.0 [110/202] via 139.1.25.2, 00:00:17, Serial0/0.52
O IA 139.1.15.0 [110/256] via 139.1.25.2, 00:00:17, Serial0/0.52
O IA 139.1.13.0 [110/192] via 139.1.25.2, 00:00:17, Serial0/0.52
O IA 139.1.2.0 [110/74] via 139.1.25.2, 00:00:17, Serial0/0.52
O IA 139.1.0.0 [110/138] via 139.1.25.2, 00:00:17, Serial0/0.52
O IA 139.1.6.0 [110/139] via 139.1.25.2, 00:00:17, Serial0/0.52
O IA 139.1.7.0 [110/139] via 139.1.25.2, 00:00:17, Serial0/0.52
O IA 139.1.23.0 [110/128] via 139.1.25.2, 00:00:17, Serial0/0.52
150.1.0.0/16 is variably subnetted, 8 subnets, 2 masks
O IA 150.1.7.7/32 [110/139] via 139.1.25.2, 00:00:17, Serial0/0.52
O IA 150.1.6.6/32 [110/139] via 139.1.25.2, 00:00:17, Serial0/0.52
O IA 150.1.3.3/32 [110/129] via 139.1.25.2, 00:00:17, Serial0/0.52
O 150.1.2.2/32 [110/65] via 139.1.25.2, 00:00:17, Serial0/0.52
O IA 150.1.1.1/32 [110/193] via 139.1.25.2, 00:00:17, Serial0/0.52
The problem comes when we bring serial0/0.51 up again, there is one route
(VLAN 2) that remains with distance 110 (instead of the configured 105):
Rack1R5(config-subif)#no shut
Rack1R5(config-subif)#
*Mar 1 04:22:10.586: %OSPF-5-ADJCHG: Process 1, Nbr 150.1.1.1 on
Serial0/0.51 from LOADING to FULL, Loading Done
Rack1R5(config-subif)#
*Mar 1 04:22:19.990: %LINEPROTO-5-UPDOWN: Line protocol on Interface
Tunnel0, changed state to up
Rack1R5(config-subif)#do sir ospf
139.1.0.0/24 is subnetted, 14 subnets
O IA 139.1.11.0 [105/74] via 139.1.15.1, 00:00:04, Serial0/0.51
O IA 139.1.13.0 [110/128] via 139.1.15.1, 00:00:04, Serial0/0.51
O IA 139.1.2.0 [110/74] via 139.1.25.2, 00:00:04, Serial0/0.52
<------------- AAARRGGHH!!
O IA 139.1.0.0 [105/138] via 139.1.15.1, 00:00:04, Serial0/0.51
O IA 139.1.6.0 [105/139] via 139.1.15.1, 00:00:04, Serial0/0.51
O IA 139.1.7.0 [105/139] via 139.1.15.1, 00:00:04, Serial0/0.51
O IA 139.1.23.0 [110/128] via 139.1.25.2, 00:00:04, Serial0/0.52
150.1.0.0/16 is variably subnetted, 8 subnets, 2 masks
O IA 150.1.7.7/32 [110/139] via 139.1.25.2, 00:00:04, Serial0/0.52
[110/139] via 139.1.15.1, 00:00:04, Serial0/0.51
O IA 150.1.6.6/32 [110/139] via 139.1.25.2, 00:00:04, Serial0/0.52
[110/139] via 139.1.15.1, 00:00:04, Serial0/0.51
O IA 150.1.3.3/32 [110/129] via 139.1.25.2, 00:00:04, Serial0/0.52
[110/129] via 139.1.15.1, 00:00:04, Serial0/0.51
O 150.1.2.2/32 [110/65] via 139.1.25.2, 00:00:05, Serial0/0.52
O 150.1.1.1/32 [110/65] via 139.1.15.1, 00:00:05, Serial0/0.51
As I say, this must be a bug. Bit if this happens to me in the exam, I would
configure a Tunnel between R5 and R1 and put it in area 0 (carefull with the
recursive routing: use R1 lo0 or physical interfaces as the tunnel
destination). It just works and it seems to be complaint with what we are
asked for in task 3.7..
Cheers,
Alberto
On Jan 9, 2008 9:55 AM, Maxim Kurushkin <m.kurushkin@orange-ftgroup.ru>
wrote:
> It is dosen't work.
> I have opened case in Cisco TAC 4 month ago. It is answer from Cisco:
> "Sorry for the delay in getting back to you. The developers are still
> working on this issue. I will contact them again and ask for a status
> update."
> So.
> As a temporary workaround you can do the following:
> R2:
> router ospf 1
> area range 139.1.2.0 <http://139.3.2.0> 255.255.255.0
> <http://255.255.255.0> cost 10000
> area range 139.1.0.0 <http://139.3.2.0> 255.255.255.0
> <http://255.255.255.0> cost 10000
> area range 139.1.11.0 <http://139.3.2.0> 255.255.255.0
> <http://255.255.255.0> cost 10000
> area range 139.1.6.0 <http://139.3.2.0> 255.255.255.0
> <http://255.255.255.0> cost 10000
> area range 139.1.7.0 <http://139.3.2.0> 255.255.255.0
> <http://255.255.255.0> cost 10000
> and the same for another networks.
>
> WBR,
> Maxim
>
> nhatphuc wrote:
> > Hello,
> >
> > Does anyone have a working solution for IEWB Lab 13 task 3.7? It's about
> > ospf distance command.
> >
> > I've searched the IEWB Forum and GS archive but can't find a working
> > solution. The solution in the workbook doesn't work.
> >
> > Thanks for your help
> >
> > Phuc
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> >
> >
>
>
>
> *******************************************************************************************************
> This message and any attachments (the "message") are confidential and
> intended solely for the addressees.
> Any unauthorised use or dissemination is prohibited.
> Messages are susceptible to alteration. Orange Business Services shall not
> be liable for the message if altered, changed or
> falsified. If you are not the intended addressee of this message, please
> cancel it immediately and inform
> the sender.
>
> *******************************************************************************************************
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Fri Feb 01 2008 - 10:37:59 ARST