Well...looky what we have

ITAdmin777 · ‎03-13-2014

Hi Community

We just implemented a new VLAN to seperate our physical workstations. We continue to test with a few switchports/workstation (4 of them) on the new VLAN, however we noticed the following. When we change the switchport to new VLAN and peform an IP /release IP/renew on the workstation....it takes approx 2-3 minutesto ger an IP from new VLAN/DHCP pool? also PC's seem to slow to a crawl at times?

As mentioned we only have 4 workstations on new VLAN.

To compare, when the switchports/workstations where on the old VLAN......none of the above occurred?

Jon Marshall · ‎03-13-2014

Where/what is the DHCP server ?

If it is a separate device presumably it on a different vlan so you have configured an "ip helper-address .." ?

Have you enabled portfast on the ports ?

What is the configuration of the ports ?

Jon

ITAdmin777 · ‎03-13-2014

Hello Jon

The DHCP server resides on our Core 3750 switch.

ip dhcp pool vlan41
network 192.168.41.0 255.255.255.0
default-router 192.168.41.254
domain-name MYCOMPANY.COM
dns-server 192.168.1.44 192.168.1.45

Also here is what a typical switchport looks like in our environment before and after VLAN change

Before Change (old VLAN 10)

interface FastEthernet1/0/14
description ACCESS
switchport access vlan 10
switchport mode access
switchport nonegotiate
switchport voice vlan 50
no logging event link-status
load-interval 30
srr-queue bandwidth share 10 10 60 20
priority-queue out
mls qos trust device cisco-phone
mls qos trust dscp
no snmp trap link-status
auto qos voip cisco-phone
storm-control broadcast level pps 1k
storm-control multicast level pps 2k
storm-control action trap
macro description ACCESS_PORT
spanning-tree portfast
spanning-tree guard root
service-policy input AutoQoS-Police-CiscoPhone
!

After Change (New VLAN 41)

interface FastEthernet1/0/14
description ACCESS
switchport access vlan 41
switchport mode access
switchport nonegotiate
switchport voice vlan 50
no logging event link-status
load-interval 30
srr-queue bandwidth share 10 10 60 20
priority-queue out
mls qos trust device cisco-phone
mls qos trust dscp
no snmp trap link-status
auto qos voip cisco-phone
storm-control broadcast level pps 1k
storm-control multicast level pps 2k
storm-control action trap
macro description ACCESS_PORT
spanning-tree portfast
spanning-tree guard root
service-policy input AutoQoS-Police-CiscoPhone
!

Jon Marshall · ‎03-13-2014

So just the data vlan change then.

Can you post config of 3750 ?

You may need to run wireshark on a PC to see why it is taking so long to get a DHCP address.

Jon

ITAdmin777 · ‎03-13-2014

Yes we only changed the data vlan from 10 to 41

Here are all the changes we made on My-Switch1 (Core) and My-Switch2)

My Switch 2 contains the 4 switchports we have been testing with whereby we have experienced the issues

What is interesting is my own workstation was th first one to test and I experienced the symptoms yesterday...however today I have not had a hiccup thus far?

Does it have anything to do with spanning-tree or OSPF? and it took a while to learn routes or anything like that?

Here are the changes...what is not shown here is the Po-Groups wih VLAN's added just to cut down on the config clutter : )

My Core Switch

vlan 40
name vDesktops(192.168.40.0/24)

vlan 41
name WRKSTNs(192.168.41.0/24)

interface Vlan40
ip address 192.168.40.254 255.255.255.0

interface Vlan41
ip address 192.168.41.254 255.255.255.0

! This scope is defined for vDesktops (VDI)
ip dhcp pool VLAN40
network 192.168.40.0 255.255.255.0
default-router 192.168.40.254
domain-name mycompany.com
dns-server 192.168.1.44 192.168.1.45

! This scope is defined for the physical workstations
ip dhcp pool VLAN41
network 192.168.41.0 255.255.255.0
default-router 192.168.41.254
domain-name mycompany.com
dns-server 192.168.1.44 192.168.1.45

Reserve a block
ip dhcp excluded-address 192.168.40.1 192.168.40.20
ip dhcp excluded-address 192.168.41.1 192.168.41.20

spanning-tree vlan 3,10,20,50,40,41,900,999 priority 24576

router ospf 100
router-id 192.168.1.10
log-adjacency-changes
passive-interface Vlan10
passive-interface Vlan30
passive-interface Vlan40
passive-interface Vlan41
passive-interface Vlan50
passive-interface Vlan500
network 192.168.0.2 0.0.0.0 area 0
network 192.168.1.10 0.0.0.0 area 0
network 192.168.30.254 0.0.0.0 area 0
network 192.168.33.254 0.0.0.0 area 0
network 192.168.40.254 0.0.0.0 area 0
network 192.168.41.254 0.0.0.0 area 0
network 192.168.51.254 0.0.0.0 area 0
network 192.168.99.5 0.0.0.0 area 0
network 192.168.200.254 0.0.0.0 area 0

________________________________________
________________________________________
My-Switch2

vlan 40
name vDesktops(192.168.40.0/24)

vlan 41
name WRKSTNs(192.168.41.0/24)

Jon Marshall · ‎03-13-2014

