224.0.0.0/24 & Multicast flooding

[chintan-shah]

Hi Guys,

Most of Cisco document says below about 224.0.0.0/24 :

"In general, addresses from 224.0.0.1 to 224.0.0.255 are reserved and used by various protocols (standard or proprietary, such as Hot Standby Router Protocol (HSRP)). Cisco recommends that you not use these for GDA in a multicast network. CGMP and IGMP snooping do not work with this reserved address range.”

But What I am not sure is , it is true that packet with Multicast destined from 224.0.0.0/24 range will be flooded to all ports , irrespective of that packet is tagged with what VLAN ? I mean if packet arrived on switch port with VLAN tag 200, will I see same packet flooded on port where VLAN 200 is not allowed at all ? Can some one please clarify this with more details ?

-C

[Peter Paluch]

Hi,

it is true that packet with Multicast destined from 224.0.0.0/24 range will be flooded to all ports , irrespective of that packet is tagged with what VLAN?

No, that is not true. A packet with the destination somewhere in the 224.0.0.0/24 range would be flooded within its own VLAN only. Under no circumstances can a frame in one VLAN leak into another VLAN without routing. It is irrelevant whether the packet is a unicast, multicast or broadcast frame. If a packet is received in VLAN 200, it can be flooded only over ports that are members of VLAN 200.

Best regards,
Peter

[chintan-shah]

Thanks Peter. In this case, I see wrong behavior on Cisco Nexus where i clearly see that packets destined to  224.0.0.x with VLAN tag 200 are being flooded to port where VLAN 200 is not allowed at all. Have you seen such behavior in any of other cisco switch ? I've feeling that it is even true on 6500. 

-C

[Peter Paluch]

Hi,

This must be some kind of error. You see, if packets to 224.0.0.x were flooded across VLANs, we would be, for example, getting all sorts of "neighbor not on the common subnet" errors produced by routing protocols - think of OSPF or EIGRP Hello packets destined to 224.0.0.5 or 224.0.0.10 flooded across all VLANs. Clearly, this is an unthinkable scenario.

I think we should be asking three questions here:

1. Is the port in question a FabricPath port? FabricPath does not have a concept of VLANs and the multicast frames are replicated along a specific tree. Is it possible you are observing this behavior?
2. If the port is a normal port, can you post its configuration here? In particular, I would like to see how the VLAN 200 is disallowed on that port.
3. Is it certain that the frames you are observing on the port have truly been originated in VLAN 200? Is it possible instead that they have been originated in a different VLAN that happens to be allowed on that port, and are just - by some coincidence - similar to frames already seen in VLAN 200?

Definitely, I need to understand more about the phenomenon you have observed. Perhaps even describing what kind of traffic is that, how you determined that the traffic is flooded inappropriately, etc. - all these details help me tremendously to understand your situation.

Thanks!

Best regards,
Peter

[chintan-shah]

Hi,

Answers to your questions are :

#1 - Not it is Ethernet port connected to firewall.

#2 - 

Monitor session on Nexus switch.

show run monitor

!Command: show running-config monitor
!Time: Sat Jan  3 19:48:18 2015

version 5.0(3)U5(1g)
monitor session 1
  source interface Ethernet1/44 both
  destination interface Ethernet1/46
  no shut

Eth1/44 port configuration on which I see Multicast packet ( with vlan 200).

show run int eth1/44

!Command: show running-config interface Ethernet1/44
!Time: Sat Jan  3 19:48:24 2015

version 5.0(3)U5(1g)

interface Ethernet1/44
  no cdp enable
  switchport mode trunk
  switchport trunk allowed vlan 50
  spanning-tree port type edge trunk
  spanning-tree bpduguard enable

Port configuration where sniffer is connected.

show run int eth1/46

!Command: show running-config interface Ethernet1/46
!Time: Sat Jan  3 19:48:29 2015

version 5.0(3)U5(1g)

interface Ethernet1/46
  switchport monitor

#3 - Initially I also thought the same that packet might not be tagged with VLAN 200 but then when i ran tcp dump with -e option on sniffer on which i capture packet being transmitted on eth1/44. I see vlan information and in fact i see OSPF packet as well.

