From: Cristi Grigore (cristi.grigore@gmail.com)
Date: Thu Apr 10 2008 - 20:39:06 ART
Matt, please post all OSPF related configuration from R11, R2 and R5.
On Thu, Apr 10, 2008 at 11:35 PM, Matt Bentley <mattdbentley@gmail.com>
wrote:
> Hi GS:
>
> Sorry to be so long in pasting my configs. In reference to the
> suggestions that the problem is due to recursive routing over the tunnel
> interface over the NSSA area, I thought this initally, but the tunnel stayed
> up and never went down, so I am thinking it is not the case.
>
> *R2 can ping R5*
>
> R1<--------------R2--------------------->R5
> (area 0) Fa0/0 (e0/0)
> <------------------------>
> NSSA Area
> GRE Tunnel
>
> Rack1R2#ping 141.1.145.5
>
> Type escape sequence to abort.
> Sending 5, 100-byte ICMP Echos to 141.1.145.5, timeout is 2 seconds:
> !!!!!
> Success rate is 100 percent (5/5), round-trip min/avg/max = 8/28/60 ms
> Rack1R2#
>
> *R2 can ping R1*
>
>
> Rack1R2#ping 141.1.123.1
>
> Type escape sequence to abort.
> Sending 5, 100-byte ICMP Echos to 141.1.123.1, timeout is 2 seconds:
> !!!!!
> Success rate is 100 percent (5/5), round-trip min/avg/max = 8/36/80 ms
> Rack1R2#
>
>
> *R1 has a route to R5*
>
>
> Rack1R1#sh ip route 141.1.145.5
> Routing entry for 141.1.145.0/24
> Known via "ospf 1", distance 110, metric 11185, type inter area
> Last update from 141.1.123.2 on Serial1/0.1, 00:07:38 ago
> Routing Descriptor Blocks:
> * 141.1.123.2, from 150.1.5.5, 00:07:38 ago, via Serial1/0.1
> Route metric is 11185, traffic share count is 1
>
> *R5 has a route to R1
>
> *
> Rack1R5#sh ip route 141.1.123.1
> Routing entry for 141.1.123.0/24
> Known via "ospf 1", distance 110, metric 11175, type intra area
> Last update from 1.1.1.2 on Tunnel0, 00:09:10 ago
> Routing Descriptor Blocks:
> * 1.1.1.2, from 150.1.2.2, 00:09:10 ago, via Tunnel0
> Route metric is 11175, traffic share count is 1*
>
> R1 can reach R5, but R5 can't get back*
> Rack1R1#ping 141.1.145.5
>
> Type escape sequence to abort.
> Sending 5, 100-byte ICMP Echos to 141.1.145.5, timeout is 2 seconds:
> ....
> Success rate is 0 percent (0/5)
>
>
> Rack1R5#debug ip icmp
> ICMP packet debugging is on
> Rack1R5#
> *Mar 1 09:49:29.837: ICMP: echo reply sent, src 141.1.145.5, dst
> 141.1.123.1
> Rack1R5#
> *Mar 1 09:49:31.857: ICMP: echo reply sent, src 141.1.145.5, dst
> 141.1.123.1*
> *
> *Following the traceroute, the packet should go from R5 out the tunnel
> interface to R2*
>
> Rack1R5#sh ip route 141.1.123.1
> Routing entry for 141.1.123.0/24
> Known via "ospf 1", distance 110, metric 11175, type intra area
> Last update from 1.1.1.2 on Tunnel0, 00:11:53 ago
> Routing Descriptor Blocks:
> * 1.1.1.2, from 150.1.2.2, 00:11:53 ago, via Tunnel0
> Route metric is 11175, traffic share count is 1*
> *
> *As soon as I configure a static route out either the Ethernet OR tunnel
> interface, it works fine*
>
>
> Rack1R5(config)#ip route 141.1.123.1 255.255.255.255 e0/1
> Rack1R5(config)#do ping 141.1.123.1
>
> Type escape sequence to abort.
> Sending 5, 100-byte ICMP Echos to 141.1.123.1, timeout is 2 seconds:
> .!!!!
> Success rate is 80 percent (4/5), round-trip min/avg/max = 24/47/100 ms
> Rack1R5(config)#
>
>
> Rack1R5(config)#no ip route 141.1.123.1 255.255.255.255 e0/1
> Rack1R5(config)#ip route 141.1.123.1 255.255.255.255 tun0
> Rack1R5(config)#do ping 141.1.123.1
>
> Type escape sequence to abort.
> Sending 5, 100-byte ICMP Echos to 141.1.123.1, timeout is 2 seconds:
> !!!!!
> Success rate is 100 percent (5/5), round-trip min/avg/max = 12/44/104 ms
> Rack1R5(config)#
>
>
> Thanks in advance.
>
>
> On Wed, Apr 9, 2008 at 9:00 PM, Cristi Grigore <cristi.grigore@gmail.com>
> wrote:
>
> > Hi Matt,
> >
> > are you sure you're not having problems with the tunnel due to recursive
> > routing?
> >
> > I replicated the problem and, from R5, I was able to ping a loopback on
> > R1 that was advertised through OSPF. Here are the configs (the link between
> > R1 and R2 is a serial link and R2 and R5 are connected through FR but that
> > should'n matter):
> >
> > R1:
> > !
> > interface Loopback1
> > ip address 10.1.1.1 255.255.255.0
> > ip ospf 1 area 0
> > !
> > interface Serial0/1/1
> > ip address 155.1.32.3 255.255.255.0
> > ip ospf 1 area 0
> > !
> > router ospf 1
> > log-adjacency-changes
> > !
> >
> > R2:
> > !
> > interface Tunnel0
> > ip address 25.0.0.2 255.255.255.0
> > ip ospf 1 area 0
> > keepalive 1 3
> > tunnel source 155.1.0.2
> > tunnel destination 155.1.0.5
> > !
> > interface Serial0/0/0
> > ip address 155.1.0.2 255.255.255.0
> > encapsulation frame-relay
> > ip ospf network point-to-multipoint
> > ip ospf 1 area 2
> > !
> > interface Serial0/0/1
> > ip address 155.1.32.2 255.255.255.0
> > ip ospf 1 area 0
> > !
> > router ospf 1
> > log-adjacency-changes
> > area 2 nssa
> > distribute-list prefix TUNNEL_DEST in Tunnel0
> > !
> > ip prefix-list TUNNEL_DEST seq 5 deny 155.1.0.5/32
> > ip prefix-list TUNNEL_DEST seq 10 permit 0.0.0.0/0 le 32
> > !
> >
> > R5:
> > !
> > interface Tunnel0
> > ip address 25.0.0.5 255.255.255.0
> > ip ospf 1 area 0
> > keepalive 1 3
> > tunnel source 155.1.0.5
> > tunnel destination 155.1.0.2
> > !
> > interface Serial0/0/0
> > ip address 155.1.0.5 255.255.255.0
> > encapsulation frame-relay
> > ip ospf network point-to-multipoint
> > ip ospf 1 area 2
> > !
> > router ospf 1
> > log-adjacency-changes
> > area 2 nssa
> > distribute-list prefix TUNNEL_DEST in Tunnel0
> > !
> > ip prefix-list TUNNEL_DEST seq 5 deny 155.1.0.2/32
> > ip prefix-list TUNNEL_DEST seq 10 permit 0.0.0.0/0 le 32
> > !
> >
> >
> > Now, the ping to R1's loopback 10.1.1.1 is working:
> > R5#sir
> > [..]
> > 155.1.0.0/16 is variably subnetted, 3 subnets, 2 masks
> > O 155.1.0.2/32 [110/64] via 155.1.0.2, 00:09:56, Serial0/0/0
> > C 155.1.0.0/24 is directly connected, Serial0/0/0
> > O 155.1.32.0/24 [110/11175] via 25.0.0.2, 00:09:56, Tunnel0
> > 25.0.0.0/24 is subnetted, 1 subnets
> > C 25.0.0.0 is directly connected, Tunnel0
> > 10.0.0.0/32 is subnetted, 1 subnets
> > O 10.1.1.1 [110/11176] via 25.0.0.2, 00:09:56, Tunnel0
> > R5#ping 10.1.1.1
> >
> > Type escape sequence to abort.
> > Sending 5, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds:
> > !!!!!
> > Success rate is 100 percent (5/5), round-trip min/avg/max = 68/69/72 ms
> > R5#
> >
> >
> > On Thu, Apr 10, 2008 at 1:38 AM, Matt Bentley <mattdbentley@gmail.com>
> > wrote:
> >
> > > Hi GS:
> > >
> > > I know this sounds pretty weird, but here's is what's going on.
> > >
> > >
> > > R1<--------------R2--------------------->R5
> > > (area 0) Fa0/0 (e0/0)
> > > <------------------------>
> > > NSSA Area
> > > GRE Tunnel
> > >
> > > I have an OSPF adjacency over both the GRE tunnel as well as over the
> > > physical interfaces on R2 and R5.
> > >
> > > Here is relevant config:
> > >
> > > R2:
> > > int tun0
> > > tunnel source fa0/0
> > > tunnel destination 141.1.0.5
> > > ip add 1.1.1.2 255.255.255.0
> > >
> > > router ospf 1
> > > network 141.1.0.2 0.0.0.0 area 2
> > > network 1.1.1.2 0.0.0.0 area 0
> > >
> > >
> > > R5:
> > > int tun0
> > > tunnel source e0/0
> > > tunnel destination 141.1.0.2
> > > ip add 1.1.1.5 255.255.255.0
> > >
> > > router ospf 1
> > > network 141.1.0.2 0.0.0.0 area 2
> > > network 1.1.1.5 0.0.0.0 area 0
> > >
> > > For some reason I don't know, the tunnel adjacency won't come up
> > > unless I
> > > have the tunnel sources be the directly connected interfaces. I CAN
> > > reach
> > > R2 from R5, but CAN'T reach R1 from R5, even though R5 has a route
> > > which
> > > appears to trace (based on the "show ip route" output) directly as it
> > > should
> > > go to get to R1. R1 can get to R5 (I know this because of debugging
> > > ICMP
> > > -which R5 receives, and subsequently sends a packet to R1, but it
> > > never gets
> > > there. As soon as I configure a static route on R5 - and it doesn't
> > > matter
> > > whether it is to the tunnel interface or to e0/0, then I can ping that
> > > prefix. The traffic must be getting blackholed someplace, but I
> > > really
> > > can't figure out where. Thanks in advance for everybody's help.
> > >
> > >
> > > Pass the CCIE in six weeks, Guaranteed!
> > > http://www.certscience.com/CCIE
> > >
> > > _______________________________________________________________________
> > > Subscription information may be found at:
> > > http://www.groupstudy.com/list/CCIELab.html
> > >
> > >
> > >
> > >
> >
> >
> > --
> > Thank you,
> > Cristi Grigore
>
>
>
-- Thank you, Cristi GrigorePass the CCIE in six weeks, Guaranteed! http://www.certscience.com/CCIE
This archive was generated by hypermail 2.1.4 : Thu May 01 2008 - 08:25:50 ART