Capturing iPhone traffic

This walk through will enable you to capture all traffic that ingresses or egresses the device. It will not differentiate between WLAN or Cellular traffic. If you’re on WiFi, no IP traffic should traverse the Cellular network. If you turn Wifi off, you’ll see your data flow over Cellular.

You’ll need :

  • A Mac with a 30pin/Lightning cable
  • An iPhone

Versions tested :

  • Mac OS X 10.11.6
  • iOS 9.3.3

Procedure:-

Install Xcode on Mac OS X – beware, 4GB download.

Install Wireshark on Mac OS X – no need to beware. Not a 4GB download.

Xcode will make the rvictl tool available to you and despite other tutorials using tcpdump, you can actually capture straight into Wireshark from the remote virtual interface that we’ll create.

Attach an iPhone to the Mac with the cable and allow the Mac to be trusted by the iPhone so it appears in iTunes.

Viewing the iPhone summary page in iTunes, the section which includes the Capacity and Phone Number also has the Serial Number. If you click on the words Serial Number, the display rotates through UDID, ECID and Product Type. We want the UDID

Hold Ctrl and click the UDID string which is a stupid long alphanumeric. Choose copy.

Open a terminal window.

In the terminal window, enter rvictl –s with whitespace after the “-s” and hold Ctrl and click the terminal window to then choose “Paste”

The resulting command should look like:

Macbook$ rvictl –s 23cf3b0ce86e059dd87e53b507858abc99c

When finished with the procedure after using either tcpdump or Wireshark, use the -x form.

rvictl

You can then either use tcpdump if you want to simply save the data to a file for review later, or if you’d like the feeling of ‘watching the traffic’ too, fire up Wireshark and capture from the rvi0 interface. Treat Wireshark like you would in any other packet capture situation.

tcpdump syntax to capture to a file called iphone_capture.pcapng would look like this:

tcpdump -n -i rvi0 -w iphone_capture.pcapng

Use Ctrl+C to stop the capture in tcpdump.

When you’re done, simply stop the remote virtual interface as described earlier and disconnect your phone.

Happy capturing!

 

Cisco WLAN Device Disconnects

Problem statement

The issue I’m facing in an 802.1x Cisco Controller based Wireless Network is that 802.1x Wireless Clients are either A. whilst completely static, and sitting at desks, devices are disconnecting and I’m seeing a connectivity drop with DHCP renewal (according to Cisco AnyConnect supplicants) or B. roaming devices are hanging on to AP’s which are nowhere near the closest AP to the client when moving about the building.

Cisco Wireless LAN Controller

In Cisco WLC Release 8.0, Cisco included Optimized Roaming into their Controller code.

Cisco states the following on Optimized Roaming:-

Information About Optimized Roaming

“Optimized roaming resolves the problem of sticky clients that remain associated to access points that are far away and outbound clients that attempt to connect to a Wi-Fi network without having a stable connection. This feature disassociates clients based on the RSSI of the client data packets and data rate. The client is disassociated if the RSSI alarm condition is met and the current data rate of the client is lower than the optimized roaming data rate threshold. You can disable the data rate option so that only RSSI is used for disassociating clients.

Optimized roaming also prevents client association when the client’s RSSI is low. This feature checks the RSSI of the incoming client against the RSSI threshold. This check prevents the clients from connecting to a Wi-Fi network unless the client has a viable connection. In many scenarios, even though clients can hear beacons and connect to a Wi-Fi network, the signal might not be strong enough to support a stable connection.

You can also configure the client coverage reporting interval for a radio by using optimized roaming. The client coverage statistics include data packet RSSIs, Coverage Hole Detection and Mitigation (CHDM) pre-alarm failures, retransmission requests, and current data rates.”

I’m also very interested in getting log events into my SIEM platform to be able to see when disconnect events are happening. I’m currently trying to get clarity from the advanced logging options in the WLC as I’d like quite just those specific events to come through. I’ll update this section when I’m there.

Now, my final configuration will probably not fit your environment, in that we’re dealing with physics here (radio). My environment has it’s own unique physical characteristics. But I hope to share the journey I took to get to the correct balance for my organisation.

