Aggregate and Generate

Let’s start with the classic design guideline, the trope that you need overlapping circles. “Make sure they overlap 20%, that’s a proper design.” At least that’s what they say.

The queuestion is, how do you achieve that? How do you know you have the percentage overlap that you need? Ok, maybe we account for dB loss? Well then how do you properly calculate that loss? That’s easy, find a document that gives you the loss over the distance you need, correlate the two. Call it a day! Well…

Well let’s see here, let me put this AP down right here in the hallway.

That’s odd. It’s not a circle. It’s like the hallway reflected the signal down the hall instead of letting it spread evenly.

This is why your wifi isn’t performing as expected. A long enough hallway will require you to place multiple APs in it to get the coverage you need. The instant you have co-channel interference you just reduced your AP count from 2 to 1.

How do we solve for this, so the circles actually behave more like circles? You place the AP in rooms.

This allows your design to reduce the chance of co-channel interference. And allows for you to account for the amount of overlap you need. But look carefully, we still don’t have circles. It’s very critical to find out the dB loss your walls will create, this circle won’t look the same in a different office.

After some quick testing it appears that Juniper originates traffic from the lowest interface and then lowest IP address.

The Rub
Why is it that Juniper allows for multiple addresses but Cisco can only in specific use cases? CEF allows for multiple destinations, even unequal cost load balancing.

Possibilities

Historical

RFC

Other?

Historical
Looking through the mists of time I found this book – “Inside Cisco IOS Software Architecture.”

Unfortunately I don’t have an AGS+ and can only infer from the text it’s possible functions. The Cisco AGS+ used autonomous switching for the line cards. It was very costly in bandwidth and cpu to send a packet to the route processor. From what I can tell, the individual line cards didn’t retain a full copy of the routes. Any packet that arrived that had an unknown destination in the line card had to be passed up to the route processor. After that, the destination could be cached on the line card. The book also mentions that the AGS+ was the basis of the 7000 router and IOS.

Could this have been an early form of control plane protection? Or was it used to prevent from transferring unnecessarily across the low bandwidth bus?

RFC1009
My original theory was that it was based off of the RFC for requirements for an internet gateway. Here is the text in question –

“A different subnet address mask must be configurable for each interface of a given gateway. This will allow a subnetted gateway to connect to two different subnetted networks, or to connect two subnets of the same network with different masks.”

Unless I’m misreading it, it seems a pretty clear definition of what we are running into.

Other?
Is it a combination of the two above or something completely different. I would love to know. Drop me a line! admin at solutions-haven.com

Key Point - The process is straight forward. The server tells the client in the configuration request that the authentication is PAP. Client responds with its username and password. The username and password is authenticated against the local database.

Key Point - The functional difference between PAP and CHAP is that CHAP performs a semi-bidirectional authentication. The server tells the client that the authentication is CHAP. The server during authentication sends its username to the client router. The client router then looks up the password in the database and sends the hash in response with its username. The server then checks the database to confirm.

I recently ran into an issue where I needed to edit Monitors, Pools, and Rules on an F5. I didn’t want to delete each item and recreate. I was able to achieve this by going to into the bigip.conf file and editing it there. This is one way to do it. It’s probably not the fastest way, but it is a way. Check with your local Linux admin for a better way.

SSH into the load balancer.

Run this command – ~ # vi /config/bigip.conf

To enter a command in vi type <SHIFT> + :

Run this command in vi – :%s/<text to search for>/<replacement text>/gc

The new catalyst 3850s are great! They have a ton of features that come in handy. I recently ran into a bit of a conundrum though. The 3850 was bouncing back my ARP requests from the nexus management interface with the 3850’s MAC address. The nexus management interfaces were on the same subnet in the same vlan, that didn’t even span multiple switches.

I’ve changed the IP addresses to protect the innocent. The packets are out of order, just because it was near impossible to collect amount of packets necessary to make it look nice. This is plenty though. The originator is the owner of the eb:81 MAC. So why is the ARP packet coming back to me with the MAC of the 3850(52:99). Turns out it’s a little feature that Cisco has implemented and is very poorly documented as of 09/2013. Here is the response from TAC –

“Please add the following configuration on the interfaces connected to the Nexus switches: ‘nmsp attach suppress’.

IP Device Tracking (IPDT) is globally enabled by default on the 3850. It can only be disabled on a per-interface level. The 3850 uses a feature called Network Mobility Service Protocol (NMSP) which in turn uses IPDT. The cause of the ARP errors is caused by IP Device Tracking. We’ll want to disable NMSP to prevent the 3850 from sending these packets.

Once the configuration is added, please let me know if the Nexus switch still sees these ARP packets.”

If one were to perform a packet capture, one would see that DTP actually transmits the VTP domain between the switches. If the switches cannot agree on the VTP domain, the switch transitions to an access port. If the trunks are already negotiated, the switch takes 300 seconds to timeout to an access port. Which means the trunks will continue to forward traffic properly for the next 5 minutes.

“Version-Dependent Transparent Mode—In VTP version 1, a VTP transparent switch inspects VTP messages for the domain name and version and forwards a message only if the version and domain name match. Although VTP version 2 supports only one domain, a VTP version 2 transparent switch forwards a message only when the domain name matches.”

Make a change to the VTP database and then verify that the Revision number has incremented and has updated across the transparent switch. The transparent switch will not install the update into its vlan database, only pass it along.

Even though the documentation has been corrected in newer version, this doesn’t mean that myth won’t continue to live on. It’s always a good idea to verify what the documentation is saying by setting up a practice lab. Or you may find that certain assumptions are incorrect.

1.(Preferred) Reset the crypto keys and re-initialize the secure store on the device with the error message. The warnings you will get will differ than what I have listed below. You will want to type ‘yes’ to all responses. If the secure store doesn’t initialize, try again. I had a few warnings that I had entered the commands to quickly (seriously.)

#########

WAV01#crypto pki managed-store initializeManaged store key is set successfully, no need to re-init. Are you sure you want to continue(yes/no)? [no]:yesAll certificate/private keys in SSL managed store will be deleted and optimized SSL traffic will be interrupted. Are you sure you want to continue(yes/no)? [no]:yes

WAV01#cms secure-store init

#########

2. This solution should be tried at your own risk. This is the nuke option. You will need to de-register and then re-register the device with the central manger. This should only be done as a last resort.

####WARNING!#####

WAV01#cms deregister

WAV01#config t
WAV01(config)#cms enable

####WARNING!#####

This is like registering the device as brand new. Any location information will be lost, etc.

Depending on the order of operations, you will not see the ARP entry for the respective IP addresses on the respective hosts. If you try to ping from the wireless host first, the entries will most likely show up.

This is partly due to bridging being enabled. Essentially, bridge groups will restrict broadcasts and multicasts. ARP works off of broadcasts. It appears that the access point shouldn’t allow broadcasts through at all.Sources: Bridge Group Configuration

Yet, everything points to the contrary on the network. It looks like you should be able to reach the host on the wireless segment. The switches show the proper layer 2 addresses. The access point doesn’t show the hosts dropping off. You can ping and connect to the host from a different subnet (e.g. 10.0.1.1 /24).

Solution: Enable ARP caching. The access point will reply to ARP requests on behalf of the host.