V5.0 certification guide in May, by Narbik!

Narbik is taking up the helm for the new v5 certification guide, to be released in May 2014.

It will be released in two volumes which can be bought separately, or in a pack together. 

Volume 1 will cover: LAN switching, IP networking, and IGP routing:

Part 1. LAN Switching

1. Switched Networking Basics
2. Virtual LANs and VLAN Trunking
3. Spanning Tree Protocol

Part 2. IP Networking

4. Layer 3 Basics
5. IP Services

Part 3. IP IGP Routing

6. IP Forwarding (Routing)
7. RIPv2 and RIPng
8. EIGRP
9. OSPF v2 and v3
10. ISIS
11. IGP Route Redistribution, Route Summarization, and Default Routing

Volume 2 will cover: BGP, QoS, IP multicast, security, WANs, and MPLS. 

Part 1. IP BGP Routing

1. Fundamentals of BGP Operations

2. BGP Routing Policies

Part 2. QoS

3. Classification and Marking

4. Congestion Management and Avoidance

5. Shaping and Policing

Part 3. Wide-Area Networks

6. Wide Area Networks

Part 4. IP Multicast

7. Introduction to IP Multicast

8. IP Multicast Routing

Part 5. Security

9. Device and Network Security

10. Tunneling Technologies

Part 6. MultiProtocol Label Switching (MPLS)

11. MPLS

Amazon have made this available for preorder now! I'll post more details when they come out...

Buy from Amazon.com

Volume 1
Volume 2
Volumes 1 & 2

Buy from Amazon UK

Volume 1
Volume 2
Volumes 1 & 2

Fun with QinQ tunnels - Part 4: Never trunk a tunnel VLAN

We are back to playing with QinQ tunnels. This time solving a Layer 2 loop issue.

If you recall from part 1 we have had to do a bit of a McGyver and loop a cable in and out of our switch to bring up the tunnel. It worked well in that post, but now it's time to open up the tunnel a bit more and allow more vlans through it.

Our QinQ trunk port is configured as follows:

3750#sh run int fa1/0/1
Building configuration...

Current configuration : 263 bytes
!
interface FastEthernet1/0/1
 description **** QinQ vlan ****
 switchport access vlan 500
 switchport trunk encapsulation dot1q
 switchport mode dot1q-tunnel
 ip access-group 101 in
 no keepalive
 l2protocol-tunnel cdp
 l2protocol-tunnel stp
 no cdp enable
end

And our access port is configure as:

3750#sh run int fa1/0/17
Building configuration...

Current configuration : 177 bytes
!
interface FastEthernet1/0/17
 description **** Cust trunk ****
 switchport trunk encapsulation dot1q
 switchport trunk allowed vlan 4,10,11,61,62,63
 switchport mode trunk
end

So the logical solution to allow all our vlans to communicate over the QinQ would be to change the allowed VLAN list to "all", this should do it, right?

Not so much, and behold the problem when we do this:

3750(config-if)#int fa1/0/17
3750(config-if)#switchport trunk allowed vlan all
3750(config-if)#exit
3750(config)#exit
03:34:26: %PM-4-ERR_DISABLE: l2ptguard error detected on Fa1/0/1, putting Fa1/0/1 in err-disable state
3750#
03:34:27: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/1, changed state to down
03:34:27: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/17, changed state to down
03:34:27: %SYS-5-CONFIG_I: Configured from console by console
03:34:28: %LINK-3-UPDOWN: Interface FastEthernet1/0/1, changed state to down
03:34:28: %LINK-3-UPDOWN: Interface FastEthernet1/0/17, changed state to down
3750#

Immediately we find that our switch detects a layer 2 loop and is error disabled: "%PM-4-ERR_DISABLE: l2ptguard error detected on Fa1/0/1, putting Fa1/0/1 in err-disable state".

This is because we are allowing the QinQ vlan (vlan 500) to be trunked. We can either specify all the vlans we want to allow (1,4,5,6,7, etc etc) or instead we can use the much cleaner way below:

3750(config)#int fa1/0/17
3750(config-if)#switchport trunk allowed vlan ?
  WORD    VLAN IDs of the allowed VLANs when this port is in trunking mode
  add     add VLANs to the current list
  all     all VLANs
  except  all VLANs except the following
  none    no VLANs
  remove  remove VLANs from the current list

3750(config-if)#switchport trunk allowed vlan except 500
3750(config-if)#exit

