Exploits 2013-2014

So after my post a few days back and cleaning up the blog design I started to think what the heck have I been doing for 5+ years and why haven’t I been writing. Around that time is also when I transitioned roles from being a pre-sales engineer attached to a couple of account managers to a regional overlay for the southeast team focusing on datacenter technologies(NEXUS, UCS, storage, storage switching Virtualization. This also meant a lot more travel before this we would be within a few hours a customer and rarely spent the night in a hotel. Moving to this new role meant covering accounts in Tennessee, Virginia, Georgia, Florida, as well as where some of their other locations were.

At this point I also started working a lot with what we called our National Team who were considered our “experts” in a particular technology. I worked on being able to give our UCS class, our NEXUS class, and our RAD demo so this way we could offload some of these tasks to local guys as we needed to scale.

Some of the highlights for this year were 4 major data center redesigns from 6500 to NEXUS I designed as well as major LAN and VoIP upgrades for other customers networks. Multiple NEXUS and UCS classes as well as RAD demos to help out the national team. Customers ranged from several major banks in the North Carolina area as well as a home improvement company and a television network in Knoxville. There were also Cloupia, Flexpod, Nexus and ACI bootcamps given by the OEMs to bring us up to speed. I also participated in several beta tests for the ASAv and the NEXUS 1000V.

Looking back at my calendar, emails and designs from that year no wonder I had no time. However this was only the beginning

Wireless Guest and Microsoft IAS(radius)

I have always done wireless guest and 802.1x authentication with ACS as all my customers so far have had it. Today I had to configure wireless guest authentication using the IAS server. Very simple but a couple of gotchas.

• First setup your IAS to recieve requests from your Cisco controller. I used this link as a guide. http://articles.techrepublic.com.com/5100-10878_11-6148579.html
• I used the wizard to keep it simple, but you will want to go in and change the service type from framed to login(Figure PPP). Also the article states to leave the EAP methods unchecked in the profile Authentication TAB(Figure QQQ) however I found that IAS would authenticate fine but the user failed authentication. By checking the MSCHAPv2 it worked fine,

Create a new “Radius Client” – This is the IP of your Cisco Controller, I used  ‘Radius Standard’; remember your password you will need it later.

Create a new “Access Policy” – Just start simple  add a “Windows-Group” such as ‘Domain Users’ & “NAS-IP-Address” which is your controllers IP. Remember to change the Service to login instead of framed and check the MSCHAPv2

Now lets configure the controller 

Go to ‘Security’ Tab >

On the side menu ‘RADIUS’ + ‘Authentication’

Enter your IAS (Radius)  IP, password and make sure ‘Server Status’ is enabled; everything else as default i.e. as port ’1812′.

Repeat with ‘Accounting’ under ‘RADIUS’ menu.

Next on the wireless guest SSID Menu;

 Go to tab ‘LAYER 3′ and make sure ‘Layer 3 Security’ = None, ‘Web Policy’ is ticked (ON), ‘Authentication’ radio box is selected and everything else is default.

Next go to ‘AAA SERVERS’ and make sure ‘Authentication Servers’ & ‘Accounting Servers’ = Enabled and ‘Server 1′ drop boxes have servers you created for selection.(The IAS server instance we previously created)

Thats about it. Once the client gets the splash page, they should authenticate against the IAS server fine. Place to check for errors is the IAS logs you setup and on the windows box where the IAS server site. Look in the security event logs for successful authentication. If that is fine it will be either the service type is not login or a authentication type was not checked.

Wireless guest access using a anchor controller in the DMZ

A dedicated controller will be used in the DMZ that will house the authentication page if used, hand out DHCP and forward traffic to the firewall to be natted out to the internet. The guest traffic will ride over the LWAPP tunnel back to the internal controller. Once on the internal controller the traffic is sent over the  EoIP tunnel that is  formed between the internal and DMZ anchor controller.

• The following ports must be opened between the internal controller and the DMZ controller

–UDP 16666 for tunnel control traffic

–UDP 16667 for encrypted traffic

–IP Protocol 97 for user data traffic

–UDP 161 and 162 for SNMP

• The same Guest WLAN must be created on the internal and anchor controllers. Only the anchor controller needs to have the web authentication page configured or uploaded if a custom page is used.
• A interface for the Guest WLAN must be created on the anchor controller. Use a unique ip address on the subnet the DMZ is using and make the default gateway the firewalls DMZ interface. Create a DHCP scope using this subnet and use the DMZ interface as default gateway.
• A interface for the Guest WLAN must be created on the internal controller. Use a unique ip address on the subnet the DMZ is using and make the default gateway the firewalls DMZ interface. Point the DHCP server to Anchor controller IP address.
• On the anchor controller, use the IP address and MAC-address of the internal controller  to create a mobility group
• On the internal use the IP address and MAC-address of the internal controller  to create a mobility group
• Make sure that when you view the mobility group both the control and data path are up. If they are not up the firewall is not permitting the ports specified earlier. Here is how to troubleshoot this;

Running Mobility Ping Tests

Controllers belonging to the same mobility group communicate with each other by controlling information over a well-known UDP port and exchanging data traffic through an Ethernet-over-IP (EoIP) tunnel. Because UDP and EoIP are not reliable transport mechanisms, there is no guarantee that a mobility control packet or data packet will be delivered to a mobility peer. Mobility packets may be lost in transit due to a firewall filtering the UDP port or EoIP packets or due to routing issues.

Controller software release 4.0 or later enables you to test the mobility communication environment by performing mobility ping tests. These tests may be used to validate connectivity between members of a mobility group (including guest controllers). Two ping tests are available:

•Mobility ping over UDP—This test runs over mobility UDP port 16666. It tests whether the mobility control packet can be reached over the management interface.

•Mobility ping over EoIP—This test runs over EoIP. It tests the mobility data traffic over the management interface.

Only one mobility ping test per controller can be run at a given time.

---

Note These ping tests are not Internet Control Message Protocol (ICMP) based. The term “ping” is used to indicate an echo request and an echo reply message.

---

Use these commands to run mobility ping tests using the controller CLI.

1. To test the mobility UDP control packet communication between two controllers, enter this command:

mping mobility_peer_IP_address

The mobility_peer_IP_address parameter must be the IP address of a controller that belongs to a mobility group.

2. To test the mobility EoIP data packet communication between two controllers, enter this command:

eping mobility_peer_IP_address

The mobility_peer_IP_address parameter must be the IP address of a controller that belongs to a mobility group.

3. To troubleshoot your controller for mobility ping, enter these commands:

config logging buffered debugging

show logging

To troubleshoot your controller for mobility ping over UDP, enter this command to display the mobility control packet:

debug mobility handoff enable

---

Note Cisco recommends using an ethereal trace capture when troubleshooting.

• On the Guest WLAN on internal controller, choose the newly created mobility group to anchor the WLAN. This will force the traffic to go over the mobility tunnel to the anchor controller. Once the client associates, they will get a IP address on the DMZ subnet. The client traffic will be forwarded from the internal controller, to the anchor controller over the EoIP tunnel. It will then be sent to the firewall and natted out to the internet.

http://www.cisco.com/en/US/docs/wireless/technology/guest_access/technical/reference/4.1/GAccess_41.html

Wireless QOS

In setting up these controllers for a VoWLAN deployment, QOS has come up.

IEEE 802.11e, IEEE 802.1P, and DSCP Mapping

WLAN data in a Unified Wireless network is tunneled via LWAPP (IP UDP packets). To maintain the QoS classification that has been applied to WLAN frames, a process of mapping classifications to and from DSCP to CoS is required.

For example, when WMM classified traffic is sent by a WLAN client, it has an IEEE 802.1P classification in its frame. The AP needs to translate this classification into a DSCP value for the LWAPP packet carrying the frame to ensure that the packet is treated with the appropriate priority on its way to the WLC. A similar process needs to occur on the WLC for LWAPP packets going to the AP.

A mechanism to classify traffic from non-WMM clients is also required, so that their LWAPP packets can also be given an appropriate DSCP classification by the AP and the WLC.

Figure 2-22 shows a numbered example of the traffic classification flow for a WMM client, an AP, and a WLC.

Figure 2-22 WMM and IEEE 802.1P Relationship

Step 1 A frame with a 802.1p marking and a packet with an IP DSCP marking arrive at the WLC wired interface. The IP DSCP of the packet is used to determine the DSCP of the LWAPP packet leaving the WLC, and the 802.1p value of the frame depends on the QoS translation table ( see Table 2-7), the QoS profile for the WLAN, and the Wired QoS Protocol configured for that QoS profile (Figure 2-16). If the Wired QoS Protocol is configured as “None”, then no 802.1p value is set, but if the protocol is set to 802.1p, then the 802.1p used depends on the translation table capped at a maximum value of 802.1p table value shown in Figure 2-16.

Step 2 The IP DSCP of the LWAPP packet reaching the AP will translate to an 802.11e CoS marking based on Table 2-7.

Step 3 The 802.11e CoS marking of a frame arriving at the AP translates to an LWAPP DSCP value based on Table 2-7, capped at the maximum value for that QoS profile.

Step 4 The DSCP of the packet leaving the WLC will be equal to the DSCP of the packet that left the WLAN client, but the 802.1p value depends on the QoS translation table (Table 2-7), QoS profile for the WLAN, and the Wired QoS Protocol configured for that QoS profile (Figure 2-16). If the Wired QoS Protocol is configured as “None”, then no 802.1p value is set, but if the protocol is set to 802.1p, then the 802.1p used depends on the translation table.

---

The multiple classification mechanisms and client capabilities require multiple strategies:

•LWAPP control frames require prioritization, and LWAPP control frames are marked with a DSCP classification of CS6.

•WMM-enabled clients have the classification of their frames mapped to a corresponding DSCP classification for LWAPP packets to the WLC. This mapping follows the standard IEEE CoS-to-DSCP mapping, with the exception of the changes necessary for QoS baseline compliance. This DSCP value is translated at the WLC to a CoS value on IEEE 802.1Q frames leaving the WLC interfaces.

•Non-WMM clients have the DSCP of their LWAPP tunnel set to match the default QoS profile for that WLAN. For example, the QoS profile for a WLAN supporting Cisco Unified Wireless IP Phone 7920s would be set to platinum, resulting in a DSCP classification of EF for data frames packets from that AP WLAN.

•LWAPP data packets from the WLC have a DSCP classification that is determined by the DSCP of the wired data packets sent to the WLC. The IEEE 80211.e classification used when sending frames from the AP to a WMM client is determined by the AP table converting DSCP to WMM classifications.

---

Note The WMM classification used for traffic from the AP to the WLAN client is based on the DSCP value of the LWAPP packet, and not the DSCP value of the contained IP packet. Therefore, it is critical that an end-to-end QoS system is in place.

So for QOS to work properly, DSCP must be trusted on the access point switch ports, while COS must be trusted on the WLC ports.

AP Switch Configuration

The QoS configuration of the AP switch is relatively trivial because the switch must trust the DSCP of the LWAPP packets that are passed to it from the AP. There is no CoS marking on the LWAPP frames coming from the AP. The following is an example of this configuration.

---

Note This configuration addresses only the classification, and that queueing commands may be added, depending on local QoS policy.

---

interface GigabitEthernet1/0/1

 switchport access vlan 100

 switchport mode access

 mls qos trust dscp

 spanning-tree portfast

end

In trusting the AP DSCP values, the access switch is simply trusting the policy set for that AP by the WLC. The maximum DSCP value assigned to client traffic is based on the QoS policy applied to the WLANs on that AP.

WLC Switch Configuration

The QoS classification decision at the WLC-connected switch is a bit more complicated than at the AP-connected switch, because the choice can be to either trust the DSCP or the CoS of traffic coming from the WLC. In this decision there are a number of points to consider:

•Traffic leaving the WLC can be either upstream (to the WLC or network) or downstream (to the AP and WLAN clients). The downstream traffic is LWAPP encapsulated, and the upstream traffic is from AP and WLAN clients, either LWAPP encapsulated or decapsulated WLAN client traffic, leaving the WLC.

•DSCP values of LWAPP packets are controlled by the QoS policies on the WLC; the DSCP values set on the WLAN client traffic encapsulated by the LWAPP tunnel header has not been altered from those set by the WLAN client.

•CoS values of frames leaving the WLC are set by the WLC QoS policies, regardless of whether they are upstream, downstream, encapsulated, or decapsulated.

The following example illustrates choosing to trust the CoS of settings of the WLC. This allows a central location for the management of WLAN QoS, rather than having to manage the WLC configuration and an additional policy at the WLC switch connection. Other customers, intending to have a more precise degree of control, might implement QoS classification policies on the WLAN-client VLANs.

interface GigabitEthernet1/0/13

 switchport trunk encapsulation dot1q

 switchport trunk allowed vlan 11-13,60,61

 switchport mode trunk

 mls qos trust cos

end

Wireless install

Just finishing up a wireless install with a pair of 5508’s and WCS. The customer has 4400’s and wanted to go to the 5508’s to gain the added AP count. Very easy migration, we stood up the controllers, and stood up and new version of WCS. We then added the new and old controllers to WCS. Finally we just changed the primary and secondary controller on the AP to the new ones and reload the AP’s. Imported the new maps and placed and everything is good. Set all the parameters for VoWLAN as per the 7925 deployment guide http://www.cisco.com/en/US/docs/voice_ip_comm/cuipph/7925g/7_0/english/deployment/guide/7925dply.pdf

Setup all the QOS on the access layer switches as well as 6500.

One thing we ran into and that’s RRM. In one of the networkers sessions, the speaker said that the newer code runs the RRM algorithm for 100 minutes. If you are doing a new deployment, he advised to reboot the controller so it would run again with all the AP’s associated. We did that, and we wanted the 01 controller to be RRM group leader. We reloaded him first, the 02 took over for all AP’s and became the group leader. We brought 01 back up and shut 02 off and 01 was the group leader with all AP’s. However when 02 came back online it became the group leader for RRM. We wanted 01 but there is no way to configure this. Weird this was before all this reloading 01 was the group leader for RRM. Here is a great link that describes RRM I learned a lot from it.http://www.cisco.com/en/US/tech/tk722/tk809/technologies_tech_note09186a008072c759.shtml

Why the title

I tried to come up with something that describes what I work with on a daily basis. Basically I am a network engineer and I deal with taking data from one computer, putting it on a wire and sending it to another computer. If you break it down everything on a computer is based in binary(0’s and 1’s) bits. You take these bits off a hard drive, the OS does its thing and these bits are converted to binary electrical impulses(0’s and 1’s) and sent across the wire to the other computer. So basically these binary bits are taking a journey from one computer to another.

Forgetfulness

So the reason I started doing a blog is I am forgetting a lot of what I do on a daily basis and what I have done in the past. Hopefully in all this writing I can document all the cool things I have done with my life and hopefully help some people with all the mistakes I have made. So welcome to my blog hopefully I can help someone out. Please feel free to contact me and if anything that I blog about is incorrect feel free to tell me about it I try my best to put good information and experiences.