cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2036
Views
15
Helpful
13
Replies

unregistered multicast on ME3400E

fips
Level 1
Level 1

Hi, 

I have a use case where 2 host send multicast packets to each other for HA purposes.

They don't create a multicast group via IGMP they just send as unregistered members.

 

If I use a SG300 Switch there is an option under Multicast -> Unregistered Multicast -> there you can define for each port "filtering or forwarding", default is forwarding.

everything works fine.

 

But if I change the SG300 to an ME3400E access switch that unregistered multicast settings doesn't exist. 

So the multicast packets can't be forwarded. 

 

Can I achieve this behaviour with different options?

1 Accepted Solution

Accepted Solutions

Hello Fips,

Thanks for the outputs. The STP state looks strange, as I was expecting some sort of STP info available for VLAN 1. More on this down below.

The source MAC looks okay, it's VRRP virtual mac for group 1, I believe. The destination mac looks good too, it translates to 224.0.0.18.

I don't believe changing the source mac would help anything as the this particular source mac scheme is ingrained into how VRRP works.

So, anways...looking at the STP info got me digging into some config guides. Can we check the port-states for G0/1 and G0/2? I found that per config guide UNI port types don't run STP instances.

I checked on the ME-3400 models and I believe you may be using a ME-3400G-2CS-A based on the config that was posted.

Can you check output of "show port-type". If G0/1 and G0/2 are UNI type ports, then it might cause a problem like you're describing. Per config guide, traffic entering UNI ports can only exit NNI ports (Reference). I checked on a ME-3400G-2CS-A in my lab and found that G0/1 and G0/2 are UNI ports by default.

Can you check their port status? If G0/1 and G0/2 are UNI ports currently, can you change them to NNI ports and check again?

 

If  this would create a security risk, then it looks like allowing communication between UNI's is possible by modifying VLAN config (Reference).

 

Can you check if the above is causing the issue and if one of these options resolves the issue?

View solution in original post

13 Replies 13

Matt Delony
Cisco Employee
Cisco Employee

Hello fips,

 

Me-3400 has IGMP snooping enabled by default. It's likely that the switch is dropping the traffic because it doesn't know where to send the multicast traffic.

 

If the 2 hosts don't join their respective multicast group, then there are a couple things you can do to force the ME-3400 to forward the traffic.

 

  • Configure static joins on the ME-3400 (reference).
    • Add the physical interfaces connected to the 2 hosts, as well as the multicast group address, so that the switch will know where to send the multicast traffic for the group that the hosts are using.
    • Validate with "show ip igmp snooping groups".

 

  • Disable IGMP snooping globally or per vlan (reference).
    • This is not an ideal solution. This will cause all multicast traffic to be treated as a broadcast and will be flooded by the switch in all ports within a broadcast domain. If you disable for specific VLAN, then only multicast traffic for that VLAN will be affected. If you disable globally, then it will be all multicast traffic affected.

Matt Delony
Cisco Employee
Cisco Employee

Hello fips,

 

Me-3400 has IGMP snooping enabled by default. It's likely that the switch is dropping the traffic because it doesn't know where to send the multicast traffic.

 

If the 2 hosts don't join their respective multicast group, then there are a couple things you can do to force the ME-3400 to forward the traffic.

 

  • Configure static joins on the ME-3400 (reference).
    • Add the physical interfaces connected to the 2 hosts, as well as the multicast group address, so that the switch will know where to send the multicast traffic for the group that the hosts are using.
    • Validate with "show ip igmp snooping groups".

 

  • Disable IGMP snooping globally or per vlan (reference).
    • This is not an ideal solution. This will cause all multicast traffic to be treated as a broadcast and will be flooded by the switch in all ports within a broadcast domain. If you disable for specific VLAN, then only multicast traffic for that VLAN will be affected. If you disable globally, then it will be all multicast traffic affected.

Hi Matt, 

 

thanks for your reply.

 

Because multicast addresses are local-subnetwork (224.0.0.18) the ME3400E access switch doesn't allow me to add a static join: 

Switch(config)#ip igmp snooping vlan 1 static 224.0.0.18 interface gi0/1 
Illegal multicast group address

Even if I disable IGMP snooping, multicast packets are not forwarded.

Is it possible that ME3400E access switch by default can not forward local-subnetwork multicasts?

Is it too smart?

 

Because as I said, if I change the ME3400E to SG300, the packets are forwarded, and both hosts work as expected.

Even if I take just a stupid L2 switch connected to the ME3400E it works.

 

 

Hello Fips,

224.0.0.18 is a reserved group, for VRRP. So when the ME-3400 receives this traffic, it should be flooded in the broadcast domain associated with the ingress port.

On the ME-3400 are the ports connecting to the hosts in the same broadcast domain?

Yes, I want to use CARP, a VRRP clone.

Both hosts run firewalls and they are directly connected to gi0/1 and gi0/2 of ME3400E.

gi0/3 is not in use and gi0/4 is a routed upstream port.

gi0/1 and gi0/2 are in the same VLAN1.

 

 

would it be possible to post a sanitized config from the ME-3400?

It's a bit tricky to tell if the ME-3400 is actually forwarding the traffic or not with basic L2 config. You can check "show interface x/y counter" output and see if in/out multicast category is incrementing. Also, a SPAN could be used to check input/output details for the multicast traffic.

sure here is the config:

Switch(config)#do sh run
Building configuration...

Current configuration : 2689 bytes
!
version 12.2
no service pad
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Switch
!
boot-start-marker
boot-end-marker
!
no logging console
!
no aaa new-model
system mtu routing 1546
ip routing
no ip domain-lookup
!
!
!
crypto pki trustpoint TP-self-signed-1935808256
 enrollment selfsigned
 subject-name cn=IOS-Self-Signed-Certificate-1935808256
 revocation-check none
 rsakeypair TP-self-signed-1935808256
