Solved: Problems with Multicast routing on 2811

janhendrikbriese · ‎01-18-2013

Hello,

i tried to etablish multicast routing using pim and gre between two 2811 (IP-Base) Router.

Routing/forwarding from rtA to rtB works without any problems, but forwarding multicast from rtB to rtA isn't running!

In my opinion the configuration looks good. Pls find attached Files.

Thanks

Jan

Edison Ortiz · ‎01-18-2013

Rick,

He is using sparse-dense mode.

View solution in original post

Edison Ortiz · ‎01-23-2013

Valid UDP ports are up to 65535 so I don't think that's the problem.

Did you verify the TTL value? If TTL = 1, packets won't be forwarded.

As suspected, the issue is application and not the router configuration.

View solution in original post

Edison Ortiz · ‎01-18-2013

How are you testing multicast?

Please provide the following outputs;

'show ip mroute'

'show ip pim neighbors'

'show ip pim interfaces'

You don't need the mroute commands are your unicast is flowing via the tunnel.

Richard Burts · ‎01-18-2013

Jan

I notice that there is no RP configured for PIM sparse mode. Other than that I do not see issues in the configuration.

Perhaps you can tell us a bit about how you are testing this? Do you have something sourcing multicast traffic? What are the results of your testing?

HTH

Rick

HTH

Rick

Edison Ortiz · ‎01-18-2013

Rick,

He is using sparse-dense mode.

Richard Burts · ‎01-18-2013

Edison

Yes he is attempting to run sparse-dense mode. And without an RP he is effectively entirely in dense mode. See this white paper for discussion about the effect of lack of RP in sparse-dense mode

http://www.cisco.com/en/US/docs/ios/solutions_docs/ip_multicast/White_papers/rps.html

I am not suggesting that lack of RP would cause a failure of multicast traffic to be forwarded, since dense mode should still work. But part of Jan's question was whether there were issues in his configuration. And I believe that a configuration of sparse-dense that does not provide for RP is a deficient configuration.

HTH

Rick

HTH

Rick

janhendrikbriese · ‎01-20-2013

First at all thank you for your quick response.

I will provide you the mroute and pim reports as soon as possible. On Friday I figured out some serious phenomena. I need the mc forwarding for a client-server architecture where the communication between client and server will be done via mc. When the Server is registering the mc group at one router (I tried both sides), the router will start forwarding and you will find the correct mroute entries on both routers (Server + * = source). The Clients on the other hand (connected to the other router) will start registration and transmitting in the same mc group, but nothing will be forwarded! I double checked with Wireshark and the registration and packages look nearly the same. The only difference is that the Server is binary compiled and the Clients are Java. Are there known problems with the Java TCP-Stack?

Thank You

Jan

Richard Burts · ‎01-21-2013

Jan

Thanks for the additional information. I am slightly confused about the client/server relationship using multicast. It makes sense that the server might send to a multicast address so that it could communicate with multiple clients. Are you telling us that the clients are also sending to a multicast address? And is it the same multicast address as the one used by the server?

HTH

Rick

HTH

Rick

paul driver · ‎01-21-2013

Hello Jan - Richard

Possible you may have RPF failure which could be traced by the commands below

could you post if applicable from each router:

sh ip route (mc client)
sh ip rpf ( mc client)
sh ip pim interface count

res

Paul

Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

janhendrikbriese · ‎01-22-2013

Hello Rick, Paul,

in my configuration both, the Server and the clients are MC-Server AND MC-Client. The Server is sending his status and other Information via MC (in this case group 224.64.1.1) witch are received by the clients and the clients are sending configuration commands in the same group witch are received by the server.

I can't find any indication for RPF-Failures.

This is my Hardware configuration:

Server (10.10.1.2/24) <-> rtA <- Transit LAN with GRE -> rtB <-> Client (192.168.2.2/24)

Attached you will find Text-Files with the actual configuration and some show commands inside.

Thank You

Jan

g.agarwal1612 · ‎01-22-2013

Hi Jan ,

You have wrong mroutes on router A and B, they should be other way around what you have right now.

