Booches.nl

Passed Exam 642-642 Cisco QoS

During the Cisco Live conference you have to opportunity to take one exam certification for free. I am currently learning for my CCVP certification. I started with exam 642-642 which is all about Quality of Service. I thought to myself: “Lets give it a try!!”.

I was stunned by the passing score of 940 out of 1000. Prior to the exam I thought I would fail, but the exam wasn’t that hard. The virtual configurations and drag-and-drop questions weren’t that bad. While reading some question I was really wondering what a possible good answer should be, but when looking at the answer I often laughed inside. I could exclude a lot of answers only leaving 2 or mostly 1 correct answer to choose from.

This was 20% of the CCVP certification. I will have to decide with topic to do next, choosing from the following:

• 642-436 CVOICE
• 642-426 TUC
• 642-446 CIPT1
• 642-456 CIPT2

I don’t know which to choose next, but that is for later concern….

Troubleshooting EIGRP

To troubleshoot EIGRP you should obvious have a grasp understanding of the specific routing protocol. Of course this doesn’t only apply to the EIGRP routing protocol.

Troubleshooting the EIGRP routing protocol on a Cisco devices is mainly about logging the correct information to a syslog server, the buffer or the console and know what the output of several show commands mean.

Neighbor instability on a router has mostly one of the following reasons:

• Holding time expired;
• Retry limit exceeded;
• Manual changes like route filter changes;
• Unidirectional links;
• Primary / secondary IP address mismatch (EIGRP uses the primary IP address);
• Routes get Stuck-in-Active aka SIA (“Active” means recovering from a change in the network, for example flapping links). Routes can get SIA by the following reasons: bad or congested links, query range is “too long”, excessive redundancy, overloaded router, router memory shortage and so one;

Many problems with EIGRP appear when using external routes, like redistributing a routing protocol like OSPF into EIGRP. The most common cause of this problem is the absence of setting the metrics. Important when using the redistribute command is specifying the metrics with the default-metric <metric> or redistribute <protocol> metric <metric> command.

Black Hole Summary Routing is also a common problem when using EIGRP. Black Hole Summary Routing is caused when manual summary routes are configured.

The picture shows a case of Black Hole Routing. Routers A and B summary the different /24 networks as one /16 network to router X. Suddenly the link between router A and router C gets lost. Because we used summarization between router A and router X, router X isn’t aware of the lost link, so router X keeps sending traffic for network 10.1.1.0/24 to router A and router B ((un)equal cost load-balancing). All traffic send to router A would get lost in the process.

A solution to this problem is connecting routers A and B by using a physical link or creating a GRE tunnel between both, if the physical links isn’t possible.

As mentioned before, troubleshooting the routing protocol can be done by using the correct show, logging and debug commands. Important commands for troubleshooting EIGRP are:

• show ip eigrp neighbors: for checking neighbors, hold timers, uptime, Smooth Round Trip Timer (SRTT) and Retransmit Time Out (RTO);
• show ip eigrp topology active: used for noticing if route is SIA;
• show ip eigrp events: check what EIGRP events are going on;
• RTR(config-router)#eigrp-log-neighbor-changes;
• RTR(config-router)#logging buffered <size>;
• debug eigrp packet hello: showing the processing of hello packets;
• debug eigrp packet terse: shows all EIGRP packet debugging except hellos;
• debug ip eigrp notifications: troubleshooting redistribution by showing what happens between EIGRP and the routing table as routes are redistributed;

Troubleshooting a routing protocol can only be done if you know what the protocol is actually doing. When troubleshooting it is necessary to know the correct way to troubleshoot and start exempting possibilities for the routing problems. Exempting possibilities narrows the scope, which can result in finding the actual problem.

Cisco Firewall Design and Deployment

The session about firewall design and deployment didn’t reveal a lot of new things about the Cisco ASA appliance or FWSM module. The only new thing for me was the possibility to configure a redundant interface for a Cisco ASA appliance. The screen shot below shows the cabling scheme for an implementation with and without interface redundancy.

