From: marvin greenlee (marvin@ccbootcamp.com)
Date: Mon Aug 22 2005 - 13:41:57 GMT-3
The mismatch of network types is a factor here, but is not the major issue.
The mismatches are on the serial interfaces, not on the tunnel interfaces.
You can have the physical interfaces configured with different network
types, and it will not directly affect the tunnel interfaces. Since the
tunnel interfaces are using IP unnumbered, they will be included in the OSPF
process, and the adjacency will form over the tunnel. I labbed up a similar
scenario a while back, and the reason that your tunnel is down is because
the point-to-multipoint configuration adds a /32 host route for that side,
which takes down the tunnel due to recursive routing issues (tunnel endpoint
preferred path is through the tunnel). Turn on "debug ip routing" on R2 and
watch the output.
Marvin Greenlee, CCIE#12237, CCSI# 30483
Network Learning Inc
marvin@ccbootcamp.com
www.ccbootcamp.com (Cisco Training)
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Mitchell, TJ
Sent: Monday, August 22, 2005 9:08 AM
To: Ali.Huang; swm@emanon.com
Cc: ccielab@groupstudy.com
Subject: RE: GRE Tunnel always down [bcc][faked-from][bayes]
Importance: Low
Ali -
This is just an idea but you have an OSPF interface mis-match you
point-to-multipoint on one interface and ptp on the other. They need to
be the same otherwise they are going to bounce either that or fix the
timers.
Fix that and your tunnels should start working correctly.
Thanks
T.J. Mitchell
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Ali.Huang
Sent: Monday, August 22, 2005 9:40 AM
To: swm@emanon.com
Cc: ccielab@groupstudy.com
Subject: Re: GRE Tunnel always down
hi Scott,group,
The following configuration was my recall,
R2:
int t0
ip unnumber s0.24
tun source s0.24
tun dest 150.50.24.4
int s0
encap fram
no fram inv
interface s0.24 point-to-point
ip add 150.50.24.2 255.255.255.0
fram interface-dlci 204 protocol ip 150.50.24.4
router os 10
net 150.50.0.0 0.0.255.255 area 0
R4:
int t0
ip unn s0
tun so s0
tun de 150.50.24.2
int s0
encap fram
ip address 150.50.24.4 255.255.255.0
fram map ip 150.50.24.2 402 broadcast
ip os net point-to-multipoint
router os 10
net 150.50.24.4 0.0.0.0 area 0
net 10.1.1.4 0.0.0.0 area 1 //Ethernet 0
Symptoms:
The OSPF neighbors are unstable,I checked on R2,found the dead-time
was near to 30s,then disappear,then I checked the tunnel 0 down(line
protocol).
I checked R4,and found the neighbor was waiting our of dead-time,and
the tunnel 0 of R4 was always up.
If I issued the command ip ospf hello-interval 10 on R4' s0,I found
there were two neighbors with the same router-id on R2,one from tunnel
0 ,the other form s0.24.They works well.
I also tried on two ethernet,and I use ip ospf network to change
network type,one p2p,one p2m,but no change.I think it was not relate
with FR or Ethernet,only OSPF?
I didn't know why the virtual interface may be down?or it was affected
by OSPF protocol?
Thanks,regards
Ali.Huang
On 8/22/05, Scott Morris <swm@emanon.com> wrote:
> What's the rest of the config? (e.g. Frame Relay stuff, tunnel
destination,
> etc.)
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
Of
> Ali.Huang
> Sent: Monday, August 22, 2005 12:27 AM
> To: ccielab@groupstudy.com
> Subject: GRE Tunnel always down
>
> Hi,group,
> When I bulit a tunnel between subinterface and physical intterface and
both
> of them encapsulated with fram-relay,I found the line protocol of
tunnel0
> using subinterface always up and down.But the peer is always up.I
wonder if
> the tunnel interface couldn't work well on FR subinterface?
>
> R2#sh ip int t0
> Tunnel0 is up, line protocol is down
> Interface is unnumbered. Using address of Serial0.24 (150.50.24.2)
> Broadcast address is 255.255.255.255
> MTU is 1476 bytes
> --
> THX.
> Ali.huang
>
>
This archive was generated by hypermail 2.1.4 : Sun Sep 04 2005 - 17:01:19 GMT-3