CNI Overloading

Having tried 2 CNI's with the same results I am coming to the conclusion that I might be overloading the CNI with network traffic. Does anyone know if this is possible ?

The CNI is connected to a 28 port gigabit CISCO switch (layer 2 at moment).

Pinging the CNI sometimes returns a hit, sometimes not.

Both CNI's exhibit exactly the same behavior.

I have over 100 ethernet devices on the network including AV kit like kaleidescape and lots of Crestron kit too.

Any suggestions most welcome.

Cheers
Chris

 

I just tried disconnecting the other kit and everything returns to normal. So the question is how can I stop the CNI failing because of too much network traffic ?

Ta
Chris

 

Its a brand new high spec / high performance cisco switch. Everything else on the network is fine and works perfectly. Are you sure the CNI can handle multicast traffic properly without getting overloaded for example ? At some point there is a limit to how much traffic it can handle surely ?

I know Crestron series 2 processors for example do not have the CPU to handle the multicast traffic from Kaleidescape servers and need to be isolated on the network (Mine is series 3 so its fine).

Cheers
Chris

 

Can you configure the switch to not send multicast packets to the CNI port?

 

I have a similar problem on my LAN and traced it to SSDP sending massive amounts of data for no reason. Multicast is more than likely your cause of it, did you at some stage add a network printer or even a streaming device that advertises it's services via SSDP or similar?

When it happens to me I see all the Switch port LED's go absolutely berzerk. Putting a sniffer on the LAN showed me exactly which devices caused it and voila, restart that device and the problem goes away for another few weeks until something triggers it again.

The reason that the CNI dies is probably just the Switch port being so flooded by traffic that normal packets don't even get through. The CNI probably don't even listen to the Multicasts so if it was a 1G port it would have been fine (or not ).

Good luck, the Switch is probably just doing what it's designed to do... Forward all packets for unknown MAC's out all ports to try and learn the MAC of the destination.

Ingo

 

Cisco commands

Depending what model CISCO switch you have you can control this.

do this on the switch

Switch#show int g1/0/1 switchport

Name: Gi1/0/1
Switchport: Enabled
Administrative Mode: static access
Operational Mode: static access
Administrative Trunking Encapsulation: negotiate
Operational Trunking Encapsulation: native
Negotiation of Trunking: Off
Access Mode VLAN: 9 (VLAN0009)
Trunking Native Mode VLAN: 1 (default)
Administrative Native VLAN tagging: enabled
Voice VLAN: none
Administrative private-vlan host-association: none
Administrative private-vlan mapping: none
Administrative private-vlan trunk native VLAN: none
Administrative private-vlan trunk Native VLAN tagging: enabled
Administrative private-vlan trunk encapsulation: dot1q
Administrative private-vlan trunk normal VLANs: none
Administrative private-vlan trunk associations: none
Administrative private-vlan trunk mappings: none
Operational private-vlan: none
Trunking VLANs Enabled: ALL
Pruning VLANs Enabled: 2-1001
Capture Mode Disabled
Capture VLANs Allowed: ALL

Protected: false
Unknown unicast blocked: disabled
Unknown multicast blocked: disabled
Appliance trust: none




look at the second last line if disabled turn it on with

config t
int g1/0/1
switchport block multicast


This will stop in sending multicast to that port.



Cannot do this on a neatgear !!!


Charles

 

This is what I do
----------------------

Disable the network gateway address from the CNI and remove it from DHCP. Place the CNI into a range of IP numbers which is excluded from the DHCP range. This usually requires people to limit the DHCP range.

This would then make the CNI temporarily unavailable from off-site connections over a router but still addressable from LAN connections over Teamviewer. In other words, a PC on the same lan would need to be running Teamviewer.

You can also look at doing a fixed speed on the CNI data rate like 100 or 10.

This is purely for diagnostic setup. I also would look at doing a firmware update from the original manufacturer. The way it handles networks was improved in later firmwares.

When the memory buffering isnt matched the level-2 switches can at times strobe the legacy devices and cause an unreasonable amount of traffic. This can be because of a revision in TCP/IP.

 

Hi Guys,

My installers blocked the multicast 'spam' exiting the hub with the Kaleidescape kit on it. Totally fixed now. Proof that you can overwhelm a CNI with broadcast traffic.

Cheers
Chris

 

That may also be handled with exclusions.

 

Hi,

This is quite a common issue with many embedded Ethernet units. Unless they have specific hardware filtering in place (and it's activated!) they will often get bogged down if there is a large amount of broadcast/multicast data on the network. I'm a fan of shifting 'small' devices off into their own VLAN (assuming you have a switch that supports VLANS and have the means to route between them). There are other ways of reducing the traffic but such as blocking broadcasts but I've found that a separate VLAN is usually the easiest to maintain in the long run. I've had this issue with all sorts of gear from Cisco ATA units to CNI gateways and everything in between ;-(

John

 

When you refer to the idea of VLAN are you suggesting a second NAT translation ? Or are you operating with two independent network setups and a router between them ?

By definition a VLAN is a virtual implement in software which embedded devices dont usually understand. Multiple routing zones are hardware implementations.

As a rule of thumb, one may avoid using 10.x.x.x as a network configuration given that the embedded controller is not designed to handle Class-A subnet mask traffic.

Alternately, one may also operate with different subnet masks.