This interface redundancy makes it possible to connect a ASA to two different physical switches. When the active switch would crash, the second switch would become the active switch.

Important here is to notice that this configuration doesn’t provide load-balancing across two links. The configuration is only for link redundancy.

To configure interface redundancy you can use the configuration snippet shown below.

interface Redundant1
  member-interface GigabitEthernet0/2
  member-interface GigabitEthernet0/1
  no nameif
  no security-level

  no ip address
!
interface Redundant1.4
  vlan 4
  nameif inside
  security-level 100
  ip address 172.16.10.1 255.255.255.0
!
interface Redundant1.10

  vlan 10
  nameif outside
  security-level 0
  ip address 172.16.50.10 255.255.255.0

The configuration of interface redundancy has some caveats as listed below:

• Firewalls have to be configured in Active/Standby mode. No load-balancing or link aggregation is supported;
• Interface redundancy is available on Cisco ASA 5510 and above. The ASA 5505 already has a build in switch and FWSM doesn’t have any physical interfaces;
• Subinterfaces (IEEE 802.1Q) need to be configured on top of the logic redundant interface;

During the session the different modes for the firewalls have been discussed. Normally we only use the Routed Mode, but there are more modes like described below:

• Routed mode: traditional mode of the firewall. Two or more interfaces that separate two or more layer 3 domains;
• Transparent mode: the firewall acts as a bridge and functions mostly at layer 2 of the OSI model (this functions is often used for filtering traffic between two routers who, for example, exchange routing information through a dynamic routing protocol);
• Multi-context: one physical firewall is divided in more virtual firewalls;
• Mixed mode: using routed and transparent firewalls in a virtual environment (NOTE: mixed mode is only supported in FWSM today);

Firewall virtualization using multiple context has some caveats. We, Ictivity consultants, already noticed these caveats during firewall implementations. Firewall virtualization has the following caveats:

• No support for VPN services;
• No support for dynamic routing protocols;
• No way to configure the sharing of CPU usage between contexts;
• No support for multicast routing (multicast bridging is supported);

Especially not supporting VPN services (site-to-site VPN, remote access VPN and SSL VPN) is mostly the most used reason for not using multiple context implementation for the firewall.

Cisco Live – A lot of rude people

I haven’t seen so much rude people in one place during the first day of Cisco Live 2008. I noticed during all the sessions and especially during the general keynote by Cisco’s CEO John Chambers a lot of people left the room, when they noticed that the session was going to an end.

I don’t have a problem with somebody leaving the room half way during a session. But it irritates me when somebody leaves the room in the last minute of a session and doesn’t even leave the room silently. I don’t know what the normal standards for those people are, but my parents learned me to respect somebody speaking in front of a group and listen to him………

Wired 802.1X

The session about wired 802.1X deployment was really interesting. I was stunned about the information I already knew after my testing with MAC Authentication Bypass last week. Of course the speaker had more configuration options when configuring the switch ports.

Important for me to hear where the ways for deploying 802.1X in environments. It isn’t a good idea to just implement 802.1X with some kind of big-bang scenario. Important when implementing 802.1X is choosing the correct identity for authentication and which identity repository you are going to use.

Also good to know is that the actual authentication conversation is between the client and the authentication server using EAP; the switch is an EAP conduit, but aware of what’s going on. In normal 802.1X implementation all traffic is blocked on the port ingress and egress. This can give problems with features like DHCP, BootP, Wake on LAN and so one, like I already posted in my post about MAB.

One thing I learned from the session is using the VLAN name instead of the VLAN ID, when using RADIUS to assign the VLAN. This is because you can have a VLAN with the name Marketing, but the VLAN ID can differ per branch office. The Inaccessible Authentication Bypass feature is also useful for branch offices. IAB assigns the port to a statically configured VLAN when the RADIUS server cannot be reached. After IAB detects that the RADIUS server is online again, it starts authenticating all the ports that weren’t authenticated before.

Summarizing I guess that 802.1X will be the new authentication standard and when implementing 802.1X MAB is a good alternative for non-compliant 802.1X stations.