Your config looks fine. Couple of things -

1) before you changed to the new vlan did you do an "ipconfig /release" to release the old IP

2) don't forget as well when you change the IP of the workstation this means the arp cache on the L3 switch is now mapping the mac address to the old IP.

Jon

ITAdmin777 · ‎03-13-2014

I believe these are the steps I took for all 4 test workstations:

Requested users close out of programs

I then changed switchport to new VLAN

Did an ip /release and ip /renew

Did I do the above in the wrong order??

As far as arp cache you are referring to.....how do I see that or know if that is what is going on? or clear the cache for a specifc switchport/mac addr of workstation?

As mentioned I do not seem to exibit the behavior today on my Win 7...but one of test users whom has an XP machine experienced the issue yersterday and it seems to be occuring today!

IOS commands appreciated!

Thanks,

Jon Marshall · ‎03-13-2014

For the release/renew yes it was the wrong order. You need to release it when it is in it's current vlan rather than when you change to the new vlan because that IP is no longer relevant to the new vlan.

For the arp table -

"sh ip arp <IP address>"

to clear that entry -

"clear ip arp <IP address>

Jon

Jon Marshall · ‎03-13-2014

Just did a quick lookup and when a Windows device gets a new IP it should send a gratuitous arp which should update the arp table on the 3750.

So try releasing/renewing before taking it out of it's original vlan and then check the 3750 to make sure the correct arp table entry is there.

Jon

ITAdmin777 · ‎03-13-2014

Here is the entry as per "sh ip arp 192.168.41.19" for the XP machine having the most issues.

Protocol Address Age (min) Hardware Addr Type Interface
Internet 192.168.41.19 4 0016.e604.7b34 ARPA Vlan41

Should I just clear it anyway?

________________________________

_______________________________

Also...several days ago we adjusted our DHCP scope on the old VLAN to 4 hours....this is so when computers renew...they are now on a 4 hour lease rather than 24.

Reason for this.....my goal was to change a range of ports 1 switch at a time (we have 4 of them) after hours or weekend...

Therefore my thinking/process and correct me if I am wrong.

1) Have the workstations shutdown at night,

2) Change switchports to new VLAN

3) User power up in AM and should get new IP from new VLAN/DHCP pool.

One issue that comes to mind with above.......we have many users that simply lock thier PC and night and do not shutdown...therefore not sure how to deal with.

Would it be better to just do a "shut and no shut" on the range of ports....would that work? and if so in what order should I do things?

Gotta say...sure learning a lot from this project...thanks Jon.

Jon Marshall · ‎03-13-2014

Re the arp entry, is that correct ? If so nothing to do.

In terms of the release/renew i know what you mean about users not shutting down. There is no foolproof way to sort this. We used to send a message out saying all users must shutdown their PCs otherwise they could experience connectivity issues the next day and then i was up to them really.

There is only so much you can do

Note that this may not be the issue at all and it may be something else. I was just covering what may be issues. It may be worth doing a -

"sh ip arp | include 0016.e604.7b34" just to make sure the same device does not have multiple IPs in the arp table.

Shouldn't do but worth a check.

Jon

ITAdmin777 · ‎03-13-2014

Well...looky what we have here? The user did have .22 yesterday and we assigned static (.19) this AM.

sh ip arp | include 0016.e604.7b34

Internet 192.168.41.19 9 0016.e604.7b34 ARPA Vlan41
Internet 192.168.41.22 186 0016.e604.7b34 ARPA Vlan41

I should clear both from arp table? I will have to check my other 3 test systems as well.

______________________________________________________

So assumming we have users that do not shutdown as you stated....to fix:

Clear the IP from apr table

perform IP /release IP/ renew on workstation.

Jon Marshall · ‎03-13-2014

So -

1) do an "ipconfig /release"

2) clear both entries from the arp table

3) do an "ipconfig /renew"

and recheck the arp table to make sure it is looking okay.

Edit - actually if the IP is now static no need for the first step. Just disconnect the PC, remove the IP, set to DHCP and then do the other steps above.

Jon

ITAdmin777 · ‎03-13-2014

Hi Jon,

I did as you suggested....and also came across another article that suggested doing the following on the XP workstation:

On workstation command prompt type:

netsh interface ip delete arpcache.

Arp table show the correct Mac/ip

I should know within a few hours if everything OK!

___________________________________________

____________________________________________

If this works, I will pick on a few more workstations and compete in the following order:

Test 1) During Daytime

ip /release

change switchport vlan

ip /renew

Test 2) After Hours

1) Have the workstations shutdown at night,

2) Change switchports to new VLAN

3) User power up in AM and should get new IP from new VLAN/DHCP pool.

___________________

VERIFY:

verify switchports in new vlan

show vlan id 41

________________

Troubleshooting tips

show mac adress-table

For the arp table -

"sh ip arp <IP address>"

to clear that entry -

"clear ip arp <IP address>

Any other tid bits you can pass along?

Thanks

Jon Marshall · ‎03-13-2014

I think that should do it for now.

I'm assuming when you move the PC into the new vlan it stays on the same port on the switch ?

If so no need to worry about the mac address table just the arp table.

Jon

Workstations operating slower on new VLAN