From: Matt Bentley (mattdbentley@gmail.com)
Date: Thu Apr 10 2008 - 18:35:49 ART
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
Pass 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