06-14-2018 10:20 AM - edited 03-10-2019 01:15 PM
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?
Solved! Go to Solution.
06-15-2018 11:22 AM
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?
06-14-2018 01:34 PM - edited 06-14-2018 01:39 PM
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.
06-14-2018 01:42 PM
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.
06-15-2018 05:39 AM - edited 06-15-2018 05:41 AM
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.
06-15-2018 08:24 AM
06-15-2018 08:50 AM
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.
06-15-2018 09:32 AM
06-15-2018 10:08 AM
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.
06-15-2018 10:37 AM
06-15-2018 10:55 AM
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?
06-15-2018 11:22 AM
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?
06-15-2018 11:29 AM
06-15-2018 11:34 AM
Woohoo! I'm glad we figured it out.
06-15-2018 08:48 AM
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide