Servers Migration from VLAN 1 to New VLAN 10

[Nuhu_2007]

Greeting to All,

Please guide ......

We migrate our Application Servers from default vlan1 to new vlan10 by removing VLAN 1 SVI  and assigning it to VLAN 10  plus changing access port to  respective vlan 10 connected to Servers .Now we are facing issues with some client when they access application server there PC hangs after a while and they have to reset the same application it happened after moving Server from default VLAN.

Please note : No firewall or any sort of ACL exist between client and Server .

                      Core Switch perform L3 functionality .

                      No ping drop/ No CRC etc all troubleshooting step performed.

Regards

[Dennis Mink]

Did you clients used to be in VLAN 1 as well? so do you connections to you app servers now go between different subnets?

[Nuhu_2007]

Dear Dennis Mink,

To make it more clear , initially it was a flat network  .

In first stage we moved  clients to vlan X ,Y,Z  with different subnets  based on depart and against each Vlan SVI have configured in Core Switch plus routing enabled  so thats work fine at that stage .

Problems started when we migrate app Servers from Vlan 1 to Vlan 10 , as we don't want to disturb our business so changes in Server side was a difficult.

Do we need to make some sort of changes in Native VLAN as it still VLAN 1.

thanks in advance 

[Richard Burts]

Initially when I read this I thought that the issue was that some clients could not access the servers when the servers are moved to vlan 10. So I was thinking about what could cause this. But as I read more carefully the original post says that "there PC hangs after a while ". So am I correct in now understanding that after the move that all clients initially can access the servers but some clients hang after a while? And does that mean that some clients can access the servers without problem?

HTH

Rick

[Nuhu_2007]

yes , absolutely right clients exist in VLAN Y,Z can access servers without any problem. We try to move problematic clients in VLAN Y,Z plus have tried to change cable , Switch etc but still  same problem exist.

Client Server communication is 

Client(vlan x 10.16.141.x/24)------Sw----Trunk-----

Client(vlan y 10.16.101.x/24)------Sw----Trunk-----Core Sw --Trunk---Sw----App Server(172.16.x.x/16)

client(vlan z  10.16.131.x/24)------Sw----Trunk----- 

Well I am not an expert of Wireshark , May be this snap can help to sort out where exactly problem exist.

Regards

[Richard Burts]

Can you verify my understanding of the situation:

- clients in vlan Y and Z work with no issue

- clients in vlan X work initially and then stop working

- when it stops working the client restarts the application and then it works

I note one discrepancy, though I am not sure that it relates to the problem: you tell us that the subnet for vlan X is 10.16.141.x/24 but the packet capture shows address 10.16.142.37

I notice in capture 1 that there are packets between the client and the server, and that the server is sending RST (reset) responses which terminate the TCP session. Is this normal?

I notice in capture 2 that there is a lot of arp activity. Perhaps it might be helpful to run debug arp (or perhaps debug ip arp) on the core switch while the problem is going on.

HTH

Rick

[Nuhu_2007]

please find detail as 

- clients in vlan Y and Z work with no issue

We have around 50 vlans for client ,so the same application can be access from client exist in different vlans and its work fine with other vlan client.

- clients in vlan X work initially and then stop working

While those clients which exist in vlan x i-e (141,142 ) have problem .

- when it stops working the client restarts the application and then it works

initially the client access app Server through Internet Explorer (note: its intranet) start respective cases registering i-e fill form , print tag , scan and save to respective db server . it works fine for 2/3 or some time 5 cases but then browser stop , next you have open session again .

1) I note one discrepancy, though I am not sure that it relates to the problem: you tell us that the subnet for vlan X is 10.16.141.x/24 but the packet capture shows address 10.16.142.37

We tried to move the defective client to other vlan 142,101,102 but still same problem.Client in vlan 141 have same problems.

I notice in capture 1 that there are packets between the client and the server, and that the server is sending RST (reset) responses which terminate the TCP session. Is this normal?

Well , I need guide line on it why its tries to reset responses and reset causes.

I notice in capture 2 that there is a lot of arp activity. Perhaps it might be helpful to run debug arp (or perhaps debug ip arp) on the core switch while the problem is going on.

Well , please guide on this as well but let me know it my not affect our business activities.

Regards

[Richard Burts]

A server will generally send a reset when it encounters a condition that it considers incorrect. We do not know enough about your application to give good suggestions about what is causing the resets.

Running debug does have potential to impact performance. There are some things that you can do to minimize the impact - in particular do not send debug output to the console. The lowest impact would be to send debug output to logging buffered. The other low impact option is to send debug output to terminal monitor.

HTH

Rick