Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

Multicast over a GRE tunnel

I setup a GRE tunnel between two cisco 3725 routers following

http://www.cisco.com/en/US/tech/tk828/technologies_configuration_example09186a00801a5aa2.shtml

They are both running IOS c3725-ipbase-mz.123-9e.bin. When I do a show ip int brief they both show up/down! So I seem to have a problem with the protocol! I cannot ping the tunnel address at the far end. I have checked both of the tunnel interfaces and they seem fine.

My IP cloud consists of some Nortel 7440 multiservice switches.

I have looked all over the cisco site trying to find some troubleshooting

information but, I don't see anything that applies.

Here is a copy of my configs:

///////////////////////////////////////////////////

MCast 1:

ip multicast-routing

frame-relay switching

no ftp-server write-enable

!

!

!

!

interface Loopback0

ip address 2.2.2.2 255.255.255.255

!

interface Tunnel0

ip address 192.168.0.1 255.255.255.0

ip pim sparse-dense-mode

tunnel source Loopback0

tunnel destination 4.4.4.4

!

interface FastEthernet0/0

ip address 10.120.255.1 255.255.255.0

ip pim sparse-dense-mode

speed 100

full-duplex

!

interface Serial0/1

ip address 10.120.254.1 255.255.255.0

encapsulation frame-relay IETF

ip ospf network point-to-point

no fair-queue

frame-relay interface-dlci 16

frame-relay lmi-type q933a

frame-relay intf-type dce

!

router ospf 1

log-adjacency-changes

network 2.2.2.2 0.0.0.0 area 0

network 10.120.0.0 0.0.255.255 area 0

network 192.168.0.0 0.0.0.255 area 0

!

ip classless

no ip http server

ip pim bidir-enable

////////////////////////////////////////////////////////

MCast 4:

no ip domain lookup

ip multicast-routing

frame-relay switching

no ftp-server write-enable

!

!

!

!

interface Loopback0

ip address 4.4.4.4 255.255.255.255

!

interface Tunnel0

ip address 192.168.0.2 255.255.255.0

ip pim sparse-dense-mode

tunnel source Loopback0

tunnel destination 2.2.2.2

!

interface FastEthernet0/0

ip address 10.120.244.1 255.255.255.0

ip pim sparse-dense-mode

duplex auto

speed auto

!

interface Serial0/1

ip address 10.120.245.1 255.255.255.0

encapsulation frame-relay IETF

ip ospf network point-to-point

frame-relay interface-dlci 16

frame-relay lmi-type q933a

frame-relay intf-type dce

!

router ospf 1

log-adjacency-changes

network 4.4.4.4 0.0.0.0 area 0

network 10.120.0.0 0.0.255.255 area 0

network 192.168.0.0 0.0.0.255 area 0

!

ip classless

no ip http server

ip pim bidir-enable

ip mroute 10.120.255.0 255.255.255.0 Tunnel0

!

///////////////////////////////////////////////////////////

Any help would be much appreciated. Thanks.

Mark

2 REPLIES
Cisco Employee

Re: Multicast over a GRE tunnel

Hi,

Did you confirm endpoint reachability? Use an extended ping with source 2.2.2.2 and dest 4.4.4.4 or vice versa.

If this does not work, troubleshoot your IP network.

If this works then shut/no shut the tunnel interfaces.

Please report the outcome for further help.

Regards, Martin

Hall of Fame Super Silver

Re: Multicast over a GRE tunnel

Andy

I believe that Martin has given you very good advice in suggesting extended ping to check reachability from 2.2.2.2 to 4.4.4.4. I suspect that you will find that the extended ping fails and reveals that the fundamental problem at this point is lack of reachability.

From my experience there are 2 things that will produce the symptom of GRE tunnel interfaces as up/down. One is that GRE keepalives are configured (and they are not in your config) or that the router does not have a valid route to the tunnel destination. You can confirm this with show ip route on either or both of the routers. I suspect that you will find that 2.2.2.2 is not in the routing table of the other router.

I also observe that I believe you will have an additional problem with recursive routing once you get the basic IP connectivity issue resolved. It is a frequent problem with GRE tunnels if you advertise the tunnel end point in the routing protocol running over the tunnel (and the network statements for 2.2.2.2 and 4.4.4.4 along with 192.168.0.0 under OSPF will do just that). Essentially what happens is that when the tunnel comes up and the routing protocol running over the tunnel advertises the tunnel end point (2.2.2.2 or 4.4.4.4) as reachable through the tunnel, then the router when it has an encapsulated GRE packet to transmit will attempt to transmit it over the tunnel rather than transmitting it out the physical interface. The easy solution to this issue is to configure a static route for the /32 host address pointing to the outbound physical interface.

HTH

Rick

852
Views
0
Helpful
2
Replies