Using the "except" command we can specify which VLANs we don't want to trunk, and the IOS will trunk everything that's not in the list. So your mileage will vary depending on whether you want to allow or restrict more, but its a cleaner approach for this example.
We have to remember to shut and no shut our QinQ interface to bring up the tunnel:

3750(config)#int fa1/0/1
3750(config-if)#shut
3750(config-if)#no shut
3750(config-if)#exit
3750(config)#exit
03:35:31: %LINK-5-CHANGED: Interface FastEthernet1/0/1, changed state to administratively down
3750#
03:35:33: %SYS-5-CONFIG_I: Configured from console by console
03:35:33: %LINK-3-UPDOWN: Interface FastEthernet1/0/1, changed state to up
03:35:34: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/1, changed state to up
03:35:35: %LINK-3-UPDOWN: Interface FastEthernet1/0/17, changed state to up
03:35:37: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/17, changed state to up

And now we should be able to see the other side of the network (the 3560), which should be listed twice - once for the trunk link between the two (port 48) and again on port 17.

3750#sh cdp neigh
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
                  S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone

Device ID Local Intrfce         Holdtme   Capability    Platform   Port ID
3560      Fas 1/0/17            132            S I      WS-C3560-4Fas 0/17
3560      Fas 1/0/48            143            S I      WS-C3560-4Fas 0/48
3550-B    Fas 1/0/12            138           R S I     WS-C3550-2Fas 0/12
3750#

No more l2ptguard errors!

QoS & The MQC - Part 2: Classification with Class Maps and NBAR

In the previous post we looked briefly at the MQC, and set up a basic QoS mechanism to classify a ping packet. In this post we will look closer at Class Maps, the match commands and classification using NBAR (Network Based Application Recognition).

Packets are classified using the match command, and we have already seen that the list of things we can match is pretty huge, we can match on layer 2 (MAC addresses), layer 3 (IP, Access-lists, or applications), or even match that grey-area between layers, MPLS. If we choose to match by protocol then IOS will use Network Based Application Recognition (NBAR), and lastly we can match absolutely everything, using the any command.

We can have multiple match statements within a class-map, and here we pick up on something from the previous post:

R1(config)#class-map ?
  WORD       class-map name
  match-all  Logical-AND all matching statements under this classmap
  match-any  Logical-OR all matching statements under this classmap
  type       Configure CPL Class Map

We have the ability to match-all and match-any (a logical AND, or a logical OR), for example, we can match http traffic coming from a machine with a source mac-address:

class-map match-all example1
  match protocol http
  match source-address mac 0000.0000.0000