To gain an understanding of my particular environment, here’s some detail.

Building

The building in question is 72m x 29m in size. The build is mostly wood, glass and concrete and 70% open plan with two floors and a large atrium space.
The two floors are not discrete in that there’s clear air in two directions from any upper floor seat to the lower floor and vice versa.

Radios

Within the building, there’s 22 internal 3500 series APs which are the focus of our discussion and 8 external 2600 series APs which contribute to the RF characteristics but aren’t a major player for this discussion.
The radio spectrum in question is a 20Mhz wide 5Ghz WLAN based in the UK using all available indoor UK channels:
36,40,44,48,52,56,60,64,100,104,108,112,116,132,136,140

WiFi Nigel does an exceptional job of explaining the constraints of 5Ghz in the UK, here.

Devices

Day to day, there’s anything up to 400 devices across 5 WLANs within the building. The devices we’re focusing on number up to 270 on a single 5Ghz 802.1x enabled WLAN. They are the managed laptop devices.

The devices in my organisation are loaded with Intel® Centrino® Advanced-N 6235 Wi-Fi adapters which have several options for client side ‘Roaming Aggressiveness’.

centrino

A colleague of mine has already changed a couple devices to ‘5’ for Roaming Aggressiveness with no detrimental feedback, so we assume that is safe – for now – on those devices whilst we pay attention to the WLC.

Taking a note of the configuration of both the Laptops and the WLC configuration, I’m starting with the WLC Optimized Roaming configuration and leaving the Laptops on ‘4’ for Roaming Aggressiveness.

The strategy for the changes pan out as follows:-

  1. Enable Optimized Roaming on the WLC without RSSI – 10 sec interval
  2. Review Optimized Roaming change after 2 weeks and consider interval period.
  3. *Repeats* Add/Increase RSSI thresholds

Cisco states “If you configure a low value for the reporting interval, the network can get overloaded with coverage report messages”. I don’t understand how data, sent every 20secs from 30 APs would overload the network which is Gigabit access ports and 10Gig uplinks to the Core.
My with that long suggested timer interval is that if Optimized Roaming only executed disconnects every 1.5mins, that’s a long time for a device to be hanging around on a sub-optimal AP before it re-connects to something useful.

In the interest of only turning one knob at a time, I’m changing the WLC to enable Optimized Roaming allowing RSSI as it’s only metric and ignoring data rates for the time being.

Step 1. Configuring Optimized Roaming without RSSI from the WLC CLI.

*You will need to disable your radios to complete this work!*

config 802.11a disable network
config 802.11b disable network
config advanced 802.11a optimized-roaming enable
config advanced 802.11b optimized-roaming enable
config advanced 802.11a optimized-roaming interval 20
config advanced 802.11b optimized-roaming interval 20
config advanced 802.11a optimized-roaming datarate 0
config advanced 802.11b optimized-roaming datarate 0

config 802.11a enable network
config 802.11b enable network

show advanced 802.11a optimized-roaming
show advanced 802.11a optimized-roaming stats

Unless there’s any immediate negative consequence from enabling these settings, it’s only fair that the configuration is left alone for a reasonable amount of time before moving on with the RSSI modifications.

Two weeks seems like a good start, it enables you to carefully investigate any issues that aren’t global within the environment and confirm if they were real issues or emotional responses to the change.

Step 2. Configure RSSI as a part of Optimized Roaming

*You will need to disable your radios to complete this work!*

config 802.11a disable network
config 802.11b disable network
config advanced 802.11a optimized-roaming datarate 12
config advanced 802.11b optimized-roaming datarate 12
config 802.11a enable network
config 802.11b enable network
show advanced 802.11a optimized-roaming
show advanced 802.11a optimized-roaming stats
 

Step 3. Increase RSSI thresholds in Optimized Roaming

*You will need to disable your radios to complete this work!*

config 802.11a disable network
config 802.11b disable network
config advanced 802.11a optimized-roaming datarate 24
config advanced 802.11b optimized-roaming datarate 24
config 802.11a enable network
config 802.11b enable network
show advanced 802.11a optimized-roaming
show advanced 802.11a optimized-roaming stats
 