12:01:22.175576 a0:36:9f:1c:21:a8 > 01:00:5e:00:00:51, ethertype 802.1Q (0x8100), length 1458: vlan 200, p 0, ethertype IPv4, 172.17.215.31.40353 > 224.0.0.81.8848: UDP, length 1412

12:02:37.874387 88:5a:92:36:45:81 > 01:00:5e:00:00:05, ethertype 802.1Q (0x8100), length 86: vlan 100, p 0, ethertype IPv4, 172.17.216.3 > 224.0.0.5: OSPFv2, Hello, length 48

The multicast traffic on 224.0.0.81 is coming on port (trunk port with vlan 200 allowed) connected to other switch on which end host is connected. It is used for sync between two end host for specific application being run on them.

Let me know if you need more information and thanks for help.

-C

[Peter Paluch]

Hi,

Thanks for the added info. You see, the E1/44 is a trunk port. While it is configured only with VLAN 50 in its list of allowed VLANs, it appears that the device on the other end of the trunk does not use the same list of allowed VLANs, and allows, among others, VLANs 100 and 200. As a result, frames in these VLANs arrive at your E1/44 port. They would be dropped and not forwarded by the switch, but because you are also doing a monitor session on this port, a copy of these to-be-dropped frames is sent to the sniffer.

Can you verify the configuration of the device attached to E1/44 if it truly is allowing VLANs 100 and 200?

Best regards,
Peter

[chintan-shah]

Actually Multicast packets are being send to device (firewall) connected to eth1/44 and not the case where it coming from device (firewall) connected eth1/44.

To avoid doubt, i modified monitor session with source interface as eth1/44 Tx and i still see Multicast packets on my tcp dump with vlan 200.

monitor session 1
  source interface Ethernet1/44 tx
  destination interface Ethernet1/46
  no shut

20:15:29.928459 a0:36:9f:1c:21:a8 > 01:00:5e:00:00:51, ethertype 802.1Q (0x8100), length 1458: vlan 200, p 0, ethertype IPv4, 172.17.215.31.40353 > 224.0.0.81.8848: UDP, length 1412

-C

[Peter Paluch]

Chintan,

This is very strange. It is as if the configuration of the port was not properly pushed down to the hardware of the port.

I am not sure if you can do configuration changes to the port that will cause a connectivity disruption, but if you can make a couple of experiments, would you be willing to test these three suggestions for me? My intention is to cause a sequence of events that should cause the NX-OS to newly program the ASIC on the port.

1. Remove the switchport trunk allowed vlan 50 command from the E1/44 port, thereby allowing all VLANs, and after a minute or so, put it back.
2. If it does not help, shut the port down, wait a couple of seconds, and activate it again.
3. If it still does not help, put the E1/44 into the default configuration (the default int e1/44 should do the trick but if NX-OS does not support this command then simply remove all commands from the interface) and then re-configure it back.

If none of these steps helps then I am thoroughly confused, and I would personally contact TAC with a request for explanation.

Best regards,
Peter

[chintan-shah]

Peter,

I think we have already done the steps you mentioned but i will check on this and update you further since now on VLAN 50 we have our production traffic so can not touch at the moment .

Thanks for help so far, will update you on outcome.

-C

[chintan-shah · Accepted solution]

Peter,

After further investigation with Cisco, this is what is happening :

- We see packet from VLAN 200 is being flooded to port on VLAN 50 when we SPAN port allowed with VLAN 50.

- But in reality, packet is not being send on wire, it's because of the way SPAN is implemented in Nexus 3K.

Here is the reason

SPAN replication engine make a copy of the packet before CBL/STP state. CBL(Color Blocking Logic) is the hardware implementation of spanning-tree. But if you do a capture in the host you won't see this packets being sent out in the wire.

So we are good :)

-C

[Peter Paluch]

Hi Chintan,

Thank you very much for updating this thread with this insider information! Rated and endorsed as deserved. I am sure it will help other users of Nexus 3K if they stumble across the same behavior.

Thanks once again!

Best regards,
Peter