Questions[cisco](server)

While studying for the CCENT exam, my reference materials have made an alarming number of references to class A/B/C networks. Thankfully they just treat Class A/B/C as shorthand for /8, /16, and /24 CIDR subnets, and don't make any mention of an implicit subnet from the first nibble. Still, it throws me off to have "Class B" pop up in a question or explanation and have to remind myself at every step that there is an implied /16 mask in there.

Is this a convention that is still widely used despite being obsoleted over two decades ago? Am I going to just have to get used to this from my senior admins? And, perhaps most importantly, does Cisco expect its certified technicians/associates/experts to accept and use classful network terminology? (Ignore the last question if it violates Cisco's exam confidentiality policy.)

Update: After switching to a more authoritative reference/study guide, it became clear that Cisco expects knowledge of actual classful networks, insofar as the official study guide dedicates several chapters to them. This makes the question less about the A/B/C terminology and more about if/why admins are expected to know about classful networks.

Hoping someone here might have some insight to the issue we are facing. Currently we have Cisco TAC looking at the case but they are struggling to find the root cause.

Although the title mentions ARP broadcast and high CPU usage, we are unsure if they are related or unrelated at this stage.

The original issue has been posted on INE Online Community

We have stripped the network down to a single link no redundancy setup, think of it as a star topology.

Facts:

• We use 3750x switches, 4 in one stack. Version 15.0(1)SE3. Cisco TAC confirms no known issues for high cpu or ARP bugs for this particular version.
• No hubs/ unmanaged switches connected
• Reloaded Core stack
• We don't have a default route "Ip route 0.0.0.0 0.0.0.0 f1/0". Using OSPF for routing.
• We see large broadcast packets from VLAN 1, VLAN 1 used for desktop devices. We use 192.168.0.0/20
• Cisco TAC said they don't see anything wrong with using /20, other then we'd have a large broadcast domain but should still function.
• Wifi, management, printers etc are all on different VLAN
• Spanning tree has been verified by Cisco TAC & CCNP/CCIE qualified individuals. We shutdown all redundant links.
• Configuration on the core has been verified Cisco TAC.
• We have the default ARP timeout on majority of the switches.
• We do not implement Q & Q.
• No new switches been added (at least none we know of)
• Cannot use dynamic arp inspection on edge switches because these are 2950
• We used show interfaces | inc line|broadcast to figure out where the large number of broadcast coming from, however both Cisco TAC and 2 other engineers(CCNP & CCIE) confirmed this is normal behaviour due to what is happening on the network (as in large number of mac flaps causing the larger broadcast). We verified the STP was functioning correctly on the edge switches.

Symptoms on the network and switches:

• Large number of MAC flaps
• High CPU usage for ARP Input process
• Huge number of ARP packets, rapidly increasing and visible
• Wiresharks shows that 100s of computers are flooding the network with ARP Broadcast
• For test purpose, we put approx 80 desktop machines different vlan, however we tested this and made no visible difference to high cpu or arp input
• Have ran different AV/ malware/ spyware, but no viruses visible on the network.
• sh mac address-table count, shows us approx 750 different mac addresses as expected on vlan 1.

#sh processes cpu sorted | exc 0.00%
CPU utilization for five seconds: 99%/12%; one minute: 99%; five minutes: 99%

 PID Runtime(ms)     Invoked      uSecs   5Sec   1Min   5Min TTY Process
  12   111438973    18587995       5995 44.47% 43.88% 43.96%   0 ARP Input
 174    59541847     5198737      11453 22.39% 23.47% 23.62%   0 Hulc LED Process
 221     7253246     6147816       1179  4.95%  4.25%  4.10%   0 IP Input
  86     5459437     1100349       4961  1.59%  1.47%  1.54%   0 RedEarth Tx Mana
  85     3448684     1453278       2373  1.27%  1.04%  1.07%   0 RedEarth I2C dri

• Ran show mac address-table on different switches and core itself (on the core, for example, plugged by desktop directly, my desktop ), and we can see the several different MAC hardware address being registered to the interface, even though that interface has only one computer attached to this:

 Vlan    Mac Address       Type        Ports
 ----    -----------       --------    -----
    1    001c.c06c.d620    DYNAMIC     Gi1/1/3
    1    001c.c06c.d694    DYNAMIC     Gi1/1/3
    1    001c.c06c.d6ac    DYNAMIC     Gi1/1/3
    1    001c.c06c.d6e3    DYNAMIC     Gi1/1/3
    1    001c.c06c.d78c    DYNAMIC     Gi1/1/3
    1    001c.c06c.d7fc    DYNAMIC     Gi1/1/3

• show platform tcam utilization

 CAM Utilization for ASIC# 0                      Max            Used
                                              Masks/Values    Masks/values

  Unicast mac addresses:                       6364/6364       1165/1165
  IPv4 IGMP groups + multicast routes:         1120/1120          1/1
  IPv4 unicast directly-connected routes:      6144/6144        524/524
  IPv4 unicast indirectly-connected routes:    2048/2048         77/77
  IPv4 policy based routing aces:               452/452          12/12
  IPv4 qos aces:                                512/512          21/21
  IPv4 security aces:                           964/964          45/45

We are now at a stage, where we will require huge amount of downtime to isolate each area at a time unless anyone else has some ideas to identify the source or root cause of this weird and bizarre issue.

Update

Thank you @MikePennington and @RickyBeam for the detailed response. I will try and answer what I can.

• As mentioned, 192.168.0.0/20 is an inherited mess. However, we do intend to split this up in the future but unfortunately this issue occured before we could do this. I personally also agree with majority, whereby the broadcast domain is far too big.
• Using Arpwatch is definitely something we can try but i suspect because several access port is registering mac address even though it doesn't belong to this port, the conclusion of arpwatch may not be useful.
• I completely agree with not being 100% sure finding all redundant links and unknown switches on the network, but as best of our finding, this this is the case until we find further evidence.
• Port security has been looked into, unfortunately management has decided not to use this for various reasons. Common reason is we constantly move computers around (college environment).
• We have used spanning-tree portfast with in conjunction with spanning-tree bpduguard by default on all access ports (desktop machines).
• We do not use switchport nonnegotiate at the moment on access port, but we are not getting any Vlan hopping attack bouncing across multitple Vlans.
• Will give mac-address-table notification a go, and see if we can find any patterns.

"Since you're getting a large number of MAC flaps between switchports, it's hard to find where the offenders are (suppose you find two or three mac addresses that send lots of arps, but the source mac addresses keep flapping between ports)."

• We started on this, picked any one MAC flaps and continued our way through all the core switch to distribution to access switch, but what we found was once again, the access port interface was hogging multiple mac address hence mac flaps; so back to square one.
• Storm-control is something that we did consider, but we fear some off the legitimate packets will be dropped causing further issue.
• Will triple check the VMHost configuration.
• @ytti the unexplainable MAC addresses is behind many access ports rather then an individual. Haven't found any loops on these interfaces. The MAC addresses also exist on other interfaces, which would explain large number of MAC flaps
• @RickyBeam i agree with why hosts are sending so many ARP requests; this is one of the puzzling issue. Rouge wireless bridge is an interesting one that i haven't given thought to, as far as we are aware, wireless is on different VLAN; but rogue will obviously mean it may well be on VLAN1.
• @RickyBeam, i don't really wish to unplug everything as this will cause massive amount of downtime. However this is where it may just be heading. We do have Linux servers but not more then 3.
• @RickyBeam, can you explain DHCP server "in-use" probing?

We (Cisco TAC, CCIEs, CCNP) globally agree that this is not a switch configuration but a host/device is causing the issue.

We have a machine for connecting via Cisco SSL VPN (\\speeder).

i can ping our our speeder on 10.0.0.3:

The routing table on \\speeder shows the multiple IP addresses we have assigned to it:

After connecting with the Cisco AnyConnect VPN client:

we can no longer ping \\speeder:

And while there are new routing entries for the Cisco VPN adapter, no existing routing entries were modified after connection:

It is to be expected that we cannot ping Speeder’s IP address on the Cisco VPN adapter (192.168.199.20) because it is on a different subnet than our network (we are 10.0.x.x 255.255.0.0), i.e.:

C:\Users\ian.AVATOPIA>ping 192.168.199.20
Pinging 192.168.199.20 with 32 bytes of data:
Request timed out.

The problem we are experiencing is that we then cannot ping existing IP addresses on \\speeder:

C:\Users\ian.AVATOPIA>ping 10.0.1.17
Pinging 10.0.1.17 with 32 bytes of data:
Request timed out.

C:\Users\ian.AVATOPIA>ping 10.0.1.22
Pinging 10.0.1.22 with 32 bytes of data:
Request timed out.

C:\Users\ian.AVATOPIA>ping 10.0.1.108
Pinging 10.0.1.108 with 32 bytes of data:
Request timed out.

etc

What’s interesting, and might provide a clue, is that there is one address we can communicate with:

This address we can ping and communicate with:

C:\Users\ian.AVATOPIA>ping 10.0.1.4
Pinging 10.0.1.4 with 32 bytes of data:
Reply from 10.0.1.4: bytes=32 time<1ms TTL=128

What makes this one IP address special? This one IP address has the virtue of being a “main” address:

As opposed the addresses we use, which are “additional” addresses:

To sum up, when the Cisco AnyConnect VPN client connects, it blocks us from all-but-one address associated with the computer.

We need the Cisco Client to stop doing that.

Does anyone know how to make Cisco AnyConnect SSL VPN client stop doing that?

Note: Firepass SSL VPN from F5 Networks does not suffer the same issue.

We've contacted Cisco, and they say that this configuration is not supported.

In our company we have a range of /21 (2048) IPv4 public addresses.

We have a bunch of Cisco routers and servers.

How to get started with IPv6? What can we do to provide internet to our clients with IPv6 compliment as well?

Cisco VPN client (IPsec) does not support 64bit Windows.

Worse, Cisco does not even plan to release a 64-bit version, instead they say that
"For x64 (64-bit) Windows support, you must utilize Cisco's next-generation Cisco AnyConnect VPN Client."

• Cisco VPN Client Introduction
• Cisco VPN Client FAQ

But SSL VPN licences cost extra. For example, most new ASA firewalls come with plenty of IPSec VPN licences but only a few SSL VPN licences.

What alternatives do you have for 64-bit Windows? So far, I know two:

1. 32-bit Cisco VPN Client on a virtual machine
2. NCP Secure Entry Client on 64-bit Windows

Any other suggestions or experiences?