Hi,
If you have genuine multicast traffic in your network then you can apply Broadcast and multicast limit on the up links.
Else stop the cast by ACL.
Regards
Rajesh Singh,
ÑÇÌêÔ ÓæÌ
Sr. Network Engineer,
åçæÏÓ ÔÈãÇÊ Ãèä
________________________________
From: foundry-nsp [foundry-nsp-bounces@puck.nether.net] on behalf of Justin Keery [justin.keery@venus.co.uk]
Sent: Wednesday, November 19, 2014 2:03 PM
To: foundry-nsp@puck.nether.net
Subject: [f-nsp] ANY IDEAS - IP6 multicast traffic causing severe CPU load issue (on ICX)
Hi folks, any ideas about this?
The switches affected by this include ICX6540, 6610 and 6650 all of which were involved in transporting the VLAN described below.
IP6 multcast traffic (less than 20Mbit/sec, discovered with wireshark on a mirror port) on VLAN682 was causing >40% CPU load on all switches where this VLAN was configured, even though there is no IP virtual interface in this VLAN. At one point there was a brief but serious OSPF failure whilst this condition was present.
With the ingress port shut down the CPU load returned to 1%.
We tried to disable IP4 and IP6 igmp / mld snooping, this had no effect. We then added a router-interface so we could add an IP6 ACL to filter *all* IP6 traffic - again no effect
vlan 682 name KARMARAMA_L2_ONEA809159_682 by port
tagged ethe 1/2/1 to 1/2/3
router-interface ve 682 <- added later so we could implement an ACL
multicast disable-igmp-snoop <- did not help
multicast6 disable-mld-snoop <- did not help
We need a way to make sure that IP6 multicasts on a VLAN won't overload the CPU on any switch with that VLAN present - ideally filter that VLAN from the CPU altogether!
Any ideas?
Thanks
Justin
---------------------------------------------------------------------------------------
DISCLAIMER
This message (including any attachments) is confidential and intended solely for the person or organization to whom it is addressed. It may contain privileged and confidential information. If you are not the intended recipient, you should not copy, distribute or take any action in reliance on it. If you have received this message in error, please notify us immediately by telephoning or E-mailing the sender. This footnote also confirms that this E-mail message has been scanned for the presence of computer viruses.
---------------------------------------------------------------------------------------
Please consider the environment before printing this email
If you have genuine multicast traffic in your network then you can apply Broadcast and multicast limit on the up links.
Else stop the cast by ACL.
Regards
Rajesh Singh,
ÑÇÌêÔ ÓæÌ
Sr. Network Engineer,
åçæÏÓ ÔÈãÇÊ Ãèä
________________________________
From: foundry-nsp [foundry-nsp-bounces@puck.nether.net] on behalf of Justin Keery [justin.keery@venus.co.uk]
Sent: Wednesday, November 19, 2014 2:03 PM
To: foundry-nsp@puck.nether.net
Subject: [f-nsp] ANY IDEAS - IP6 multicast traffic causing severe CPU load issue (on ICX)
Hi folks, any ideas about this?
The switches affected by this include ICX6540, 6610 and 6650 all of which were involved in transporting the VLAN described below.
IP6 multcast traffic (less than 20Mbit/sec, discovered with wireshark on a mirror port) on VLAN682 was causing >40% CPU load on all switches where this VLAN was configured, even though there is no IP virtual interface in this VLAN. At one point there was a brief but serious OSPF failure whilst this condition was present.
With the ingress port shut down the CPU load returned to 1%.
We tried to disable IP4 and IP6 igmp / mld snooping, this had no effect. We then added a router-interface so we could add an IP6 ACL to filter *all* IP6 traffic - again no effect
vlan 682 name KARMARAMA_L2_ONEA809159_682 by port
tagged ethe 1/2/1 to 1/2/3
router-interface ve 682 <- added later so we could implement an ACL
multicast disable-igmp-snoop <- did not help
multicast6 disable-mld-snoop <- did not help
We need a way to make sure that IP6 multicasts on a VLAN won't overload the CPU on any switch with that VLAN present - ideally filter that VLAN from the CPU altogether!
Any ideas?
Thanks
Justin
---------------------------------------------------------------------------------------
DISCLAIMER
This message (including any attachments) is confidential and intended solely for the person or organization to whom it is addressed. It may contain privileged and confidential information. If you are not the intended recipient, you should not copy, distribute or take any action in reliance on it. If you have received this message in error, please notify us immediately by telephoning or E-mailing the sender. This footnote also confirms that this E-mail message has been scanned for the presence of computer viruses.
---------------------------------------------------------------------------------------
Please consider the environment before printing this email