Step 4. Increase RSSI thresholds in Optimized Roaming

*You will need to disable your radios to complete this work!*

config 802.11a disable network
config 802.11b disable network
config advanced 802.11a optimized-roaming datarate 36
config advanced 802.11b optimized-roaming datarate 36
config 802.11a enable network
config 802.11b enable network
show advanced 802.11a optimized-roaming
show advanced 802.11a optimized-roaming stats
 

Step 5. Increase RSSI thresholds in Optimized Roaming

*You will need to disable your radios to complete this work!*

config 802.11a disable network
config 802.11b disable network
config advanced 802.11a optimized-roaming datarate 48
config advanced 802.11b optimized-roaming datarate 48
config 802.11a enable network
config 802.11b enable network
show advanced 802.11a optimized-roaming
show advanced 802.11a optimized-roaming stats
 

Step 6. Increase RSSI thresholds in Optimized Roaming

*You will need to disable your radios to complete this work!*

config 802.11a disable network
config 802.11b disable network
config advanced 802.11a optimized-roaming datarate 54
config advanced 802.11b optimized-roaming datarate 54
config 802.11a enable network
config 802.11b enable network
show advanced 802.11a optimized-roaming
show advanced 802.11a optimized-roaming stats

As of 25/11/15 I’m executing Step 1. on the 27/11/15.
I’ll continue to update this post as the process develops.

 

 

 

Quick note on Iperf usage

Iperf commands used for testing a flow. These are unidirectional, as I would advise against using the Server side return flag i.e. when finished flip the commands around and change the IP address.

TCP test – example at 20m (see –b) and the x.x.x.x address should be the servers address:

Client side = iperf -c x.x.x.x –p10000 -i1 -w512k -l512 -t30 –b20m
Server side = iperf -s –p10000 -i1 -w512k

UDP test – example at 20m (see –b) and the x.x.x.x address should be the servers address:

Client side = iperf -c x.x.x.x -u -p10000 -i1 -w512k -l512 -t30 –b20m
Server side = iperf -s -u -p10000 -i1 -w512k

Flags:
-p = the port used for the flow
-c = Assign as client (servers IP address must follow)
-s = Assign as server
-i1 = Print to screen every second
-w512k = Enlarge window size (proven through multiple tests as the best value)
-t30 = Duration of test in seconds
-b20m = 20Mbits bandwidth – can be m = Megabits or K = Kilobits – value can be changed based upon requirement
-u = UDP Mode (without the flag it defaults to TCP)
-l512 = Set the packet length (example is 512, but default is 1470)

You cannot use the vSphere client to edit the settings of virtual machines of version 10 or higher

Image

This was the message that greeted me after upgrading my ESXi Hypervisor with Free license to 5.5.
I’ve applied an Enterprise license to see if there’s a difference to the host license applied and there’s no change to the behaviour.

It seems if you don’t want the hassle of using a CLI to interact with your VM’s on a Hypervisor license, DO NOT UPGRADE THE VIRTUAL HARDWARE OF YOUR VMs to Version 10 hardware. Unless you’re running vCenter of course.

I’m unable to see a way round this to restore the use of the vSphere Client as a tool to modify the settings of the VM, and let’s be clear, all I want to do is change the vSwitch a VM is connected to as my LAB ESXi box is hooked up to four different switches and I move the VM’s around to recreate different scenarios.

I’m gutted. I’ll update if I find anything to help or back myself out of this mess.

Cisco SWITCH Campus VoIP Refresh. Part 3b – QoS Configuration

I can’t believe I’ve had to chop up not just the VoIP refresh section into three parts, but part three into A and B!

It’s surprised me a little and I must have a little more to say on the subject than I thought when I started putting finger to key last night. But, I AM trying to keep this in scope for the SWITCH exam, so we’ll discuss just the req’s for that in this article.

Configuration

First of all, in order to turn on QoS processing on the switch, we need to enable it with the mls qos global command.
This is something that’s easy to overlook as you’ll enter interface commands all day long, without this, they don’t count for anything.