!
!
crypto pki certificate chain TP-self-signed-1935808256
 certificate self-signed 01
  3082023F 308201A8 A0030201 02020101 300D0609 2A864886 F70D0101 04050030 
  5A4D5645 C3F60E00 1D6BC632 9337D7CF 03AF2784 DD8B9A82 09F3759C 35D494C0 
  0A17DA3E 699DC51E 5AB9F672 5F358BA0 8B000741 A4A9F662 2547097C 0F0F3199 B1D436
  quit
!
!
!
!
spanning-tree mode rapid-pvst
spanning-tree extend system-id
!
!
vlan internal allocation policy ascending
!
!
!
interface FastEthernet0
 no ip address
 no ip route-cache cef
 no ip route-cache
 no ip mroute-cache
!
interface GigabitEthernet0/1
 load-interval 30
 media-type rj45
!
interface GigabitEthernet0/2
 load-interval 30
 media-type rj45
!
interface GigabitEthernet0/3
 port-type nni
!
interface GigabitEthernet0/4
 port-type nni
 no switchport
 ip address 9X.XXX.X72.14 255.255.255.252
!
interface Vlan1
 ip address 8X.XXX.X7.17 255.255.255.248
!
interface Vlan10
 no ip address
!
no ip http server
ip http secure-server
ip classless
!
!
ip sla enable reaction-alerts
no cdp run
!
!
line con 0
line vty 0 4
 login
line vty 5 15
 login
!
end

if I check with "show interface gi0/2 counter" InMcastPkts is incrementing (OutMcastPkts = 0).

But as I understood VRRP and CARP, multicast packets from host1 has to arrive host2, so the counter should not increment furthermore the counter for OutMcastPkts should increment.

 

 

 

Hello Fips,

Thanks for the config. I'm not seeing anything that would contribute to the problem from a config perspective.

With VRRP, both hosts will send multicast traffic until they establish who is active/standby. Once this is established, then it's 1 way communication from active to standby. If the standby stops seeing the keepalives, then it switches to active.

If I were troubleshooting live, I would check that both G0/1 and G0/2 are in STP DSG forwarding state. I wouldn't expect one of the ports to go to blocking state going to those hosts. I'd also be curious to see the destination mac address of the multicast traffic. I would expect it to be 0100.5E00.0012 for VRRP.

There are commands to check deeper on the ME-3400 in regards to forwarding decisions, but it would be cumbersome to do so on a forum as later commands have inputs dependent on previous commands. Any possibility that ME-3400 has a support contract and ticket with TAC can be opened on it?

About spanning-tree:

Switch#show spanning-tree interface gi0/1
no spanning tree info available for GigabitEthernet0/1
Switch#show spanning-tree interface gi0/2
no spanning tree info available for GigabitEthernet0/2 

 

Wireshark output of an announcement:

Source MAC: 00:00:5e:00:01:01

Destination MAC: 01:00:5e:00:00:12

 

The problem in general: I have this problem with the ME3400E from ISP, in my production environment.

Because they don't want to help me (they always say I have to change the source MAC...), I bought a ME3400E on ebay to build up an testing situation.

 

My ISPs comment is:

"According to IPv4 multicast standards, the MAC destination multicast address begins with 0100:5e and is appended by the last 23 bits of the IP address. On the Cisco ME switch, if the multicast packet does not match the switch multicast address, the packets are treated in this way:

* If the packet has a multicast IP address and a unicast MAC address, the packet is forwarded in software. This can occur because some protocols on legacy devices use unicast MAC addresses with multicast IP addresses. 

* If the packet has a multicast IP address and an unmatched multicast MAC address, the packet is dropped"

I just can't believe that a basic switch like SG300 can handle it, and enterprise one not.

I am absolutely sure, I haven't found the right option.

Which sense it would make otherwise?

Hello Fips,

Thanks for the outputs. The STP state looks strange, as I was expecting some sort of STP info available for VLAN 1. More on this down below.

The source MAC looks okay, it's VRRP virtual mac for group 1, I believe. The destination mac looks good too, it translates to 224.0.0.18.

I don't believe changing the source mac would help anything as the this particular source mac scheme is ingrained into how VRRP works.

So, anways...looking at the STP info got me digging into some config guides. Can we check the port-states for G0/1 and G0/2? I found that per config guide UNI port types don't run STP instances.

I checked on the ME-3400 models and I believe you may be using a ME-3400G-2CS-A based on the config that was posted.

Can you check output of "show port-type". If G0/1 and G0/2 are UNI type ports, then it might cause a problem like you're describing. Per config guide, traffic entering UNI ports can only exit NNI ports (Reference). I checked on a ME-3400G-2CS-A in my lab and found that G0/1 and G0/2 are UNI ports by default.

Can you check their port status? If G0/1 and G0/2 are UNI ports currently, can you change them to NNI ports and check again?

 

If  this would create a security risk, then it looks like allowing communication between UNI's is possible by modifying VLAN config (Reference).

 

Can you check if the above is causing the issue and if one of these options resolves the issue?

wow...11 days of looking and trying and changing and searching....
and yes change the port-type from UNI to NNI did the trick!
At leat it worked on my test environment.
Now I have to convince my ISP to change that on his ME3400E too.

Thanks man!
Thank you very very much and greetings from austria!!!

Woohoo! I'm glad we figured it out.

 

713f67700c6c1a68360a43755d0f72fd.jpg

Kevin SAS
Level 1
Level 1
Hi,
You should try to change the group multicast out of 224.0.0.0/24. This is a reserved scope on link local subnet and equipment does not follow normal procedures of join.
That's the fastest and cleanest solution.
HTH
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco