Yeah I noticed that too once I hit send...good catch :) On Wed, Sep 16, 2009 at 10:56 AM, amit chopra <[email protected]>wrote:
> The problem is here that tunnel IP address is on different subnets once it > is configured same subnet , it will resolve issue. > I am really crazy :) > > > On Wed, Sep 16, 2009 at 6:23 PM, Bryan Bartik <[email protected]>wrote: > >> Amit, >> >> Do you have an adjacency over tunnel 0? It's not enough just to build the >> tunnel. Put the tunnel in Area 0 otherwise R3 is still not connected to Area >> 0. If the interface is advertised but there is no adjacency then you have a >> partitioned area 0. >> >> On Tue, Sep 15, 2009 at 11:00 PM, amit chopra <[email protected]>wrote: >> >>> Guys >>> >>> I am facing a strange issue with below topology in OSPF: The same has >>> been posted on internetworkexpert forum ( >>> http://ieoc.com/forums/t/8231.aspx) but as usual no reply by anyone so >>> I am posting this problem here as well , hope someone help. >>> >>> (R1 s0/0)------*AREA 0* ------------s0/0 (R2 F0/1)----------------*AREA >>> 1-*----------(F0/1 R3)-----------*AREA 2*----------- (R4) >>> 192.168.12.0/24 >>> 192.168.24.0/24 >>> >>> >>> As you can see that R4 is not connected to backbone router therefore it >>> is require virtual link or tunnel. >>> for this configuration , I used tunnel to configure between R2 and R3 >>> >>> Below is the config :- >>> >>> R2 - >>> >>> interface Tunnel0 >>> ip address 22.22.22.22 255.255.255.0 >>> ip ospf network broadcast >>> tunnel source 192.168.23.2 >>> tunnel destination 192.168.23.3 >>> end >>> >>> >>> R3 >>> >>> interface Tunnel0 >>> ip address 33.33.33.33 255.255.255.0 >>> ip ospf network broadcast >>> tunnel source 192.168.23.3 >>> tunnel destination 192.168.23.2 >>> end >>> >>> The 22.22.22.22 and 33.33.33.33 has been advertise into (tunnel IP) AREA >>> 0 : >>> >>> >>> R2#sh run | sec router ospf >>> router ospf 1 >>> router-id 2.2.2.2 >>> log-adjacency-changes >>> network 2.2.2.2 0.0.0.0 area 1 >>> network 22.22.22.22 0.0.0.0 area 0 >>> network 192.168.12.2 0.0.0.0 area 0 >>> network 192.168.23.2 0.0.0.0 area 1 >>> >>> >>> Now the issue is that , I am able to ping 22.22.22.22 address from router >>> R3 but not able to do ping 33.33.33.33 >>> from R2 , The tunnel is up both end side. >>> >>> if I check the ospf database on R2 for network 33.33.33.0/24 , you can >>> see that it is there in database but >>> not in routing table as ROUTING BIT IS NOT SET >>> >>> R2#show ip ospf database sum 33.33.33.0 >>> >>> OSPF Router with ID (2.2.2.2) (Process ID 1) >>> >>> Summary Net Link States (Area 1) >>> >>> LS age: 48 >>> Options: (No TOS-capability, DC, Upward) >>> LS Type: Summary Links(Network) >>> Link State ID: 33.33.33.0 (summary Network Number) >>> Advertising Router: 3.3.3.3 >>> LS Seq Number: 80000005 >>> Checksum: 0xD2A >>> Length: 28 >>> Network Mask: /24 >>> TOS: 0 Metric: 11111 >>> >>> TOS: 0 Metric: 11111 >>> >>> >>> if you do same command on R3 for network 22.22.22.0 then :- >>> >>> >>> R3#show ip ospf database sum 22.22.22.0 >>> >>> OSPF Router with ID (3.3.3.3) (Process ID 1) >>> >>> Summary Net Link States (Area 1) >>> >>> Routing Bit Set on this LSA <---- NOTE >>> LS age: 1471 >>> Options: (No TOS-capability, DC, Upward) >>> LS Type: Summary Links(Network) >>> Link State ID: 22.22.22.0 (summary Network Number) >>> Advertising Router: 2.2.2.2 >>> LS Seq Number: 80000007 >>> Checksum: 0xB4A5 >>> Length: 28 >>> Network Mask: /24 >>> TOS: 0 Metric: 11111 >>> >>> You can see that routing bit set for 22.22.22.0 on R3 and it is there in >>> routing table. I can ping this network >>> >>> Ping Test :- >>> >>> R2#ping 33.33.33.33 >>> >>> Type escape sequence to abort. >>> Sending 5, 100-byte ICMP Echos to 33.33.33.33, timeout is 2 seconds: >>> ..... >>> Success rate is 0 percent (0/5) >>> R2# >>> R2# >>> R2#show ip route 33.33.33.33 >>> % Network not in table >>> >>> R3#ping 22.22.22.22 >>> >>> Type escape sequence to abort. >>> Sending 5, 100-byte ICMP Echos to 22.22.22.22, timeout is 2 seconds: >>> !!!!! >>> Success rate is 100 percent (5/5), round-trip min/avg/max = 16/40/80 ms >>> R3# >>> R3#show ip route 22.22.22.22 >>> Routing entry for 22.22.22.0/24 >>> Known via "ospf 1", distance 110, metric 11112, type inter area >>> Last update from 192.168.23.2 on FastEthernet1/0, 00:17:55 ago >>> Routing Descriptor Blocks: >>> * 192.168.23.2, from 2.2.2.2, 00:17:55 ago, via FastEthernet1/0 >>> Route metric is 11112, traffic share count is 1 >>> >>> The another thing is that if I shutdown serial interface S0/0 of R2 then >>> I am able to ping 33.33.33.33 network , The S0/0 is touch to backbone area >>> (area 0) >>> >>> R2#config t >>> Enter configuration commands, one per line. End with CNTL/Z. >>> R2(config)#int s0/0 >>> R2(config-if)#shut >>> R2(config-if)# >>> *Mar 1 02:09:46.111: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.1 on Serial0/0 >>> from F >>> ULL to DOWN, Neighbor Down: Interface down or detached >>> *Mar 1 02:09:48.095: %LINK-5-CHANGED: Interface Serial0/0, changed state >>> to adm >>> inistratively down >>> *Mar 1 02:09:49.095: %LINEPROTO-5-UPDOWN: Line protocol on Interface >>> Serial0/0, >>> changed state to down >>> R2(config-if)# >>> R2(config-if)# >>> R2(config-if)# >>> R2(config-if)#end >>> R2# >>> R2# >>> R2#ping 33.33.33.33 >>> >>> Type escape sequence to abort. >>> Sending 5, 100-byte ICMP Echos to 33.33.33.33, timeout is 2 seconds: >>> !!!!! >>> Success rate is 100 percent (5/5), round-trip min/avg/max = 8/36/116 ms >>> R2# >>> R2# >>> R2#show ip ospf database sum 33.33.33.0 >>> >>> OSPF Router with ID (2.2.2.2) (Process ID 1) >>> >>> Summary Net Link States (Area 1) >>> >>> Routing Bit Set on this LSA (<--- Now routing bit set) >>> LS age: 1980 >>> Options: (No TOS-capability, DC, Upward) >>> LS Type: Summary Links(Network) >>> Link State ID: 33.33.33.0 (summary Network Number) >>> Advertising Router: 3.3.3.3 >>> LS Seq Number: 80000004 >>> Checksum: 0xF29 >>> Length: 28 >>> Network Mask: /24 >>> TOS: 0 Metric: 11111 >>> >>> Regards >>> Amit Chopra >>> >>> _______________________________________________ >>> For more information regarding industry leading CCIE Lab training, please >>> visit www.ipexpert.com >>> >>> >> >> >> -- >> Bryan Bartik >> CCIE #23707 (R&S), CCNP >> Sr. Support Engineer - IPexpert, Inc. >> URL: http://www.IPexpert.com >> > > -- Bryan Bartik CCIE #23707 (R&S), CCNP Sr. Support Engineer - IPexpert, Inc. URL: http://www.IPexpert.com
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