SW3#sh mls qos
QoS is disabled
QoS ip packet dscp rewrite is enabled
SW3#conf t
Enter configuration commands, one per line. End with CNTL/Z.
SW3(config)#mls qos
SW3(config)#do sh mls qos
QoS is enabled
QoS ip packet dscp rewrite is enabled

Notice the result of the first command stating that QoS is disabled.
Then the show command entered shows the processing being turned on globally.

Under your switchport interfaces, there are many things that could be done, but as mentioned previously, keeping a tight scope to the SWITCH exam.

To demonstrate a few things here, I’m going to show that the interface is in default configuration and then apply four different commands, two of which are setting the VLAN id’s for Access and Voice VLANs.

SW3(config-if)#do sh run int fa 0/1
Building configuration...
Current configuration : 33 bytes
!
interface FastEthernet0/1
end
SW3(config-if)#switchport host
switchport mode will be set to access
spanning-tree portfast will be enabled
channel group will be disabled
SW3(config-if)#switchport access vlan 11
SW3(config-if)#switchport voice vlan 22 
SW3(config-if)#auto qos voip trust
SW3(config-if)#do sh run int fa 0/1
Building configuration...
Current configuration : 235 bytes
!
interface FastEthernet0/1
 switchport access vlan 11
 switchport mode access
 switchport voice vlan 22
 srr-queue bandwidth share 10 10 60 20
 priority-queue out 
 mls qos trust cos
 auto qos voip trust 
 spanning-tree portfast
end

So hopefully you can see, from four commands, I received eight lines of configuration.
That’s because the cheeky switchport host command is a macro which sets a port up for an end device, simlarly the auto qos voip trust command is the Auto-QoS command for non-Cisco IP-Phones to be attached to your access interfaces.

From an real world operational standpoint, Auto QoS is pretty much all you need for your access ports, the only thing that I’ll mention is, try and ensure you’re running the same release of IOS on all your particular switch models as QoS maps may be different between releases.

That’s the automatic portion of configuration covered, to just expand a little on manual configuration for the exam…

To configure an IOS switch to trust the markings on traffic entering an interface, use the following:

Switch(config-if)# mls qos trust {dscp | cos}

To configure the switch to trust the traffic markings only if a Cisco phone is connected, use the following:

Switch(config-if)# mls qos trust device cisco-phone

To set a COS value for frames coming from a PC attached to the phone, use the following:

Switch(config-if)# switchport priority extend cos <cos-value>

To verify the QoS parameters on an interface, use the following:

Switch(config-if)# show mls qos interface <interface>

Here we use the last command mentioned to see how the show command interprets the Auto-QoS settings of the commands we used earlier and a second interface which is default, for comparison (no devices are attached at this point).

SW3#sh mls qos interface fa 0/1 
FastEthernet0/1
trust state: trust cos
trust mode: trust cos
trust enabled flag: ena
COS override: dis
default COS: 0
DSCP Mutation Map: Default DSCP Mutation Map
Trust device: none
qos mode: port-based
SW3#sh mls qos interface fa 0/2
FastEthernet0/2
trust state: not trusted
trust mode: not trusted
trust enabled flag: ena
COS override: dis
default COS: 0
DSCP Mutation Map: Default DSCP Mutation Map
Trust device: none
qos mode: port-based

Cisco SWITCH Campus VoIP Refresh. Part 3a – QoS Theory

QoS, a discussion

Now, funny one this. QoS is really important, right? You’ll hear people say QoS enabled network this, gotta have Quality of Service for VoIP/Video solution that, otherwise it’ll fail.

Read this statement and remember… Quality of Service is meant to combat TEMPORARY network congestion.

As a whole, on a switched campus network with 100Mbps access ports and 1Gbps uplinks everywhere, it’s unlikely, though not impossible that you need QoS. QoS will be there to catch you every time you find a link congested. That’s all!

You could just have QoS misconfigured on your switches – like I did once, thanks to a telco provider I may have mentioned in the past. It meant the campus VoIP solution went in, every one did a dance, we thought that we had a VoIP solution running on a QoS enabled network, which was only a half truth. We had a VoIP solution. The QoS wasn’t configured correctly, but no one knew any different – seemingly the telco’s installation engineers didn’t either – till a few years down the line I viewed the configs to find that they were doing diddly squat in terms of prioritisation.

