cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2120
Views
2
Helpful
22
Replies

unusual traffic load on WLC ports

Temur Kalandia
Level 1
Level 1

Hello everyone, 

i have installed Cisco 9800-CL virtual WLC on vmWare ESXi. 

current setup lools like : 

  • WLC has dedicated MGMT interface(GIG1) and trunk port (GIG2).
  • Cisco VPC is configured with ESXi standard switch, with active passive uplink ports. no LACP, or etherchannel. 
  • WLC is centrally switching user traffic
  • promiscius mode and forged transmit rejected at vSwitch level and accepted at port-group level. 

 problem description:

we see unusuall traffic load on trunk interface (GIG2)(RX) , it is two times higher compared to MGMT interface (TX). 

image.png

i assume that tunnell established between AP and MGMT port is tranfering control and data traffic and at least same amound of data should be on trunk side. i have doubt that something is duplicating packets but dont understand how to troubleshoot the problem.

 

22 Replies 22

Rich R
VIP
VIP

You might also want to look at https://community.cisco.com/t5/wireless/9800-cl-swport-4-mac-conflict-issues/td-p/4283443

JPavonM
VIP
VIP

I have another TAC case open about this errors, as in my case the ESX fix has not stopped the C9800-CL errors.

Temur Kalandia
Level 1
Level 1

Hello Everyone, 

we fount the issue. here is the description :

in our initial configuration we have used  GIG1 for wireless management and GIG2 for data plane trunk. controll plane traffic must to GIG1 and data plane to GIG2. but in reality we were seeng controll plane traffic load on GIG2 also. exaclty the same traffic was going to GIG2, this was cousing unusuall TX RX values. 

after little bit research , we found that GIG1 must be used only for out of band MGMT (OOB) and Switch Virtual Interface (SVI) must be created for wireless management and attached to GIG2 interface. after replicating that configuration everything was ok, TX and RX values become normal.

so my advice is to not use GIG1 for wireless management. 

additionally even in our original configuration data flow must be normal, but becouse of that OOB function, GIG1 interface has different traffic flow. Cisco says that it is placed in dedicated VRF, but it is not. maybe something else is happening there, but at this point i dont care. just dont use GIG1

This is actually covered in the Best Practice guide: https://www.cisco.com/c/en/us/products/collateral/wireless/catalyst-9800-series-wireless-controllers/guide-c07-743627.html#C9800CLconsiderations

Basically you should never allow the same VLAN on Gig1 and Gig2.  Gig1 - only for out of band management.  Gig2 - all AP management and client VLANs.  The VRF is immaterial to this problem - it's about VLAN config.

Using a separate VRF for your out of band management (whether on port or vlan) is still good from a security point of view but take note of the different VRF limitations in different versions.

Hello @Rich R , 

we did not have same VLAN on both interfaces, GIG1 had MGMT VLAN and GIG2 all SSID VLANs(exept that MGMT). and this type of config has produced strange traffic loads on bith interfaces. 

now it is ok, we just have all nessesary VLANs passed via GIG2 and not using GIG1 at all

But did you restrict/separate those VLANs on the hypervisor switch(es) (as per the guide) @Temur Kalandia or did you just use vlan allowed on the WLC ports?  vlan allowed means it will ignore the non-allowed VLANs but doesn't stop it receiving all the traffic if all VLANs are allowed on the hypervisor switch.

hi @Rich R , 

you are right from hypervisor it is not possible to restrict VLANs on trunk port, unless it is vmware distributed switch. i had standard switch and configured as you described. at this moment everything is ok. 

 

Cool - that explains why you saw all the traffic on both ports.

Review Cisco Networking for a $25 gift card