configure the following

hostname rtA

ip mroute 192.168.2.0 255.255.255.0 Tunnel0

hostname rtB

ip mroute 10.10.1.0 255.255.255.0 Tunnel0

if this doesnt work , please send the output of

sh ip rpf 10.10.10.2 ( on rtB)

sh ip rpf 192.168.2.2( on rTA)

sh ip igmp groups

janhendrikbriese · ‎01-22-2013

Hi,

I changed the mroute settings and now the sh ip rpf looks good in my meaning (see attached file) but nothing changed.

Still only getting the MC from the Server System! Why rtB receives the MC from the Client System (sh ip igmp) and doesn't start forwarding this?

When you look in the sh ip mroute count from rtA (Post before) you will see 10.10.1.2 as source for 224.64.1.1. Looking in the mroute count on rtB You will find 10.10.1.2 as well but nothing for 192.168.2.2. Why? I looked to the network wit Wireshark and there is a normal registration for 192.168.2.2 and there is MC traffing comming from this IP, but nothing will be forwarded!

Thank You

Jan

Edison Ortiz · ‎01-22-2013

Jan,

Your mroute details look perfect on the server side and the client, perhaps the application needs to be looked at?

From the router attached to the source, incoming F0/0 - outgoing to the tunnel.

(10.10.1.2, 224.64.1.1), 00:03:32/00:02:58, flags: LT

Incoming interface: FastEthernet0/0, RPF nbr 0.0.0.0

Outgoing interface list:

Tunnel0, Forward/Sparse-Dense, 00:03:33/00:00:00

Mroute count is showing correct values:

Group: 224.64.1.1, Source count: 1, Packets forwarded: 3144, Packets received: 3144

Source: 10.10.1.2/32, Forwarding: 3144/4/214/7, Other: 3144/0/0

On the receiver side

(*, 224.64.1.1), 00:22:52/stopped, RP 0.0.0.0, flags: DCL

Incoming interface: Null, RPF nbr 0.0.0.0

Outgoing interface list:

FastEthernet0/0, Forward/Sparse-Dense, 00:22:52/00:00:00

Tunnel0, Forward/Sparse-Dense, 00:22:52/00:00:00

(10.10.1.2, 224.64.1.1), 00:10:48/00:02:58, flags: LT

Incoming interface: Tunnel0, RPF nbr 192.168.1.2

Outgoing interface list:

FastEthernet0/0, Forward/Sparse-Dense, 00:10:49/00:00:00

mroute count:

Group: 224.64.1.1, Source count: 1, Packets forwarded: 3103, Packets received: 3103

Source: 10.10.1.2/32, Forwarding: 3103/6/214/9, Other: 3103/0/0

How are you testing multicast? Video, audio streams or simple pings?

BTW, if the client is 192.168.2.2 - you won't see this IP in the mroute table as clients simply join the group.

They don't send to a multicast address, they listen.

paul driver · ‎01-22-2013

Hello,

1) bidirectional pim is enabled but there is no specified RP mapping - which is required for pim-bidir as you have 224.64.1.1 forwarding in two directions

ip pim rp- address x.x.x.x bidir ( have to make sure this ip is routable - A loopback would be good)

2)The mroute statements are not required as you have a routable path

3)Apply sparse-mode or sparse-dense-mode to interfaces fa0/1 as at present these are not pim neigbours.

Both routers:
sh ip mroute bidirectional
sh ip pim interface fa0/1

sh ip pim interface fa0/1 df

res

Paul

.

Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

janhendrikbriese · ‎01-23-2013

Edison,