It didn’t really matter though right? We had enough bandwidth so that the devices on the switches could pass data all day and the interfaces never became congested enough for long enough to cause support calls due to quality, and if there were support calls generated, the call quality could probably be put down to one end being a call to a mobile or another external party.

So that’s all well and good if you’re staying on Campus. Instantly, the moment your voice call traffic is going off Campus, the game changes.

For the SWITCH exam, the remainder of this discussion is a little off-piste, we’re not talking about Routers here which but we may be talking about Multi Layer Switch SVI’s which are default gateways for networks and subsequently may need to consider things like global synchronisation and congestion upstream.

IT Management buy links from an ISP/Telco based on the perceived or measured need for the organisation in chunks of Mbps/Gbps because of prohibitive costing of said links. If all WAN links were the same price per Mb as a campus switchport, everyone would choose big link numbers, but they don’t.

So, importantly, these link sizing decisions are all driven or least heavily influenced by the commoditisation [sic] or lack of, Internet and private link bandwidth.

Because link bandwidth isn’t as cheap as your local switchport bandwidth, It’s very unlikely at this point that you’re going to say, right then, 1Gbps VPLS/MPLS links from all our offices please Mr ISP/Telco!
Notice I said MPLS/VPLS. You could buy xMbps/Gbps Internet links, but your traffic in transit will not be treated with any priority, so all the good work that you do as a result of this article will be for nothing the moment it’s traversing the Internet alongside little Billy’s uTorrent traffic for the latest World of WarCraft ISO rip.

So if you’re putting your inter-handset RTP traffic or SIP trunk traffic on a WAN link, to ensure your QoS model is extended to service that traffic in transit, you need to be on some sort of provider VPN, most likely, VPLS or MPLS.
It’s quite feasible to put your traffic out there on the Internet using a Site-to-Site VPN or an tunnelled Handset/Softphone remote worker to Call Server session, but there’s no guarantees, no SLA’s, if the call quality is dodgy or you have call connection issues, you have to learn to get over it. It totally depends on your requirements and expectations.

Cisco SWITCH Campus VoIP Refresh. Part 2 – Voice VLANs

Voice VLANs

Back in the day, folks used to configure trunks out all the access ports in the switch to provide the ability for the IP Phones to push their voice VLAN data up the link along with the downstream access VLAN data from the PC.

This is a bad thing. I won’t go into it here, but those days are gone. You now use Dual VLANs, Voice VLANs, however you want to describe two VLAN’s only being accepted on an access port.

The idea is that ‘default’ compute data traffic is just assigned to the access VLAN configured on that switch port, and all the voice traffic which is sourced from the phone is punched into the voice VLAN that’s been configured on that switch port thanks to some clever CDP/LLDP communication where amongst other things like power negotiation, the switch informs the phone what it needs to do in terms of 802.1q tagging.

Configuration is particularly simple.

Ensure your switchport is an access port and configure a data VLAN which I hope is not VLAN 1.

SW3(config-if)#switchport mode access
SW3(config-if)#switchport access vlan 22
SW3(config-if)#switchport voice vlan ?
  <1-4094>  Vlan for voice traffic
  dot1p     Priority tagged on PVID
  none      Don't tell telephone about voice vlan
  untagged  Untagged on PVID

To set the voice VLAN, specify a VLAN number, this is by FAR the most common configuration use, and it ends there.

Other options are :
The dot1p option tells the phone to set CoS bits in voice packets while using the data VLAN.
The untagged option tells the phone to use the data VLAN without setting any CoS values.
The none option does what it says on the tin.

There is one other voice VLAN command which is a little obscure but seems to be a protection mechanism

SW3(config-if)#switchport voice detect cisco-phone full-duplex

