Unsolved
This post is more than 5 years old
4 Posts
0
22140
Multicast killing IP interfaces
We're having an issue with multicast ghosting through PC6248 switches and stacks. Essentially what happens is that during the ghosting operation, IP interfaces on the switch, most notably VLAN interfaces, become inaccessible, or non-responsive. The IP interface on the Management VLAN remains working, and traffic still passes across the switches (so we're not killing the network). Additionally, as soon as the ghost deployment is complete, the interfaces come back up.
While the most irritating part of this is that our monitoring systems spam us about the switch being down (which is only partly correct), it doesn't seem quite right that it happens. Has anyone else noticed this behaviour? I've searched fairly hard but not found anything that really matches what we're seeing.
A simplified config could be condensed to this (firmware 2.2.0.3):
!--------------------------------------------------------------------
configure
vlan database
vlan 120,1918,1203
exit
!
hostname "ugrad.switch"
!
stack
member 1 2
member 2 2
member 3 2
exit
ip address 192.168.0.4 255.255.255.0
ip address vlan 1918
ip domain-name switch
!
ip routing
ip route 0.0.0.0 0.0.0.0 192.168.120.1
!
interface vlan 120
name "Main"
routing
ip address 192.168.120.4 255.255.255.0
exit
!
interface vlan 1918
name "1918-Management"
exit
!
interface vlan 1203
name "Deployment"
routing
ip address 192.168.123.4 255.255.255.0
ip igmp-proxy
exit
!
ip igmp
ip multicast
!
ip ssh server
bridge multicast filtering
ip igmp snooping
!
! In lab 1, being deployed
!
interface ethernet 1/g1
storm-control broadcast
description 'host001.lab'
ip igmp snooping
spanning-tree portfast
switchport access vlan 1203
exit
!
! In lab 1, being deployed
!
interface ethernet 1/g2
storm-control broadcast
description 'host002.lab'
ip igmp snooping
spanning-tree portfast
switchport access vlan 1203
exit
!
! In lab 2, NOT being deployed
!
interface ethernet 1/g3
storm-control broadcast
description 'host003.lab2'
ip igmp snooping
spanning-tree portfast
switchport access vlan 120
exit
!
interface ethernet 1/xg3
description 'Uplink to 10Gb backbone on core'
ip igmp snooping
switchport mode trunk
switchport trunk allowed vlan add 120,1918,1203
switchport trunk allowed vlan remove 1
exit
!
! Further down the stack
!
interface ethernet 3/g48
storm-control broadcast
description 'ghostsrv.deployment'
ip igmp snooping
spanning-tree portfast
switchport access vlan 1203
exit
exit
!--------------------------------------------------------------------
With that in place, if we throw a ghost deployment session from 3/g48 to 1/g1,1/g2 over VLAN 1203, pinging 192.168.120.4 or 192.168.123.4 from hosts on those subnets and VLANs fails, which means our monitoring systems deduce that the switches are down.
I can still connect to the switch via the serial console, or SSH on the management VLAN, and traffic is still forwarded at layer2, but it is an irritation.
I've held off on applying the latest firmware, but the release notes don't seem to mention or address any issues that seem to match what we're seeing (and after the stacking issues with the first 3.x release, I wanted to see if it was stable in a testing environment first).
Am I making some daft configuration errors, or missing some settings vital to successful multicasting? Any ideas? Give me a kick if you need more info.
Cheers.
ictdaemon
4 Posts
0
July 27th, 2010 07:00
(Plain text formatting on this forum fails, please ignore this reply)
ictdaemon
4 Posts
0
August 3rd, 2010 09:00
bh1633
909 Posts
0
August 5th, 2010 13:00
When the switch has routing enabled on a vlan, it puts the switch CPU in the vlan. This is a slow interface so it can become swamped when there is multicast, broadcast and unknown unicast traffic on the routed vlans. Set the broadcast, multicast and unicast storm control to the most restrictive and see if this fixes your issue.
For example:
interface ethernet 1/g1
storm-control broadcast level 1
storm-control multicast level 1
storm-control unicast level 1
exit
Storm control setting is more of a trial and error thing. If the above works without any noticeable impact on your network, leave it. If other things start happening that are attributable to dropping broadcast, multicast, slow learning, then try reducing the restrictions until network operation is optimal.
ictdaemon
4 Posts
0
August 6th, 2010 03:00
Ah, you've given me another possible solution with that, and it explains why the management VLAN interface is still accessible (as it's not routing).
I don't really need to have an IP interface on the deployment VLAN, as I can monitor the health of the switch from the other VLAN interfaces as necessary. So if I drop the ip address I can disable routing on that VLAN too, and is shouldn't swamp the CPU. If that works, it should be a cleaner fix than tweaking storm-control also.
I'm going on holiday on Sunday, and we shouldn't need to deploy any images at least until I get back, so I will report back with news then if it works either way.
Thanks BH1633.
Cheers.