Hello all,
My organization is currently dealing with the EOL of the SM-X-ES3-24-P switch modules and are currently fielding the recommended SM-X-16G4M2X replacement. We are using these modules in a 4351 ISR chassis. The production unit (containing the SM-X-ES3-24-P module) runs isr4300-universalk9.16.08.02.SPA.bin as its IOS and the switch runs c3560e-universalk9-mz.152-4.E6.bin. The router I am testing with today (with the SM-X-16G4M2X module) is running isr4300-universalk9.17.03.02.SPA.bin.
The problem I am seeing is with a device which should be sending IGMP messages to the router. In our ideal configuration, which I will explain below, the IGMPs don't seem to be making it up to the router's BDI.
In the production setup (in which the multicast traffic is successfully reaching the endpoint) we use BDI 108:
interface BDI108
description OLD_BDI
ip address 172.16.0.1 255.255.255.0
ip nat inside
no ip redirects
no ip proxy-arp
zone-member security Z_ZONE
ip verify unicast source reachable-via rx 101
ip nat inside
ip pim sparse-dense-mode
no ip directed broadcast
ip igmp mroute-proxy Loopback0
ip wccp 61 redirect in
ip wccp 63 redirect in
ip wccp 65 redirect in
no cdp enable
This connects to the VLAN on the switch via the internal ethernet interface:
interface Ethernet-Internal1/0/0
description To Switch via Router backplane
no negotiation auto
no mop enabled
no mop sysid
!
service instance 108 ethernet
description OLD_VLAN
encapsulation dot1q 108
rewrite ingress tag pop 1 symmetric
bridge-domain 108
!
This is the interface that the client connects to on the switch:
interface GigabitEthernet0/8
description OLD_USER
switchport access vlan 108
switchport mode access
switchport nonegotiate
spanning-tree portfast
spanning-tree bpdufilter enable
spanning-tree bpduguard enable
spanning-tree guard root
!
In this configuration, the command "show ip igmp group" entered on the router shows the IGMPs reaching the BDI and subscribing to 225.10.2.22.
The new switch module does not run a separate instance of IOS, as the old one does. This means there is no internal ethernet interface and we need to bridge the gap between the switch and the router another way. Our ideal option is to use an SVI with a service instance to do what the internal ethernet interface was doing. This is what we are fielding (no change to the configuration of the access port):
interface BDI108
description NEW_BDI
ip address 172.16.0.1 255.255.255.0
no ip redirects
no ip proxy-arp
ip wccp 61 redirect in
ip wccp 63 redirect in
ip wccp 65 redirect in
ip pim sparse-dense-mode
ip nat inside
ip verify unicast source reachable-via rx 101
zone-member security Z_ZONE
ip igmp mroute-proxy Loopback0
no cdp enable
!
interface Vlan108
description NEW_SVI
no ip address
no ip redirects
no ip proxy-arp
service instance 108 ethernet
encapsulation dot1q 108
rewrite ingress tag pop 1 symmetric
bridge-domain 108
The setup above passes unicast traffic successfully, but introduces a problem with multicast that is stumping me. When I enter show ip igmp group on the router, I don't see any IGMPs making it from the host to the router. Alternatively, this second less-ideal option does recieve the IGMP (again no change to the access port):
interface Vlan108
description NEW_SVI
ip address 172.16.0.1 255.255.255.0
no ip redirects
no ip proxy-arp
ip wccp 61 redirect in
ip wccp 63 redirect in
ip wccp 65 redirect in
ip pim sparse-dense-mode
ip nat inside
ip verify unicast source reachable-via rx 101
zone-member security Z_ZONE
ip igmp mroute-proxy Loopback0
When I switch from the BDI-based config to the SVI-only config, the router immediately picks up the IGMPs, so I know that the client is sending them. Should the solution with the service instance applied to the SVI work? Is there any configuration I'm missing here? As I see it, I'm thinking this should work.
Let me know if I can provide further clarification.