This command can be entered without the full-duplex keyword.
The best description I can find about this command is that it appears if a device wants to communicate on the voice VLAN is has to have drawn PoE from the switch, speak CDP and be full-duplex.
Without the full-duplex keyword, I think it simply must just have to communicate on the voice VLAN and have drawn PoE from the switch, half-duplex is acceptable.
If these criteria aren’t met, the switchport goes into err-disable.
I guess the summary of that command is that you can’t go plugging anything into the port other than a CDP speaking PoE phone on either half or full duplex.

*Update* I haven’t been able to recreate this using an 1130AG Access Point, an ESXi host and a Switch to Switch link as test devices plugged into access ports.
What does happen however is you get a log message

*Mar  1 00:03:59.066: %CPDE-6-DETECT: Cisco IP Phone 7940 detected on FastEthernet0/24 in full duplex mode

Perhaps this is all it is? You can then use this information to track device usage, deployment from your log aggregation systems. Still, not a feature I’m going to lose sleep over.

 

Cisco SWITCH Campus VoIP Refresh. Part 1 – POE

Support for IP Phones is provided by all modern Cisco Catalyst switches.

The normal functions required to support the phones are:

PoE

This review of PoE goes far beyond the knowledge required for SWITCH 642-813

Standards

IEEE 802.3af known as PoE and providing up to 15.4W per port.
IEEE 802.at known as PoE+ able to provide up to 30W per port.

PoE on Switches which carry this feature is usually on by default.
To review your switches interfaces status for power use commands :

SW3#show power inline 
Available:370.0(w) Used:0.0(w) Remaining:370.0(w)
Interface Admin Oper Power Device Class Max
 (Watts) 
--------- ------ ---------- ------- ------------------- ----- ----
Fa0/1 auto off 0.0 n/a n/a 15.4 
Fa0/2 auto off 0.0 n/a n/a 15.4 
Fa0/3 auto off 0.0 n/a n/a 15.4 
Fa0/4 auto off 0.0 n/a n/a 15.4 
Fa0/5 auto off 0.0 n/a n/a 15.4 
<truncated for brevity>

Also to view consumption configuration

SW3#show power inline consumption 
Interface Consumption Admin 
 Configured Consumption (Watts) 
---------- ----------- -------------------
Fa0/1 NO 0.0
Fa0/2 NO 0.0
Fa0/3 NO 0.0
Fa0/4 NO 0.0
Fa0/5 NO 0.0
<truncated for brevity>

You can remove PoE from an interface by using the interface command

SW3(config)#int fa 0/1
SW3(config-if)#power inline never
SW3(config-if)#do sh power inline
Available:370.0(w) Used:0.0(w) Remaining:370.0(w)
Interface Admin Oper Power Device Class Max
 (Watts) 
--------- ------ ---------- ------- ------------------- ----- ----
Fa0/1 off off 0.0 n/a n/a 15.4 
Fa0/2 auto off 0.0 n/a n/a 15.4 
<truncated for brevity>

You can now see that the Fa0/1 interface will never provide power.

When PoE is enabled, the switch senses the real-time power consumption
of the powered device. The switch monitors the real-time power consumption
of the connected powered device; this is called power monitoring or power sensing.
The switch also polices the power usage with the power policing feature.

One option is to limit the power sensing budget globally, or on a per port basis

By using the power inline consumption wattage configuration command,
you can override the default power requirement specified by the IEEE classification.
The difference between what is mandated by the IEEE classification and what is actually
needed by the device is reclaimed into the global power budget for use by additional devices.
You can then extend the switch power budget and use it more effectively.

For example, if the switch budgets 15,400 milliwatts on each PoE port as it does by default (3560/3750),
you can connect only 24 Class 0 powered devices. If your Class 0 device power
requirement is actually 5000 milliwatts, you can set the consumption wattage to
5000 milliwatts and connect up to 48 devices. The total PoE output power available
on a 24-port or 48-port 3560/3750 PoE switch is 370,000 milliwatts.

Globally:

SW3(config)#power inline consumption default 5000
%CAUTION: Misconfiguring the 'power inline consumption/allocation'
 command may cause damage to the switch and void your warranty. Take
 precaution not to oversubscribe the power supply. Refer to documentation.