I'am using a special Software in wich the "Server" and "Clients" are communicating via Multicast (in this case 224.64.1.19).
The Server stores a Backend Database and has some live analysis functions. Data from the Database and the analysis are send continuously by the Server. The Clients sending a "Heartbeat" (Hello Server I'am Console XY) and Database-changes. This communictaion is done via Multicast. Normaly the Software-Suit is used in a LAN, it's the first Time using it with deployed Clients.

Paul,

I configured the tun 0 ip from rtA as Bdir RP on both routers. Now I have a little difference in sh ip mroute (bidir), but no changes concerning the traffic.

This is my actual configuration and some sh commands:

rtA#sh run
Building configuration...

Current configuration : 1035 bytes
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname rtA
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
!
resource policy
!
ip subnet-zero
!
!
ip cef
!
ip multicast-routing
!
!
!
!
interface Tunnel0
ip address 192.168.1.2 255.255.255.252
ip pim sparse-dense-mode
tunnel source FastEthernet0/1
tunnel destination 192.168.0.2
!
interface FastEthernet0/0
ip address 10.10.1.1 255.255.255.0
ip pim sparse-dense-mode
ip igmp join-group 224.64.1.1
duplex auto
speed auto
!
interface FastEthernet0/1
ip address 192.168.0.1 255.255.255.252
duplex auto
speed auto
!
interface Serial0/0/0
no ip address
shutdown
clock rate 2000000
!
interface Serial0/0/1
no ip address
shutdown
clock rate 2000000
!
ip classless
ip route 192.168.2.0 255.255.255.0 Tunnel0
!
no ip http server
ip pim bidir-enable
ip pim rp-address 192.168.1.2 bidir
!
!
control-plane
!
!
line con 0
line vty 0 4
login
!
scheduler allocate 20000 1000
!
end

rtA#sh ip mroute bidir
(*, 224.64.1.1), 00:37:10/00:02:59, RP 192.168.1.2, flags: BCL
Bidir-Upstream: Null, RPF nbr 0.0.0.0
Outgoing interface list:
    FastEthernet0/0, Forward/Sparse-Dense, 00:04:28/00:02:46
    Tunnel0, Forward/Sparse-Dense, 00:36:50/00:02:45

(*, 224.64.1.2), 00:35:11/00:02:45, RP 192.168.1.2, flags: B
Bidir-Upstream: Null, RPF nbr 0.0.0.0
Outgoing interface list:
    Tunnel0, Forward/Sparse-Dense, 00:04:24/00:02:45

(*, 224.0.1.40), 00:37:09/00:00:48, RP 192.168.1.2, flags: BCL
Bidir-Upstream: Null, RPF nbr 0.0.0.0
Outgoing interface list:
    Tunnel0, Forward/Sparse-Dense, 00:36:49/00:00:48

(*, 229.44.91.73), 00:35:10/00:02:44, RP 192.168.1.2, flags: B
Bidir-Upstream: Null, RPF nbr 0.0.0.0
Outgoing interface list:
    Tunnel0, Forward/Sparse-Dense, 00:04:24/00:02:44

(*, 239.255.255.250), 00:36:44/00:03:10, RP 192.168.1.2, flags: B
Bidir-Upstream: Null, RPF nbr 0.0.0.0
Outgoing interface list:
    Tunnel0, Forward/Sparse-Dense, 00:04:26/00:03:09

rtA#sh ip pim int tun 0

Address          Interface                Ver/ Nbr    Query DR    DR
                                          Mode Count Intvl Prior
192.168.1.2      Tunnel0                  v2/SD 1      30    1      0.0.0.0
rtA#sh ip pim int tun 0 df

Interface                RP              DF Winner        Metric    Uptime
Tunnel0                  192.168.1.2      192.168.1.2      0          00:37:14

rtA#sh ip pim rp
Group: 224.64.1.1, RP: 192.168.1.2, next RP-reachable in 00:01:24
Group: 224.64.1.2, RP: 192.168.1.2, next RP-reachable in 00:00:23
Group: 224.0.1.40, RP: 192.168.1.2, next RP-reachable in 00:01:25
Group: 229.44.91.73, RP: 192.168.1.2, next RP-reachable in 00:00:24
Group: 239.255.255.250, RP: 192.168.1.2, next RP-reachable in 00:00:20
rtA#

rtB#sh run
Building configuration...

Current configuration : 1035 bytes
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname rtB
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
!
resource policy
!
ip subnet-zero
!
!
ip cef
!
ip multicast-routing
!
!
!
!
interface Tunnel0
ip address 192.168.1.1 255.255.255.252
ip pim sparse-dense-mode
tunnel source FastEthernet0/1
tunnel destination 192.168.0.1
!
interface FastEthernet0/0
ip address 192.168.2.1 255.255.255.0
ip pim sparse-dense-mode
ip igmp join-group 224.64.1.1
duplex auto
speed auto
!
interface FastEthernet0/1
ip address 192.168.0.2 255.255.255.252
duplex auto
speed auto
!
interface Serial0/0/0
no ip address
shutdown
clock rate 2000000
!
interface Serial0/0/1
no ip address
shutdown
clock rate 2000000
!
ip classless
ip route 10.10.1.0 255.255.255.0 Tunnel0
!
no ip http server
ip pim bidir-enable
ip pim rp-address 192.168.1.2 bidir
!
!
control-plane
!
!
line con 0
line vty 0 4
login
!
scheduler allocate 20000 1000
!
end

rtB#sh ip mroute bidir
(*, 224.64.1.1), 00:37:55/00:02:59, RP 192.168.1.2, flags: BCL
Bidir-Upstream: Tunnel0, RPF nbr 192.168.1.2
Outgoing interface list:
    FastEthernet0/0, Forward/Sparse-Dense, 00:05:09/00:02:59
    Tunnel0, Bidir-Upstream/Sparse-Dense, 00:37:44/00:00:00

(*, 224.64.1.2), 00:35:55/00:02:02, RP 192.168.1.2, flags: BC
Bidir-Upstream: Tunnel0, RPF nbr 192.168.1.2
Outgoing interface list:
    FastEthernet0/0, Forward/Sparse-Dense, 00:05:09/00:02:02
    Tunnel0, Bidir-Upstream/Sparse-Dense, 00:35:55/00:00:00

(*, 229.44.91.73), 00:35:55/00:02:04, RP 192.168.1.2, flags: BC
Bidir-Upstream: Tunnel0, RPF nbr 192.168.1.2
Outgoing interface list:
    FastEthernet0/0, Forward/Sparse-Dense, 00:05:09/00:02:04
    Tunnel0, Bidir-Upstream/Sparse-Dense, 00:35:55/00:00:00

(*, 239.255.255.250), 00:37:29/00:02:03, RP 192.168.1.2, flags: BC
Bidir-Upstream: Tunnel0, RPF nbr 192.168.1.2
Outgoing interface list:
    FastEthernet0/0, Forward/Sparse-Dense, 00:05:09/00:02:03
    Tunnel0, Bidir-Upstream/Sparse-Dense, 00:37:29/00:00:00

rtB#sh ip pim int tun 0

Address          Interface                Ver/ Nbr    Query DR    DR
                                          Mode Count Intvl Prior
192.168.1.1      Tunnel0                  v2/SD 1      30    1      0.0.0.0

rtB#sh ip pim int tun 0 df

Interface                RP              DF Winner        Metric    Uptime
Tunnel0                  192.168.1.2      192.168.1.2      0          00:37:57

rtB#sh ip pim rp
Group: 224.64.1.1, RP: 192.168.1.2, uptime 00:38:20, expires never
Group: 224.64.1.2, RP: 192.168.1.2, uptime 00:36:21, expires never
Group: 229.44.91.73, RP: 192.168.1.2, uptime 00:36:20, expires never
Group: 239.255.255.250, RP: 192.168.1.2, uptime 00:37:54, expires never
rtB#

Thanks

Jan

janhendrikbriese · ‎01-23-2013

Hi,

maybe I have found the issue why the routers wouldn't forward the packages. I foud a MCtransmit and receive toll from a universety. with this tool the current configuration works perfect!

That's the situation:

Server - works

Testtool - works in both directions simultaneously

Client - NO

The only difference I found by analysing the UDP Packages was the source Port. The forwarded MC-Packages (Server and Testtool) were send with a sourceport between 1050 and 1150. The packages wich are not forwarded were send with a port > 65000!

Do you know a way to let the routers route packages with this ports?

Thanks

Jan