Or we can match traffic that matches either of these two conditions (either http, or coming from the same mac address:

class-map match-any example2
  match protocol http
  match source-address mac 0000.0000.0000

We can also match another class-map when we use the match-all or match-any option.

class-map match-any example3
  match class-map example1
  match dscp af12

With example3 we will match http and a source mac address of 0000.0000.0000 OR if the dscp value is af12. If we omit the match-any or match-all keyword then the default behaviour will be match-all.

We can match up to four CoS and IPP or eight DSCP values in a single command (match cos, match precedence or match dscp respectively).

NBAR

NBAR is pretty cool, we have already used it in this post as whenever we use the match protocol command, this actually employs NBAR. What NBAR actually does is classify packets that would otherwise be hard to classify, such as where an application uses dynamic port numbers. NBAR can look into the packet using deep packet inspection and can match on things like host name, URL or MIME type.

Using this topology we have an HTTP server and a client set up:

From the client we can do a curl request to the http server and see a couple of pages, the default index.html page:

And a couple of pages that we will try and control using NBAR:

On R1 we configure the following:

class-map match-all CLS-DENY-FAIL-HTML
 match protocol http url "/fail.html"
!
policy-map POL-DENY-FAIL-HTML
 class CLS-DENY-FAIL-HTML
   drop
!
interface FastEthernet0/1
 ip address 10.250.1.1 255.255.255.0
 duplex auto
 speed auto
 service-policy input POL-DENY-FAIL-HTML

And if we now test from the client machine we can see that (eventually) the curl requests times out:

But the request to pass.html still works:

With our router configuration placement is key. The same class-map and policy map set on R2 on the same interface in the outgoing direction does not work, and this is because our http server is listening on port 80 (http), but requests from the client will come from an ephemeral port, and therefore will not be matched to the http protocol.

We can make this example a bit more interesting and change the QoS values for the pass and fail pages. We will now set the pass.html page to be classified as CS5, and the fail.html page to be classifed as CS1:

class-map match-all CLS-CS1-FAIL-HTML
 match protocol http url "/fail.html"
class-map match-all CLS-CS5-PASS-HTML
 match protocol http url "/pass.html"
!
policy-map POL-CHANGE-CS-HTML
 class CLS-CS5-PASS-HTML
  set dscp cs5
 class CLS-CS1-FAIL-HTML
  set dscp cs1
!
interface FastEthernet0/1
 ip address 10.250.1.1 255.255.255.0
 duplex auto
 speed auto
 service-policy input POL-CHANGE-CS-HTML

We can now look at the link between R1 and the http server and see that our requests are forwarded to the http server with different DSCP values:

Now if we do another wireshark capture either between the two routers, or between R2 and the client machine we can see that the DSCP value is returned as default - which makes sense because the service-policy is set as "input" on R1 rather than output. We can make sure that the return traffic gets the same DSCP values by specifying the same service-policy on R1 in an output direction, and this way the DSCP value is retained throughout the network.

Wireshark is a great way to confirm that our values are being set as we want them to be! Sadly as I am running a 3600 series router in GNS3 and not a 7200 embedded packet capture is not available. But this would be another way (and something we will cover later on) that would enable us to confirm the DSCP values through traffic capturing.

Why does ASDM access to active firewalls stop?

This really annoys me, and its a pretty common occurrence with ASAs set up in a failover pair. ASDM access will work to the standby member of the pair, but not to the primary. It has worked in the past, but it just stops working.

With the following setup - one PC with the lastest ASDM software installed and two ASA firewalls. Hardly a complex scenario. Well we start off with full ASDM access to both active and standby, but for some reason, after a while, ASDM access works to the standby in the pair, but not to the primary (active).

We can rule out a problem with ASDM, or with Java (because we can get to the standby). We can also rule out a problem with the http server and access rules for such, as the standby member gets its rule base from the primary - we can access the standby so we know that the rules to allow ASDM access are fine.

We can reload the standby, wait for it to come backup, for the configs to resync, and when the two show that all is healthy, perform a failover, and reboot the other (what was the primary but is now the secondary).

This usually works fine, but not always.

If we check the uptime:

We can see that the device uptime is at most 21 minutes, but still, no ASDM access to the active firewall:

SSH access works fine though, and trying to access through a web browser returns "Page cannot be displayed", whereas accessing the standby through a browser brings you into the correct page.

So what is the cause and what is the solution?

From what I have read on the various Google searches it does appear to be cause by uptime exceeding one year. You would have thought that this would apply to device uptime rather than cluster uptime, and I have ASAs in other locations, again in a failover cluster that also exceed cluster uptime of one year and they work fine AFTER doing a reload-standby, failover, reload-standby, but have exhibited the same issue.

It's not version specific as I have seen this in ASA 8.X and 9.X.

Interestingly, running "sh asp table socket" shows that the ASA is listening on the inside interface, and although connections cannot be made on the inside, ASDM from an outside address is still possible. So is it linked to an interface?

Where the full address is blanked out is an external address, where just an octet is blanked out is an internet address. So we can see https (i.e. ASDM) from an outside address still works!

I have tried removing the rules for ASDM access on the Inside and reapplying them, but this still does not work.

If anyone has encountered and fixed this I would love to hear back from you!

CCIE R+S v5.0 Lab exam - full breakdown

There are somethings that really stand out on the new v5.0 Lab exam blueprint, firstly is that there is quite a few mentions of Wireshark, so I would hazard a guess that VIRL/CML connects easily to Wireshark in the same way that IOU/IOL and GNS3 do. RIPv2 gets a very brief mention, but BGP is really ramped up when compared to the v4 blueprint. I am starting to think that RIP might not even make it onto the v6.0 blueprint (yes, you heard it first here, folks), and we also have the new versions of Netflow as well now.

Here is the complete list of things you need to cover for the new v5.0 written exam:

CCIE R+S v5.0 Written exam - full breakdown

The v5.0 Written exam has many changes from the v4.0, if you want to remind yourself what's in the V4 then have a look here. The new exam topic lists make the v4.0 look almost too generic really. If you have been following this blog then hopefully you will have seen that as I cover a topic I am linking it back to a very early post where I listed the v4.0 topics, well it looks like I will have to start linking again, and hopefully as I am now into the fifth month of my studies there wont be too many (completely) new topics!

There are some quite new things, such as IOS XE, ISIS, Wireshark but many are just extensions of topics we should already be covering.

Here is the complete list of things you need to cover for the new v5.0 written exam:

CCIE R+S v5.0 Confirmed - Find out what's new!

Cisco have released details of the new v5.0 blueprint for the CCIE Routing and Switching exams.

Here's a breakdown of what is in the new exam.

Last date of the v4.0

You have until June 3rd 2014 to take the V4 blueprint.

Start date of the v5.0

The v5.0 exams will start on July 4th 2014.

Hardware

As previously thought the lab will be 100% virtualised, though if you want to buy equipment you will need Cisco ISR 2900 series running IOS 15.3T Universal, and Catalyst 3560Xs running 15.0SE universal (IP services).

v5.0 Written exam

The new code for the written exam is 400-101, and is much the same format as before.

It is now broken down into six areas, with the percentage for each topic in brackets:

1.0 Network Principles (10%)
2.0 Layer 2 Technologies (15%)
3.0 Layer 3 Technologies (40%)
4.0 VPN Technologies (15%)
5.0 Infrastructure Security (5%)
6.0 Infrastructure Services (15%)

A full breakdown of the v5.0 Written Exam topics

v5.0 Lab Exam

The lab exam has also been simplified, with now just 5 areas:

1.0 Layer 2 Technologies (20%)
2.0 Layer 3 Technologies (40%)
3.0 VPN Technologies (20%)
4.0 Infrastructure Security (5%)
5.0 Infrastructure Services (15%)

There is a big change to the format of the lab exam, and now it is split into three parts.

Troubleshooting - 2 hours with an optional 30 minutes
Diagnostic - 30 minutes
Configuration - 5 hours 30 minutes with an optional 30 minutes (if you havn't already used it in the troubleshooting)

The diagnostic module is ticket based - similar to the CCNP TSHOOT, whereby you are required to make a choice between pre-defined options and show either where or what the root cause is, or what lead you to this conclusion, or what is missing to make a judgement about the root cause. There will be multiple sources of information such as logs, diagrams and emails - though given some of the "The internet is broken" emails I get, I hope Cisco won't go down to end-user level...

A full breakdown of the v5.0 Lab Exam topics

What's been added, moved or removed

Indications from various sources were pretty spot-on.

The following have been removed:

• Flexlink, ISL, Layer 2 Protocol Tunneling
• Frame-Relay (LFI, FR Traffic Shaping)
• WCCP
• IOS Firewall and IPS
• RITE, RMON
• RGMP
• RSVP QoS, WRR/SRR

The following have been moved from the Lab exam to the new written exam:

• Describe IPv6 Multicast
• Describe RIPv6 (RIPng)
• Describe IPv6 Tunneling Techniques
• Describe Device Security using IOS AAA with TACACS+ and RADIUS
• Describe 802.1x
• Describe Layer 2 QoS
• Identify Performance Routing (PfR)

New topics on the written exam are:

• Describe basic software architecture differences between IOS and IOS XE
• Identify Cisco Express Forwarding Concepts
• Explain General Network Challenges
• Explain IP, TCP and UDP Operations
• Describe Chassis Virtualization and Aggregation Technologies
• Explain PIM Snooping
• Describe WAN Rate-based Ethernet Circuits
• Describe BGP Fast Convergence Features
• ISIS (for IPv4 and IPv6)
• Describe Basic Layer 2 VPN - Wireline
• Describe Basic L2VPN - LAN Services
• Describe GET VPN
• Describe IPv6 Network Address Translation

And finally new topics on the both the written and lab exams:

• Use IOS Troubleshooting Tools
• Apply Troubleshooting Methodologies
• Interpret Packet Capture
• Implement and Troubleshoot Bidirectional Forwarding Detection
• Implement EIGRP (multi-address) Named Mode
• Implement, Troubleshoot and Optimize EIGRP and OSPF Convergence and Scalability
• Implement and Troubleshoot DMVPN (single hub)
• Implement and Troubleshoot IPsec with pre-shared key
• Implement and Troubleshoot IPv6 First Hop Security

As I thought in my previous post on what's probably going to come up in the v5.0 there is a greater emphasis on IPv6. Some older technologies have been removed such as ISL, and Frame-Relay, and other technologies that are more suited to the Security track (WCCP, Firewall and IPS) have also been removed.

The changes do make a lot of sense, certainly as IPv6 adoption increases then the exam-provable skill sets must also increase.

All in all it's not an overly scary change. The current reading list is still pretty valid, even the 4th edition certification guide by Wendell Odom is still very useful, but we would expect the new version to be released in the first half of next year.

I will go through the complete changes to the v5.0 Written and Lab exams in separate posts, so stay tuned!

QoS & The MQC - Part 1: Quick QoS

QoS is a pretty big area on the CCIE exam topic list, it's certainly the largest single topic, IPv4 has 9 different areas, but these are broken down into protocols, so can be considered separate, whereas QoS is all one major topic, and has six sub-topics (but OK, you could argue that these are as separate as EIGRP and OSPF are in IPv4...), anyway, it's a big topic.

QoS isn't something I have done anything with so far, either on this blog or in the workplace, so it's all new to me, as are some other topics I'll need to cover. But let's get started.

QoS is covered by part 8 on the exam list, and 8.10 lists the following:

8.10 Implement Modular QoS CLI (MQC) 
   (a) Network-Based Application Recognition (NBAR) 
   (b) Class-based weighted fair queuing (CBWFQ), modified deficit round robin (MDRR), and low latency queuing (LLQ) 
   (c) Classification 
   (d) Policing 
   (e) Shaping 
   (f) Marking 
   (g) Weighted random early detection (WRED) and random early detection (RED) 
   (h) Compression 

So lets start at the beginning with the MQC

QoS and the MQC

QoS has been around on Cisco devices for ages, there were many different tools, with different commands and configurations, then life was made easier and everything was bundled into the Modular QoS CLI (MQC).  MQC is a method of catgorizing classification, marking, policing and shaping into logical groups. MQC based tools all begin with "Class-Based" - or CB for short - such as Class-Based Weighted Fair Queuing (CBWFQ).

MQC has three components, a class-map (classifies packets into classes), the PHB (Per-Hop Behaviour - or the actions to take) and the policy-map (which is configured on an interface). The interface calls a service-policy which references our policy-map, which in turn calls our class-map:

class-map myclassmap1
  #set match commands
policy-map mypolicymap1
  class myclassmap1
    #actions to take
interface serial 0/0
  service-policy output mypolicymap1

Policy maps can reference multiple class maps, and with that let's take a look at class maps.

MQC Class Maps

Let's start with the class-map command:

R1(config)#class-map ?
  WORD       class-map name
  match-all  Logical-AND all matching statements under this classmap
  match-any  Logical-OR all matching statements under this classmap
  type       Configure CPL Class Map

R1(config)#class-map

We can either specify a class-map name or using one of the match- commands specify whether we are going to use ANDing or ORing. Type gives us the following options:

R1(config)#class-map type ?
  access-control   access-control specific class-map
  control          Configure a control policy class-map
  inspect          Configure Firewall Class Map
  logging          Class map for control-plane packet logging
  multicast-flows  multicast class-maps
  port-filter      Class map for port filter
  queue-threshold  Class map for queue threshold
  stack            class-map for protocol header stack specification
  urlfilter        Config Class map for local URL filtering
  waas             Configure a WAAS Class Map

For the moment we will just look at the first option and give our class-map a name:

R1(config)#class-map MYFIRSTCLASS
R1(config-cmap)#?
Class-map configuration commands:
  description  Class-Map description
  exit         Exit from class-map configuration mode
  match        classification criteria
  no           Negate or set default values of a command

So lets give it a description and start matching some packets. Doing "match ?" shows what you can match:

R1(config-cmap)#match ?
  access-group         Access group
  any                  Any packets
  application          Application to match
  class-map            Class map
  cos                  IEEE 802.1Q/ISL class of service/user priority values
  destination-address  Destination address
  discard-class        Discard behavior identifier
  dscp                 Match DSCP in IPv4 and IPv6 packets
  fr-de                Match on Frame-relay DE bit
  fr-dlci              Match on fr-dlci
  input-interface      Select an input interface to match
  ip                   IP specific values
  metadata             Metadata to match
  mpls                 Multi Protocol Label Switching specific values
  not                  Negate this match result
  packet               Layer 3 Packet length
  precedence           Match Precedence in IPv4 and IPv6 packets
  protocol             Protocol
  qos-group            Qos-group
  source-address       Source address
  vlan                 VLANs to match

We'll start by matching a protocol. If you do "match protocol ?" you will find loads and loads of options (too many to list here), so for the moment lets match icmp:

R1(config)#class-map MYFIRSTCLASS
R1(config-cmap)#description My First Class-Map
R1(config-cmap)#match protocol icmp

Now we need a Policy map so that we can use our class map.

MQC Policy Maps

In order to use our class-map we need a policy map.

R1(config)#policy-map MYFIRSTPOLICY
R1(config-pmap)#?
Policy-map configuration commands:
  class        policy criteria
  description  Policy-Map description
  exit         Exit from policy-map configuration mode
  no           Negate or set default values of a command

R1(config-pmap)#description My First Policy Map
R1(config-pmap)#class MYFIRSTCLASS
R1(config-pmap-c)#?
Policy-map class configuration commands:
  bandwidth        Bandwidth
  compression      Activate Compression
  drop             Drop all packets
  exit             Exit from QoS class action configuration mode
  fair-queue       Enable Flow-based Fair Queuing in this Class
  log              Log IPv4 and ARP packets
  measure          Measure
  netflow-sampler  NetFlow action
  no               Negate or set default values of a command
  police           Police
  priority         Strict Scheduling Priority for this Class
  queue-limit      Queue Max Threshold for Tail Drop
  random-detect    Enable Random Early Detection as drop policy
  service-policy   Configure QoS Service Policy
  set              Set QoS values
  shape            Traffic Shaping
  

So there is a lot we can do with our class-map. We can compress packets, drop them, enable fair-queuing, sample them using netflow, police them and drop depending on how well our network is performing, along with all the other options.

For the moment I want to drop ICMP traffic. To see this in action I have set up two routers, joined by their FastEthernet interfaces using the IP addresses 10.250.1.1 and 10.250.1.2.

R1#ping 10.250.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.250.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/20/25 ms
R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#policy-map MYFIRSTPOLICY
R1(config-pmap)#class MYFIRSTCLASS
R1(config-pmap-c)#drop
R1(config-pmap-c)#exit
R1(config-pmap)#exit
R1(config)#exit
R1#

Now we need to "attach" this policy map to our interface

R1(config)#int f0/0
R1(config-if)#service-policy output MYFIRSTPOLICY
R1(config-if)#exit
R1(config)#exit
R1#

And we can see the before and after effects from the other router:

R2#ping 10.250.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.250.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 10/11/15 ms
R2#ping 10.250.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.250.1.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R2#

So there we have a very basic example. Just dropping traffic isn't really the best usage of QoS - after all it's about improving quality rather than just dropping traffic (unless we are dropping marked traffic in order to improve other traffic - but that's for later). Let's see what we can do to our ping packets instead, and for that we need to know a bit about DSCP classes and values.

DSCP

If we fire up Wireshark and look at a ping packet we can see that in the IPv4 details we have a Differentiated Services Field, and the value is set to 0x00:

But what does this value mean and what's DSCP anyway?

Within an IP header are different byte fields. Originally this included a 1-byte field called the type of Service (ToS) byte - and this was used to mark a packet for QoS. The ToS byte included the IP Precedence field (IPP) and this was numbered from 0 to 7 (as it used the high-order 3 bits):

Name	Decimal Value	Binary Value
Routine	Precedence 0	000
Priority	Precedence 1	001
Immediate	Precedence 2	010
Flash	Precedence 3	011
Flash Override	Precedence 4	100
Critical	Precedence 5	101
Internetwork Control	Precedence 6	110
Network Control	Precedence 7	111

Differentiated Services (DiffServ) then came along and needed three more bits, the ToS byte got renamed to the Differentiated Service (DS) field, and IPP was replaced witha 6-bit field called the Differentiated Services Code Point (DSCP) field. The low-order 2 bits of which is ised for Explicit Congestion Notification (ECN), which you can also see in the Wireshark output above.

There is a lot of commonality between IPP and and DSCP, they are numbered from CS0 (meaning Class Selector) to CS7 and the binary values match those of IPP:

DSCP Class Selector Name	Binary
Default/CS0	000000
CS1	001000
CS2	010000
CS3	011000
CS4	100000
CS5	101000
CS6	110000
CS7	111000

Now if we set our DSCP value to CS4

R1(config)#policy-map MYFIRSTPOLICY
R1(config-pmap)#class MYFIRSTCLASS
R1(config-pmap-c)#set dscp ?
  <0-63>     Differentiated services codepoint value
  af11       Match packets with AF11 dscp (001010)
  af12       Match packets with AF12 dscp (001100)
  af13       Match packets with AF13 dscp (001110)
  af21       Match packets with AF21 dscp (010010)
  af22       Match packets with AF22 dscp (010100)
  af23       Match packets with AF23 dscp (010110)
  af31       Match packets with AF31 dscp (011010)
  af32       Match packets with AF32 dscp (011100)
  af33       Match packets with AF33 dscp (011110)
  af41       Match packets with AF41 dscp (100010)
  af42       Match packets with AF42 dscp (100100)
  af43       Match packets with AF43 dscp (100110)
  cos        Set packet DSCP from L2 COS
  cs1        Match packets with CS1(precedence 1) dscp (001000)
  cs2        Match packets with CS2(precedence 2) dscp (010000)
  cs3        Match packets with CS3(precedence 3) dscp (011000)
  cs4        Match packets with CS4(precedence 4) dscp (100000)
  cs5        Match packets with CS5(precedence 5) dscp (101000)
  cs6        Match packets with CS6(precedence 6) dscp (110000)
  cs7        Match packets with CS7(precedence 7) dscp (111000)
  default    Match packets with default dscp (000000)
  ef         Match packets with EF dscp (101110)
  qos-group  Set packet dscp from QoS Group.

R1(config-pmap-c)#set dscp cs4
R1(config-pmap-c)#exit
R1(config-pmap)#exit
R1(config)#int f0/0
R1(config-if)#serv
R1(config-if)#service-policy out
R1(config-if)#service-policy output MYFIRSTPOLICY
R1(config-if)#

We can then see this in Wireshark:

We have some other options we could have chosen - those beginning with AF, we could have set the DSCP manually (<0-63>) or set ef or qos-group. The AF values are for Assured Forwarding, and ef is for Expedited Forwarding.

Assured Forwarding

Assured Forwarding defines four classes for queuing, and each of these has three levels of "drop probability", allowing for 12 different values or levels. The first number (1-4) is the queue that the packet is in, and the second number (1-3) is its drop probability.

Queue Class	Low Drop Probability	Medium drop Probability	High drop Probability
	Name / Decimal / Binary	Name / Decimal / Binary	Name / Decimal / Binary
1	AF11 / 10 / 001010	AF12 / 12 / 001100	AF13 / 14 / 001110
2	AF21 / 18 / 010010	AF22 / 20 / 010100	AF23 / 22 / 010110
3	AF31 / 26 / 011010	AF32 / 28 / 011100	AF33 / 30 / 011110
4	AF41 / 34 / 100010	AF42 / 36 / 100100	AF43 / 38 / 100110

Expedited Forwarding

Expedited Forwarding (EF) queues packets to that they are scheduled quicker, EF packets are also policed so that they do not starve other queues. The DSCP value in decimal is 46, and the binary value is 101110.

I think this is a good point to end at. So we can let things sink in a bit before moving on to a deeper delve into classification using class-maps.

Month four done, eight to go

Studies are starting to pick up again, mainly because I am trying to push myself a bit more. I have finally finished BGP in the Odom book, and now it's on to QoS. Not the most interesting topic, but then not all every topic will be, you got to take the rough with the smooth really.

I am spending a bit too much time playing with the layour of this blog though. I am sure that this time could be better spent... But it does keep me amused, and I know that I need to do things other than study otherwise I will start to burn out and things won't get learned.

CCIE and home life

My shoulder is much better now, it cost a couple of hundred in chiropractor bills, but all I am left with is a slightly tingly end to one of my fingers, but at least it's not complete agony! I had my 36th birthday as well, and the wife took me to a cabaret club in London (the Wam Bam Club) - we had an excellent night, ended up getting exceedingly drunk and can't remember some parts of getting home, but we did at least make it home.

I have booked some time off in the lead up to and through Christmas, should be able to get some studying some there, I would like to get through QoS and move on to Multicast, not sure if I will go through Frame Relay as I will probably get the V5 when I am taking the exam, and all signs point to the fact that Frame Relay will not appear on the V5 - more details will be released in January so I can always go back to that if it does remain on the new blueprint.

CCIE and work life

Things are quietening down in the build up to Christmas, so am managing to get little snippets done at work. Still ironing out a few Lync "issues" but its business as usual mainly.

The BIG lab - Part 10 - IPv6 filtering

I did plan to finish the BIG lab off with a couple of network services, some IPv6 filtering and some policy routing. However Cisco IOU seems to have an issue with setting up NTP, there are no DHCP client PCs to play with and policy routing is more tuned to QoS than for "general" usage. So we'll focus on IPv6 filtering instead, and save the other topics for separate posts.

IPv6 Filtering.

Recall from part 8 that we nominated the loopback interface on R1 as our "secure network", we then blocked R10 from accessing this network, we start by assigning the IPv6 address of FEC0:0:0:111::1/128 to the loopback interface, and confirm we can see it

R1(config)#int lo0
R1(config-if)#ipv6 address fec0:0:0:111::1/128
R1(config-if)#ipv6 eigrp 100
R1(config-if)#exit
R1(config)#exit
R1#sh ipv6 int bri
Serial0/0                  [up/up]
    unassigned
Serial0/1                  [up/up]
    unassigned
Serial0/2                  [administratively down/down]
    unassigned
Serial0/3                  [administratively down/down]
    unassigned
Multilink1                 [up/up]
    FE80::FF:FE00:1
    FEC0:0:0:110::1
Loopback0                  [up/up]
    FE80::FF:FE00:1
    FEC0:0:0:111::1
R1#

And we confirm that R10 has it in it's routing table:

R10#sh ipv6 route
IPv6 Routing Table - default - 28 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
       B - BGP, M - MIPv6, R - RIP, I1 - ISIS L1
       I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary, D - EIGRP
       EX - EIGRP external, ND - Neighbor Discovery
       O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
       ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
C   FEC0::/64 [0/0]
     via Serial1/0, directly connected
L   FEC0::A8BB:CCFF:FE00:A00/128 [0/0]
     via Serial1/0, receive
O   FEC0:0:0:100::1/128 [110/64]
     via FE80::FF:FE00:8, Serial1/0
O   FEC0:0:0:100::2/128 [110/128]
     via FE80::FF:FE00:8, Serial1/0
OE2 FEC0:0:0:110::1/128 [110/100]
     via FE80::FF:FE00:8, Serial1/0
OE2 FEC0:0:0:110::2/128 [110/100]
     via FE80::FF:FE00:8, Serial1/0
OE2 FEC0:0:0:111::1/128 [110/100]
     via FE80::FF:FE00:8, Serial1/0
OE2 FEC0:0:0:120::1/128 [110/100]
     via FE80::FF:FE00:8, Serial1/0

R10#ping  FEC0:0:0:111::1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FEC0:0:0:111::1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/37/40 ms
R10#

Now that we have the visibility we need, its time to implement our filtering. We will use a distribute list as before (see part 8). But this time it won't go under the EIGRP process as when we set up IPv6 in part 9 we went in the other direction, but the process is the same, but we will set it up on R10 this time:

We start with a prefix-list:

R10#sh run | i prefix
 distribute-list prefix-list deny-111-1 in
ipv6 prefix-list deny-111-1 seq 5 deny FEC0:0:0:111::1/128
ipv6 prefix-list deny-111-1 seq 10 permit ::/0 ge 64

And as we are learning about the route through OSPF External (type 2) then we need to apply it under our OSPF IPv6 process:

ipv6 router ospf 1
 router-id 10.10.10.10
 log-adjacency-changes
 distribute-list prefix-list deny-111-1 in

And now our ipv6 routing table on R10 looks like this:

R10#sh ipv6 route
IPv6 Routing Table - default - 27 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
       B - BGP, M - MIPv6, R - RIP, I1 - ISIS L1
       I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary, D - EIGRP
       EX - EIGRP external, ND - Neighbor Discovery
       O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
       ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
C   FEC0::/64 [0/0]
     via Serial1/0, directly connected
L   FEC0::A8BB:CCFF:FE00:A00/128 [0/0]
     via Serial1/0, receive
O   FEC0:0:0:100::1/128 [110/64]
     via FE80::FF:FE00:8, Serial1/0
O   FEC0:0:0:100::2/128 [110/128]
     via FE80::FF:FE00:8, Serial1/0
OE2 FEC0:0:0:110::1/128 [110/100]
     via FE80::FF:FE00:8, Serial1/0
OE2 FEC0:0:0:110::2/128 [110/100]
     via FE80::FF:FE00:8, Serial1/0
OE2 FEC0:0:0:120::1/128 [110/100]
     via FE80::FF:FE00:8, Serial1/0

The syntax for the permit any statement (seq 10) in our prefix-list is pretty important, without the "ge 64" we won't get any other routes into our routing table.

And there we have a quick way to implement route filtering in IPv6, and with that the end of our big lab series. I hope you have enjoyed it.