Strangely, there doesn’t seem to be a show command which you can see that this global command is in effect.
Neither these commands have a different output as a result of this command being configured.

SW3#show power inline 
SW3#show power inline consumption

Whereas, the per interface configuration below shows up in the command

SW3#show power inline consumption 
Interface Consumption Admin 
 Configured Consumption (Watts) 
---------- ----------- -------------------
Fa0/1 NO 0.0
Fa0/2 YES 5.0
Fa0/3 NO 0.0

Per Interface, you can configure your ports as such

SW3(config-if)#power inline consumption 5000 
%CAUTION: Interface Fa0/2: Misconfiguring the 'power inline
 consumption/allocation' command may cause damage to the switch and void
 your warranty. Take precaution not to oversubscribe the power supply.
 It is recommended to enable power policing if the switch supports it.
 Refer to documentation.

As noted in the warning from the above budget modifications, you should enable power policing to prevent drawing so much power that you cause your switch to fail.

You can do this only on a per interface basis, so I’d recommend an interface range command on all your access ports

SW3(config)#interface range fastethernet 0/1 - 48
SW3(config-if-range)#power inline auto max 5000

Cisco Switch Supervisor Redundancy

Non-Stop Forwarding with Stateful Switch Over

Layers 2–4 (MAC addresses, IP Routes and TCP/UDP Sessions) convergence time is enhanced in Cisco 4500 and 6500 series switches by purchasing redundant route processors (RP) and holding them both in the same 4500/6500 chassis using NSF with SSO.

When using SSO with NSF, only one RP is active. The standby RP synchronizes its configuration and dynamic state information (such as CEF, MAC, and FIB tables) with the active RP. When the active RP fails, SSO enables the standby RP to take over immediately. NSF keeps the switch forwarding traffic during the switchover, using the existing route and CEF tables.

The goal of NSF with SSO is to prevent routing adjacencies from resetting, which prevents a routing flap. The switchover to the new RP must be completed before routing timers expire, or the router’s neighbors will tear down their adjacency and routing will be disrupted.
When the new RP is up, the old routes are marked as stale, and the RP asks its routing peers to refresh them. When
routing is converged, it updates the routing and CEF tables on the switch and the linecards.
NSF is supported with EIGRP, OSPF, ISIS, and BGP. An NSF-capable router supports NSF; an NSF-aware router does
not support NSF but understands it and continues forwarding traffic during SSO.

Use NSF with SSO in locations where you do not have a duplicate switch for failover, such as at the user access or Enterprise network edge. Otherwise it can actually cause longer convergence. Routing protocols timers can be tuned very short to provide fast convergence. With SSO, the switchover to the standby RP might not occur before the tuned routing Dead timer expires, and the adjacency would be reset.

Cisco Logging and Syslog

This short guide can help you plan for your device’s logging parameters from point of installation.

So, you probably want to keep more than what’s in the buffer.
Or, if you don’t, you probably want to make the buffer larger so when you do need it, there’s a chance of some context to the fault that drove you there in the first place.

Interacting with the device

First thing.

Stop the logging messages from interrupting your command statements.

line con 0
logging synchronous
line vty 0 4 
logging synchronous

Now you can read the messages without having your commands wrapping in and around them, what level of messages do you want?

If you’re on the console/ssh session of the device, it’s likely you’re there, and you want to see what’s going on.
The default on these two connection types is (7) debugging and you can leave it there.
If you do choose to change them, the commands are simply

logging console <level> 
logging monitor <level>

Now, choose to keep your logs local or on a central syslog server. It’s not hard to understand why as soon as you’ve more than one or two devices, syslog servers are your friend.
So, for those of you who keep it small and only want the device dealing with the logs, here are your choices.

Setting the level of messages that are kept in the buffer, and the size of the buffer which by default it 4096 bytes (4Kb).

logging buffered <level>
logging buffered <4096-2147483647>

For when you’re keeping log messages centrally in a syslog server, here’s your commands.

logging host 1.1.1.1 
logging on

To verify your configuration use

show logging

You are now setup for a situation where you can enjoy being on the console without the logging messages interfering with your commands and you’ve planned how and where you want your log messages kept.