Application failure after change to WS-3650-24ts

seanwaite · ‎05-05-2017

I have a problem where swapping out switches caused an application failure. Here is the scenario; Client (Win 7) is connected to an unmanaged switch, and Server (Win 7) is connected to same switch on a different switch port. The unmanaged switch is replaced with a 3650, but none of the ports are configured to use any vlan i.e. default . It is when we move to the 3560 the application itself fails, even though the client can ping the server and vice versa. All other workstations have network connectivity, can reach internet etc. It is just this one application that failed to communicate. When returning to the old unmanaged switch the client=server communication resumed.

The software manufacture just sends details on ports, which ports need to be opened etc. But as this is a swapping of one unmanaged switch to the 3650 this I would consider a layer 2 problem. The 2 workstations were on ports 1/0/8 and 1/0/10. After the switch change all 24 ports were used up, and it is only the communication between the client application to the server that was affected. Only the first 2 ports were configured for etherchannel and that worked as expected, and communication to internet worked as such.

Building configuration...
Current configuration : 5154 bytes
!
! Last configuration change at 18:20:31 UTC Fri Apr 28 2017
!
version 15.2
no service pad
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
service compress-config
!
hostname c3650
!
boot-start-marker
boot-end-marker
!
vrf definition Mgmt-vrf
!
address-family ipv4
exit-address-family
!
address-family ipv6
exit-address-family
!
no aaa new-model
switch 1 provision ws-c3650-24ts
!
ip routing
!
qos queue-softmax-multiplier 100
!
diagnostic bootup level minimal
spanning-tree mode pvst
spanning-tree extend system-id
hw-switch switch 1 logging onboard message level 3
!
redundancy
mode sso
!
class-map match-any non-client-nrt-class
!
interface Port-channel1
description ASA5525 Inside2 Primary
switchport mode trunk
!
interface GigabitEthernet0/0
vrf forwarding Mgmt-vrf
no ip address
shutdown
negotiation auto
!
interface GigabitEthernet1/0/1
description ASA5506 Line
switchport mode trunk
channel-protocol lacp
channel-group 1 mode active
!
interface GigabitEthernet1/0/2
description ASA5506 Line
switchport mode trunk
channel-protocol lacp
channel-group 1 mode active
!
interface GigabitEthernet1/0/3
!
interface GigabitEthernet1/0/4
!
interface GigabitEthernet1/0/5
!
interface GigabitEthernet1/0/6
!
interface GigabitEthernet1/0/7
!
interface GigabitEthernet1/0/8
!
interface GigabitEthernet1/0/9
!
interface GigabitEthernet1/0/10
!
interface GigabitEthernet1/0/11
!
interface GigabitEthernet1/0/12
!
interface GigabitEthernet1/0/13
!
interface GigabitEthernet1/0/14
!
interface GigabitEthernet1/0/15
!
interface GigabitEthernet1/0/16
!
interface GigabitEthernet1/0/17
!
interface GigabitEthernet1/0/18
!
interface GigabitEthernet1/0/19
!
interface GigabitEthernet1/0/20
!
interface GigabitEthernet1/0/21
!
interface GigabitEthernet1/0/22
!
interface GigabitEthernet1/0/23
!
interface GigabitEthernet1/0/24
!
interface GigabitEthernet1/1/1
!
interface GigabitEthernet1/1/2
!
interface GigabitEthernet1/1/3
!
interface GigabitEthernet1/1/4
!
interface Vlan1
description ASA5506 Line
ip address 192.168.100.2 255.255.255.0
!
interface Vlan2
description Primary Office
ip address 10.1.1.2 255.255.255.192
!
interface Vlan3
description IP Cameras
ip address 192.168.200.1 255.255.255.224
!
ip default-gateway 192.168.100.1
ip forward-protocol nd
ip http server
ip http authentication local
ip http secure-server
ip route 0.0.0.0 0.0.0.0 192.168.100.1
!
!
!
snmp-server community public RO
!
!
line con 0
stopbits 1
line aux 0
stopbits 1
line vty 0 4
exec-timeout 60 0
privilege level 15
login local
transport input ssh
transport output none
line vty 5 15
privilege level 15
login local
transport input ssh
!
wsma agent exec
profile httplistener
profile httpslistener
!
wsma agent config
profile httplistener
profile httpslistener
!
wsma agent filesys
profile httplistener
profile httpslistener
!
wsma agent notify
profile httplistener
profile httpslistener
!
!
wsma profile listener httplistener
transport http
!
wsma profile listener httpslistener
transport https
!
ap group default-group
end
c3650#

Georg Pauwen · ‎05-05-2017

Hello,

which application is affected, and which ports are used ?

seanwaite · ‎05-05-2017

It is a SCADA application by Rockwell Automation called Factory View which uses a series of different TCP ports. But I would discount TCP/UDP ports at the outset as these should not even have a role at this layer, or so I thought. In hindsight I wish I would have done packet capture on the workstations but did not at the time. The problem is in one sense I do have L2 connectivity, it is just for some reason this application like locked onto the MAC of the switch it was connected to and would only use that.

Georg Pauwen · ‎05-05-2017

Hello,

I have researched the application, it appears that there is some kind of copy protection which can be, as you stated, tied to the MAC address.

This link talks about FT activation. I wonder if reactivating the software will make it work again...

https://theautomationblog.com/what-is-factorytalk-activation/

seanwaite · ‎05-08-2017

Thank you for the link, but I do not know as of yet whether this would have anything to do with the problem. As I was informed by one of the programmers, Factory View is correctly activating, it is just the client application is not able to communicate to the server application. That happens only when physically connected to the new switch while all other internet/network related applications do in fact work.

I just do not see how a switch could affect an application like this

seanwaite · ‎05-15-2017

Just an update;

It appears that multicasting and IGMP need be configured on the switch for Factory View clients and server communication.