Multicast not received properly via bridged Ethernet interface - bug?

[rculpan]

Using a small network (WAN) with three 1921 routers (IOS 15.1(T)) connected via E1 links. One host (industrial PC - core 2 due running Win XP Pro) connected to each router. The spare Gigabit Ethernet port on each router is bridged with the active one (so a portable management PC (laptop) can be plugged in there and communicate with the router and the industriual PC.

Multicast routing strategy between the routers is as per "Anycast - Static RP", with PIM sparse-mode enabled on all interfaces and sink RP

defined on all three routers.

Problem occurs when a (IPV4) multicast application on one PC communicates with the others:

(a) IGMP V2 membersip reports etc. work correctly at the sender and at the other two PCs receiving the multicast stream

(b) Multicast routing on the WAN is working correctly; running Wireshark on the receiving PCs shows that multicast data is received on the expected group.

(c) But, there is an error in the Ethernet packets

i. The first packet's Ethernet header contains the correct destination MAC address 01:00:5E:aa:bb:cc where aa:bb:cc match with the last three octets of the mulicast group's address, and that packet is received OK by the listening multicast application

ii. However, subsequent packets' Ethernet headers have the wrong MAC address 01:00:5E:00:00:00 (the last three octets are all zeroes and these packets are discarded by Windows on the receiving PC and not seen by the multicast application.

Problem is related to the presence of integrated routing & bridging; if I delete the bridge virtual interface,disable bridging and give the two Gigabit Ethernet ports their own IP addresses, the multicast reception works correctly; all received multicast packets have te expected value on the destination MAC address (matching the group address)

I have used the same integrated routing/bridging configuration successfully on Cisco 2611 and 2811 routers and there was no such issue with the multicast packets.

Have I overlooked some subtle aspect of configuration in the 1921 router or have I uncovered a bug...?

Regards,
Richard Culpan - Artevea Digital Ltd.

For reference - snippets from router configuration scripts

:

In the non-working configuration (with Integrated Routing & Bridging)

interface GigabitEthernet0/0

no ip address

duplex auto

speed auto

no cdp enable

bridge-group 1

no shutdown

exit

!

interface GigabitEthernet0/1

no ip address

duplex auto

speed auto

no cdp enable

bridge-group 1

no shutdown

exit

!

interface BVI1

description Bridge Group - GE0/0 & GE0/1

ip address 192.168.212.1 255.255.255.128

no ip directed-broadcast

ip pim sparse-mode

exit

bridge irb

bridge 1 protocol ieee

bridge 1 route ip

In the working configuration all the bridging is gone and the two Gigabit Ethernet interfaces have a very plain & simple configuration in different subnets

interface GigabitEthernet0/0

ip address 192.168.212.1 255.255.255.128

no ip directed-broadcast

ip pim sparse-mode

duplex auto

speed auto

no cdp enable

no shutdown

exit

!

interface GigabitEthernet0/1

ip address 192.168.250.1 255.255.255.0

no ip directed-broadcast

ip pim sparse-mode

duplex auto

speed auto

no cdp enable

no shutdown

exit

!

[Peter Paluch]

Hello Richard,

In my opinion, you have indeed discovered a bug. Do you perhaps have a support contract to report this issue? In general, mapping a multicast IP address into a multicast MAC address is something unconfigurable - there is a fixed procedure for that, and there is nothing to be configured about that.

You may want to make an experiment to have only a single GigabitEthernet interface assigned to the bridge-group 1, and seeing if the problem persists (i.e. whether the problem depends on the number of interfaces in the bridge-group) but most probably, this is not going to solve the issue.

I am sorry to not be able to be of more help in this case. The 15.x series of IOSes does have a number of new issues, this one may be yet another.

Best regards,

Peter

[rculpan]

Hi Peter,

Thanks for the reply. I tried with the second Gigabit Ethernet port disabled and also with it removed from the bridge group 1; no difference - the second and subsequent multicast packets still have the corrupt destination MAC address.

We don't have a support contract, however these are brand new routers and should still be within warranty, so I'll try sending a bug report by email and see what happens.

Regards,

Richard Culpan - Artevea Digital Ltd.

[paolo bevilacqua]

Unfortunately warranty only covers hardware, so you may want to get a support contract for Cisco to look at this.

[Giuseppe Larosa]

Hello Richard,

your findings point to a SW bug affecting multicast CEF switching. First packet may be processed differently in PIM sparse-mode (it should travel on shared tree).

to see if this is the case you can try to set to infinity the SPT traffic threshold

config t

ip pim spt-threshold infinity

however, this means never switching to Source based tree and more work for RP.

as stated by Paolo and Peter, you need a service contract to rise a TAC request.

I would go this way

Hope to help

Giuseppe

[rculpan]

Thanks for the replies,

Some good news:

1. I tried the suggestion of disabling switching to the source path tree ('ip pim spt-threshold infinity'); this actually made the problem worse - EVERY multicast packet received from the remote end was then broken with the corrupted destination MAC address!

2. But seeing you mentioned that the issue could be due to multicast CEF switching, I tried disabling CEF on just the BVI1 interface ('no ip cef').

Result: Problem solved - multicast packets all received without corruption of the destination MAC address

I will do some further tests to confirm that there are no unwanted side-effects...

3. I had a reply from Cisco TAC - they have opened a support case, so do appear to be interested in the bug...

So even if due to not having a support contract means that I would not be entitled to download any fixed firmware, at least it shows that Cisco TAC won't simply turn away a genuine bug report just because the sender doesn't have a support contract.

Regards,

Richard Culpan - Artevea Digital Ltd.

[paolo bevilacqua]

Good to that you found a workaround, and had the case opened. Actually the Cisco and the TAC has a name for standing behind their products, only that sometime the red tape gets in between.

[rculpan]

FYI - I found a tidier/better way to configure the router...

1. I found (the hard way) that the command 'no ip cef' is only applicable in global configuration mode; if entered in interface configuration mode the router sneakily dropped back to global configuration mode to apply it!

So, CEF was globally disabled (affecting all interfaces).

2. After some trawling through online command references I discovered that if I use 'ip mfib' commands in interface configuration mode I can control use of CEF on just the BVI1 interface.

i. In global configuration mode enable use of CEF ('ip cef')

ii. In interface configuration mode for BVI1, disable use of CEF for packets that are output on this interface ('no ip mfib cef output')

Result: CEF remains working on WAN interfaces with potential reduction of router CPU load when router is being used just for "transit" (no members of the multicast group listening there...)

But bug causing corruption of multicast packets' destination MAC address is bypassed.

Also, CEF is still seemingly active for unicast packets being forwarded to hosts on the bridged interfaces (with potential performance benefits...)

Regards,

Richard Culpan  - Artevea Digital Ltd.