Need help with 3750 unable to communicate with Modicon

[jeffrey.chaisson]

Having a strange issue.  Currently we have a device (Schneider Modicon NOE) sitting on vlan1 (192.168.x.x that we are unable to communicate

with.  Have narrowed it down to something with the 3750-12S switches that we have in the network.  I setup a test network, completely flat with no trunks, vlans or routing and the device is unreachable.  Other devices within the subnet workfine, is there something different about the 3750 that I am unaware of?

This should be very simple, yet it refuses to work.  Same network minus the 3750's and it works just fine.  After several packet captures using Fluke Optiview, it looks like we are not getting any ARP replies from the device.....any ideas why a device would reply to an ARP from one switch but not another?  Alternatively...any ideas why an ARP would be discarded coming or going to a 3750?

IOS is at newest version, BTW.

Any help would be greatly appreciated as this has been a frustrating one!

Thanks in advance!

-Jeff

Message was edited by: jeffrey.chaisson@versopaper.com

[glen.grant]

  Do you even have a link light when they are hooked up ?

[jeffrey.chaisson]

yes link is up....other devices within the same subnet are reachable.

[Adam Casella]

Hey Jeff,

From my understading we are seeing the ARP request reach the host via SPAN, but do not see an ARP reply.  This implies that the Schneider Modicon NOE may not be responding for some reason OR the traffic is dropped/lost before it gets to this device.

One item that would be tried is statically setting the ARP on the two devices (a test PC and Schneider Modicon NOE) to see if the ping begins to work without issue.

Another item that may be a problem is NIC auto-negotiation problems. I would also check to make sure that this device is auto-negotiating correctly and we are not having one side in Half-Duplex with the other side set to Full Duplez and/or running different transmission speeds (10---100 speed mismatch).

This could be seen via late collisions if there is a duplex mis-match in the "show interface x/y" command.   The cisco NIC will default to 100 half duplex is auto-negotiation fails. If we see the auto-nego fail, hardset each side and test.  This would also imply a NIC compatibility issue.

If auto-nego looks correct,  I would make sure that STP is forwarding without issue using the command "show spanning-tree interface x/y <---interface of Schneider Modicon NOE.

I would also check to make sure we are not getting any other errors on the interface.  This can be seen on the "show interface x/y" command OR via the "show controllers ethernet-controllers x/y"

However, based on what you are saying I would first suspect an auto-nego issue.

Let me know if this helps.

Thanks,

Adam

[gatlin007]

Just to state the absolute basics...

When you execute a 'show mac address-table' on the suspect 3750 do you see the NOE mac address behind the switchport you'd expect to see it behind?  If it's not there drill into why.  If it's there go upstream to the L3 default gateway and look for it.  Can the L3 default gateway ping or ARP the NOE?

Chris

[jeffrey.chaisson]

Apparently this device is using SNAP encapsulation.   So does anyone know how to get SNAP to work on a 3750?  I tried using the "IP SNAP FORWARDING" command and it comes back saying that "switch 1 does not support IP SNAP forwarding"

Any ideas?

[gatlin007]

Is this switch part of a stack?  I found this in the command reference:

Use the ip snap forwarding global configuration command to enable forwarding of IPv4 and IPv6 frames with SNAP encapsulation.

If a switch that is joining the stack does not support forwarding of  IPv4 and IPv6 frames with SNAP encapsulation, all the switches in the  stack do not forward the IPv4 and IPv6 frames, and this forwarding  feature is disabled.

[jeffrey.chaisson]

nope not a stack, just a standalone switch.

[gatlin007]

Can you draw us a diagram that depicts how devices utilizing SNAP encapsulation are connected to the switched network?  Also include if these devices can communicate with each other properly and if they need to communicate with devices that use other types of encapsulation (please include the encapsulation of those devices). 


Chris

[Adam Casella]

Hey,

This is an old limitation on the 3750 model you are using.  Only the  following support SNAP encap'ed forwarding as of 12.2(25)SEC:

Catalyst 3560: 3560-24TS, 3560-48TS, 3560G-24TS, 3560G-48TS, 3560G-24PS, and 3560G-48PS

Catalyst 3750: 3750G-24TS-1U, 3750G-48TS, 3750G-24PS, or 3750G-48PS

On a stack of Catalyst 3750 switches, the command will be available if one of the switches listed above is present, or provisioned.

On other standalone SKUs, or if the stack contains any other SKUs, the command will be rejected with an error message.

Looks like you will need to use a different model 3750/3560.

Also keep in mind that the new 3750-E/2960-S's do not support SNAP encaped packets.

Thanks,

Adam