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.

CCIE R+S V5 - DMVPN

So with the news about the change from the CCIE Routing and Switching V4 blueprint to the V5 many (i.e. some good sources) reckon that DMVPN will be on the new V5 blueprint.

What is DMVPN?

DMVPN stands for Dynamic Multipoint Virtual Private Network, what it does is allow multiple IPSec VPN connections with just one tunnel configuration, so for a site with one central "hub" and three other sites (or "spokes") instead of having three separate VPN configurations there is just one - it does mean that the traffic say from spoke1 to spoke3 needs to go through the hub, but from a configuration standpoint, life is much easier.

DMVPN is based on GRE (and we have covered GRE tunnels before, or mGRE if we are doing spoke-to-spoke tunnels), NHRP (next-hop resolution protocol) and IPSec (because VPN tunnels should be secure). DMVPN also requires a dynamic routing protocol, and CEF (Cisco Express Forwarding).

When it comes to the routing protocol to use within the tunnel EIGRP is preferred because it is an advanced distance vector protocol, better suited to the NBMA network that is built when using DMVPN.

DMVPN can be configured as Hub-and-Spoke or (using mGRE) Spoke-to-Spoke.

Consider the following topology:

We have a central site (called "Hub") and three different spoke at the bottom. In the middle is the cloud, which can be frame-relay or any other method of providing a connection between the hub and the spoke routers.

From the viewpoint of the routers, with our DMVPN in place, they will see the 10.10.1.0/24 network:

We start of with a basic configuration to provide connectivity:

Hub:

hostname Hub
!
interface Serial0/0
 ip address 10.25.1.2 255.255.255.0
!
ip route 10.35.1.0 255.255.255.0 10.25.1.1
ip route 10.45.1.0 255.255.255.0 10.25.1.1
ip route 10.55.1.0 255.255.255.0 10.25.1.1

Cloud:

hostname Cloud
!
interface Serial0/0
 ip address 10.25.1.1 255.255.255.0
!
interface Serial0/1
 ip address 10.35.1.1 255.255.255.0
!
interface Serial0/2
 ip address 10.45.1.1 255.255.255.0
!
interface Serial0/3
 ip address 10.55.1.1 255.255.255.0

Spoke1

hostname Spoke1
!
interface Loopback0
 ip address 10.50.1.1 255.255.255.0
!
interface Serial0/0
 ip address 10.35.1.2 255.255.255.0
!
ip route 10.25.1.2 255.255.255.255 10.35.1.1

Spoke 2

hostname Spoke2
!
interface Loopback0
 ip address 10.60.1.1 255.255.255.0
!
interface Serial0/0
 ip address 10.45.1.2 255.255.255.0
!
ip route 10.25.1.2 255.255.255.255 10.45.1.1

Spoke3

hostname Spoke3
!
interface Loopback0
 ip address 10.70.1.1 255.255.255.0
!
interface Serial0/0
 ip address 10.55.1.2 255.255.255.0
!
ip route 10.25.1.2 255.255.255.255 10.55.1.1

So you can see that we are starting off easy, with just basic connectivity from the Hub to each of the Spokes using the cloud to pass the traffic through. At this stage none of the spoke have any knowledge of each other.

DMVPN Tunnel configuration

The tunnel configuration is much like a standard GRE tunnel but with a couple of additional commands.

The Hub is where everything points to, and we associate the tunnel with a network-id (this is the NBMA identifier), setting the mode as gre multipoint. The spokes map the tunnel IP set on the Hub (10.10.1.1) to the external IP address of the Hub (10.25.1.2), and set this as the next-hop-server (ip nhrp nhs 10.10.1.1).

Hub tunnel:

interface Tunnel0
 ip address 10.10.1.1 255.255.255.0
 no ip redirects
 ip mtu 1416
 no ip next-hop-self eigrp 1
 ip nhrp map multicast dynamic
 ip nhrp network-id 1
 no ip split-horizon eigrp 1
 tunnel source 10.25.1.2
 tunnel mode gre multipoint

Spoke 1 tunnel:

interface Tunnel0
 ip address 10.10.1.2 255.255.255.0
 no ip redirects
 ip mtu 1416
 no ip next-hop-self eigrp 1
 ip nhrp map 10.10.1.1 10.25.1.2
 ip nhrp map multicast 10.25.1.2
 ip nhrp network-id 1
 no ip split-horizon eigrp 1
 ip nhrp nhs 10.10.1.1
 tunnel source 10.35.1.2
 tunnel mode gre multipoint

Spoke 2 tunnel

interface Tunnel0
 ip address 10.10.1.3 255.255.255.0
 no ip redirects
 ip mtu 1416
 no ip next-hop-self eigrp 1
 ip nhrp map 10.10.1.1 10.25.1.2
 ip nhrp map multicast 10.25.1.2
 ip nhrp network-id 1
 no ip split-horizon eigrp 1
 ip nhrp nhs 10.10.1.1
 tunnel source 10.45.1.2
 tunnel mode gre multipoint

Spoke 3 tunnel:

interface Tunnel0
 ip address 10.10.1.4 255.255.255.0
 no ip redirects
 ip mtu 1416
 no ip next-hop-self eigrp 1
 ip nhrp map 10.10.1.1 10.25.1.2
 ip nhrp map multicast 10.25.1.2
 ip nhrp network-id 1
 no ip split-horizon eigrp 1
 ip nhrp nhs 10.10.1.1
 tunnel source 10.55.1.2
 tunnel mode gre multipoint

We can check that our DMVPN tunnel is working using the "sh dmvpn" command:

Hub#sh dmvpn | beg Interface

Interface: Tunnel0, IPv4 NHRP Details
Type:Hub, NHRP Peers:3,

 # Ent Peer NBMA Addr  Peer Tunnel Add State UpDn Tm  Attrb
 ----- --------------- --------------- ----- -------- -----
   1   10.35.1.2       10.10.1.2       UP    00:06:19  D
   1   10.45.1.2       10.10.1.3       UP    00:05:06  D
   1   10.55.1.2       10.10.1.4       UP    00:04:28  D

We can also use basic ping tests:

Hub#ping 10.10.1.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/20/20 ms
Hub#ping 10.10.1.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.1.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/20/24 ms
Hub#ping 10.10.1.4

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.1.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/20/20 ms

Adding IPSec to DMVPN

One of the requirements of DMVPN is IPSec, and this is quite easy to add, the same configuration can go on the Hub and the three spokes.The major thing to point out is that we associate the "dmvpn123" key with any IP address by using the 0.0.0.0 0.0.0.0 address and subnet.

crypto isakmp policy 10
 encryption 3des
 hash md5
 authentication pre-share
crypto isakmp key dmvpn123 address 0.0.0.0 0.0.0.0
!
!
crypto ipsec transform-set MyIPSEC esp-3des
!
crypto ipsec profile DMVPN
 set transform-set MyIPSEC
!
interface Tunnel0
 tunnel protection ipsec profile DMVPN

Adding EIGRP to DMVPN

DMVPNs require a routing protocol within the tunnel (otherwise they would be rather useless), and this is a simple case of adding one!

Hub#sh run | beg router
router eigrp 1 
 network 10.0.0.0
 no auto-summary

Spoke1#sh run | beg router
router eigrp 1
 network 10.0.0.0
 no auto-summary

Spoke2#sh run | beg router
router eigrp 1
 network 10.0.0.0
 no auto-summary

Spoke3#sh run | beg router
router eigrp 1
 network 10.0.0.0
 no auto-summary

Bringing all of DMVPN together

With all of the nuits and bolts in place now we should have some good visilibilty between our spoke routers. We should see routers learned through EIGRP (indicated with a "D") and be able to ping to the loop back addresses that we configured at the start.

 
Spoke1#sh ip route | beg Gateway
Gateway of last resort is not set

   10.0.0.0/8 is variably subnetted, 10 subnets, 2 masks
C    10.10.1.0/24 is directly connected, Tunnel0
L    10.10.1.2/32 is directly connected, Tunnel0
D    10.25.1.0/24 [90/27392000] via 10.10.1.1, 00:09:46, Tunnel0
S    10.25.1.2/32 [1/0] via 10.35.1.1
C    10.35.1.0/24 is directly connected, Serial0/0
L    10.35.1.2/32 is directly connected, Serial0/0
C    10.50.1.0/24 is directly connected, Loopback0
L    10.50.1.1/32 is directly connected, Loopback0
D    10.60.1.0/24 [90/28288000] via 10.10.1.3, 00:08:06, Tunnel0
D    10.70.1.0/24 [90/28288000] via 10.10.1.4, 00:07:02, Tunnel0
Spoke1#sh dmvpn | beg Interface
Interface: Tunnel0, IPv4 NHRP Details
Type:Spoke, NHRP Peers:1,

 # Ent Peer NBMA Addr  Peer Tunnel Add State UpDn Tm  Attrb
 ----- --------------- --------------- ----- -------- -----
   3   10.25.1.2       10.10.1.1       UP    00:34:25 S
                       10.10.1.3       UP    00:02:07 D
                       10.10.1.4       UP    00:02:11 D
Spoke1#ping 10.70.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.70.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 40/43/48 ms
Spoke1#ping 10.60.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.60.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 40/44/48 ms
Spoke1#

Hub-and-spoke or Spoke-to-Spoke?

Depending on the requirements you can either setup a hub-to-spoke or spoke-to-spoke topology. We have been using spoke-to-spoke through this, we can see this using the command "sh ip nhrp", because tunnels will drop if there is no traffic (apart from the one to the hub) we can see what NHRP believes to be the next hop for the end-point - so with the tunnel from Spoke1 to Spoke3 down we can issue a ping and see the tunnel come back up again - also showing the tunnel is a spoke-to-spoke.

Spoke1#sh ip nhrp
10.10.1.1/32 via 10.10.1.1
   Tunnel0 created 01:15:40, never expire 
   Type: static, Flags: used 
   NBMA address: 10.25.1.2 
Spoke1#ping 10.70.1.1      

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.70.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 40/40/40 ms
Spoke1#sh ip nhrp    
10.10.1.1/32 via 10.10.1.1
   Tunnel0 created 01:15:47, never expire 
   Type: static, Flags: used 
   NBMA address: 10.25.1.2 
10.10.1.4/32 via 10.10.1.4
   Tunnel0 created 00:00:01, expire 00:03:03
   Type: dynamic, Flags: temporary
   NBMA address: 10.25.1.2 
Spoke1#

We can, should we wish make it a true hub-to-spoke topology with adding the line "ip nhrp server-only" to the spokes

With our configuration before we can see that the tunnel to the Hub always remains up. We can ping Spoke3 and confirm that another tunnel is created:

Spoke2#sh dmvpn | beg Interface
Interface: Tunnel0, IPv4 NHRP Details
Type:Spoke, NHRP Peers:1,

 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
     1       10.25.1.2       10.10.1.1    UP 00:01:18     S

Spoke2#ping 10.70.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.70.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 40/43/48 ms
Spoke2#sh dmvpn | beg Interface
Interface: Tunnel0, IPv4 NHRP Details
Type:Spoke, NHRP Peers:1,

 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
     2       10.25.1.2       10.10.1.1    UP 00:01:28     S
                             10.10.1.4    UP 00:00:03     D

If we then go into the interface and add the "ip nhrp server-only" command we can confirm that we still have reachability to Spoke3, but only have one tunnel:

Spoke2(config)#int tunnel 0
Spoke2(config-if)#ip nhrp server-only
Spoke2(config-if)#exit
Spoke2(config)#exit
Spoke2#sh dmvp | beg Interface
Interface: Tunnel0, IPv4 NHRP Details
Type:Spoke, NHRP Peers:1,

 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
     1       10.25.1.2       10.10.1.1    UP 00:02:24     S

Spoke2#ping 10.70.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.70.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 40/42/48 ms
Spoke2#sh dmvp | beg Interface
Interface: Tunnel0, IPv4 NHRP Details
Type:Spoke, NHRP Peers:1,

 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
     1       10.25.1.2       10.10.1.1    UP 00:02:31     S

There are some more commands we can use to confirm that our tunnels are looking how they should:

Spoke2#sh ip nhrp
10.10.1.1/32 via 10.10.1.1
   Tunnel0 created 00:14:31, never expire
   Type: static, Flags: used
   NBMA address: 10.25.1.2
Spoke2#sh ip cef 10.70.1.0
10.70.1.0/24
  nexthop 10.10.1.4 Tunnel0

So we have full reachability between the spokes! Pretty neat, and so much easier than creating three different VPNs on each router! It is pretty simple really, if you have created a GRE tunnel before then really we are only looking at a couple of extra lines - and these extra few lines can be copied from one spoke router and pasted onto every other spoke router because they are identical!

The BIG lab - Part 9 - IPv6

Now its time to throw some IPv6 over the top of our network. So far our IPv4 topology has been OSPF on the left hand side, RIP in the middle and EIGRP on the right hand side, but let's make things more interesting and go in the opposite direction, and once we have our three separate IPv6 routing processes in place we will do a complete redistribution between the protocols and set up an IPv6 tunnel. In the end we should have full reachability from end to end.

Our IPv4 topology looks like this:

And our IPv6 topology will look like this:

Excuse the drawings, I am not an artist!

Basic IPv6 configuration

By default IPv6 is not enabled on Cisco routers, to enable it we need to run the command

R10(config)#ipv6 unicast-routing

And then enable IPv6 on the interface:

R10(config)#int s1/0
R10(config-if)#ipv6 enable
R10(config-if)#exit

To confirm that IPv6 is running on the interface we then use the command

R10#sh ipv6 interface serial 1/0
Serial1/0 is up, line protocol is up
 IPv6 is enabled, link-local address is FE80::A8BB:CCFF:FE00:A00 
 No Virtual link-local address(es):
 No global unicast address is configured

We can see that R10's s1/0 interface has the link-local IPv6 address FE80::A8BB:CCFF:FE00:A00.

Let's now enable IPv6 on R8, and see if we can ping across to R10

R8(config)#ipv6 unicast-routing
R8(config)#int s0/2
R8(config-if)#ipv6 enable
R8(config-if)#exit
R8(config)#exit
R8#sh ipv6 int serial 0/2
Serial0/2 is up, line protocol is up
 IPv6 is enabled, link-local address is FE80::FF:FE00:8
 No Virtual link-local address(es):
 No global unicast address is configured
 Joined group address(es):
  FF02::1
  FF02::2
  FF02::1:FF00:8
R8#ping ipv6 fe80::a8bb:ccff:fe00:a00
Output Interface: Serial0/2
Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to FE80::A8BB:CCFF:FE00:A00, timeout is 2 seconds:
Packet sent with a source address of FE80::FF:FE00:8%Serial0/2
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/9/12 ms
R8#

OK, so far so good, and after a few minutes I have added the same commands to R4, R5, and R9, as well as enabling the other interfaces on R8, now we can get on and start configuring OSPFv3.

IPv6 OSPFv3

R10#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R10(config)#ipv6 router ospf 1
R10(config-rtr)#router-id 10.10.10.10
R10(config-rtr)#interface Serial1/0
R10(config-if)#ipv6 ospf 1 area 0
R10(config-if)#ipv6 router ospf 1
R10(config-rtr)#
*Nov 26 10:14:35.227: %OSPFv3-5-ADJCHG: Process 1, Nbr 8.8.8.8 on Serial1/0 from LOADING to FULL, Loading Done
R10(config-rtr)#

R8#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R8(config)#ipv6 router ospf 1
R8(config-rtr)#router-id 8.8.8.8
R8(config-rtr)#int serial 0/2
R8(config-if)#ipv6 ospf 1 area 0
R8(config-if)#
*Nov 26 10:14:35.258: %OSPFv3-5-ADJCHG: Process 1, Nbr 10.10.10.10 on Serial0/2 from LOADING to FULL, Loading Done
R8(config-if)#

With the other routers added in the same way we should be able to see something like:

R10#sh ipv6 ospf database
      OSPFv3 Router with ID (10.10.10.10) (Process ID 1)
      Router Link States (Area 0)
ADV Router   Age    Seq#    Fragment ID Link count Bits
 4.4.4.4     91     0x80000001 0        1 None
 5.5.5.5     31     0x80000002 0        1 None
 8.8.8.8     90     0x80000003 0        3 None
 9.9.9.9     31     0x80000003 0        2 None
 10.10.10.10 286    0x80000002 0        1 None

     Link (Type-8) Link States (Area 0)
ADV Router   Age    Seq#       Link ID  Interface
 8.8.8.8     287    0x80000001 5        Se1/0
 10.10.10.10 334    0x80000001 7        Se1/0

This in itself is not enough to get our routers talking to each other properly, if we try to ping from R10 to R4 we see the following:

R10#ping ipv6 FE80::FF:FE00:4
Output Interface: Serial1/0
Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to FE80::FF:FE00:4, timeout is 2 seconds:
Packet sent with a source address of FE80::A8BB:CCFF:FE00:A00%Serial1/0
HHHHH
Success rate is 0 percent (0/5)

What we need to do is configure a site-local IPv6 address, and we can do that with the command:

R10(config)#ipv6 address
R10(config)#int serial 1/0
R10(config-if)#ipv6 address FEc0::/64 eui-64

And we can do the same on the connecting interface on R8, but we cant use the same command on the interface on R8 that connects to R4, as we get an error about overlap. So instead we will use:

R8(config-if)#int serial 0/0
R8(config-if)#ipv6 address FEC0:0:0:100::1/128

And on R4 we will use

R4(config)#int s0/2
R4(config-if)#ipv6 address FEC0:0:0:100::2/128

Now can R10 ping R4?

R10#sh ipv6 route
IPv6 Routing Table - default - 5 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
L  FF00::/8 [0/0]
   via Null0, receive
R10#ping ipv6 FEC0:0:0:100::2

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

It sure can and we know that it has learnt the address through OSPFv3. Once we add site-local addresses to the other connections using increments in the address (FEC0:0:0:200::2/128, FEC0:0:0:300::2/128 etc) we now have a full topology within our IPv6 OSPFv3 network:

R10#sh ipv6 route
IPv6 Routing Table - default - 9 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
O  FEC0:0:0:200::1/128 [110/64]
   via FE80::FF:FE00:8, Serial1/0
O  FEC0:0:0:200::2/128 [110/128]
   via FE80::FF:FE00:8, Serial1/0
O  FEC0:0:0:300::1/128 [110/128]
   via FE80::FF:FE00:8, Serial1/0
O  FEC0:0:0:300::2/128 [110/1690]
   via FE80::FF:FE00:8, Serial1/0
L  FF00::/8 [0/0]
   via Null0, receive

And one last ping to confirm reachability:

R10#ping ipv6 FEC0:0:0:300::2

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

IPv6 RIPng

Let's create our IPv6 RIPng process, this time around we will add our site-local addresses first:

The commands are similar to how we set up OSPFv3:

R7#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R7(config)#ipv6 router rip v6RIP
R7(config-rtr)#int s0/1
R7(config-if)#ipv6 rip v6RIP enable
R7(config-if)#
R7#
*Nov 26 11:29:56.565: %SYS-5-CONFIG_I: Configured from console by console
R7#
R7#sh ipv6 route
IPv6 Routing Table - default - 3 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
R  FEC0:0:0:600::1/128 [120/2]
   via FE80::FF:FE00:6, Serial0/1
LC FEC0:0:0:600::2/128 [0/0]
   via Serial0/1, receive
L  FF00::/8 [0/0]
   via Null0, receive
R7#
 
R6#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R6(config)#ipv6 router rip v6RIP
R6(config-rtr)#int s0/1
R6(config-if)#ipv6 rip v6RIP enable
R6(config-if)#exit
R6(config)#exit
R6#sh ipv6 route
IPv6 Routing Table - default - 4 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
LC FEC0:0:0:500::2/128 [0/0]
   via Serial0/0, receive
LC FEC0:0:0:600::1/128 [0/0]
   via Serial0/1, receive
R  FEC0:0:0:600::2/128 [120/2]
   via FE80::FF:FE00:7, Serial0/1
L  FF00::/8 [0/0]
   via Null0, receive
R6#ping ipv6 FEC0:0:0:600::2
 
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FEC0:0:0:600::2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/8/12 ms
R6#

What is interesting is that before we add in the RIPng process even though we have the correct addresses used we didn't have any visibility:

R7#ping FEC0:0:0:600::1
 
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FEC0:0:0:600::1, timeout is 2 seconds:
% No valid source address for destination
Success rate is 0 percent (0/1)

Once RIPng is working, all is fine:

R7#ping ipv6 FEC0:0:0:600::1

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

After we have added the same configurations to R5 and R4, we can see that R4 has full visibility down to R7:

R4#sh ipv6 route
IPv6 Routing Table - default - 14 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
O  FEC0::/64 [110/128]
   via FE80::FF:FE00:8, Serial0/2
O  FEC0:0:0:100::1/128 [110/64]
   via FE80::FF:FE00:8, Serial0/2
LC  FEC0:0:0:100::2/128 [0/0]
   via Serial0/2, receive
O  FEC0:0:0:200::1/128 [110/64]
   via FE80::FF:FE00:8, Serial0/2
O  FEC0:0:0:200::2/128 [110/128]
   via FE80::FF:FE00:8, Serial0/2
O  FEC0:0:0:300::1/128 [110/128]
   via FE80::FF:FE00:8, Serial0/2
O  FEC0:0:0:300::2/128 [110/1690]
   via FE80::FF:FE00:8, Serial0/2
LC  FEC0:0:0:400::1/128 [0/0]
   via Serial0/1, receive
R  FEC0:0:0:400::2/128 [120/2]
   via FE80::FF:FE00:5, Serial0/1
R  FEC0:0:0:500::1/128 [120/2]
   via FE80::FF:FE00:5, Serial0/1
R  FEC0:0:0:500::2/128 [120/3]
   via FE80::FF:FE00:5, Serial0/1
R  FEC0:0:0:600::1/128 [120/3]
   via FE80::FF:FE00:5, Serial0/1
R  FEC0:0:0:600::2/128 [120/4]
   via FE80::FF:FE00:5, Serial0/1
L  FF00::/8 [0/0]
   via Null0, receive
R4#
R4#ping FEC0:0:0:600::2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FEC0:0:0:600::2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/26/28 ms
R4#

IPv6 EIGRP

EIGRP is much the same as the other two we have done. We will again start with enabling ipv6 unicast routing and adding the IP addresses:

Then we can create our routing process and add our interfaces int it.

R2(config-if)#ipv6 router eigrp 100
R2(config-rtr)#int multilink 1
R2(config-if)#ipv6 eigrp 100
R2(config-if)#
*Nov 26 12:28:34.719: %DUAL-5-NBRCHANGE: EIGRP-IPv6 100: Neighbor FE80::FF:FE00:1 (Multilink1) is up: new adjacency
R2(config-if)#

The same commands are set on the other routers, and shortly we see that R1 has a decent looking routing table:

R1#sh ipv6 eigrp topology
EIGRP-IPv6 Topology Table for AS(100)/ID(1.2.3.4)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
    r - reply Status, s - sia Status

P FEC0:0:0:900::2/128, 1 successors, FD is 3193856
    via FE80::FF:FE00:2 (3193856/2681856), Multilink1
P FEC0:0:0:800::2/128, 1 successors, FD is 2681856
    via FE80::FF:FE00:2 (2681856/2169856), Multilink1
P FEC0:0:0:140::1/128, 1 successors, FD is 3705856
    via FE80::FF:FE00:2 (3705856/3193856), Multilink1
P FEC0:0:0:130::2/128, 1 successors, FD is 4217856
    via FE80::FF:FE00:2 (4217856/3705856), Multilink1
P FEC0:0:0:110::1/128, 1 successors, FD is 1340928
    via Connected, Multilink1
P FEC0:0:0:110::2/128, 1 successors, FD is 1852928
    via FE80::FF:FE00:2 (1852928/1340928), Multilink1
P FEC0:0:0:120::1/128, 1 successors, FD is 3705856
    via FE80::FF:FE00:2 (3705856/3193856), Multilink1
P FEC0:0:0:140::2/128, 1 successors, FD is 4217856
    via FE80::FF:FE00:2 (4217856/3705856), Multilink1
P FEC0:0:0:700::2/128, 1 successors, FD is 2681856
    via FE80::FF:FE00:2 (2681856/2169856), Multilink1
P FEC0:0:0:700::1/128, 1 successors, FD is 3193856
    via FE80::FF:FE00:2 (3193856/2681856), Multilink1
P FEC0:0:0:800::1/128, 1 successors, FD is 3193856
    via FE80::FF:FE00:2 (3193856/2681856), Multilink1
P FEC0:0:0:120::2/128, 1 successors, FD is 4217856
    via FE80::FF:FE00:2 (4217856/3705856), Multilink1
P FEC0:0:0:900::1/128, 1 successors, FD is 3705856
    via FE80::FF:FE00:2 (3705856/3193856), Multilink1
P FEC0:0:0:130::1/128, 1 successors, FD is 3705856
    via FE80::FF:FE00:2 (3705856/3193856), Multilink1

And we have reachability

R1#ping FEC0:0:0:140::2

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

IPv6 Redistribution

Redistribution under IPv6 is no different to that of IPv4 (which we covered in part 4), so using R4 which is our main bridge we can set it up as follows:

ipv6 router eigrp 100
 redistribute ospf 1 metric 10000 100 255 1 1500
 redistribute rip v6RIP metric 10000 100 255 1 1500
!
ipv6 router ospf 1
 router-id 4.4.4.4
 log-adjacency-changes
 redistribute rip v6RIP metric 100
 redistribute eigrp 100 metric 100
!
ipv6 router rip v6RIP
 redistribute ospf 1 metric 5
 redistribute eigrp 100 metric 5

And we can have a look at a couple of our outer-lying routers to check that they are seeing what we would expect:

R1 can see R8 as an external EIGRP route:

R1#sh ipv6 route FEC0:0:0:200::1
Routing entry for FEC0:0:0:200::1/128
 Known via "eigrp 100", distance 170, metric 2707456, type external
 Route count is 1/1, share count 0
 Routing paths:
  FE80::FF:FE00:2, Multilink1
   Last updated 00:08:59 ago

And R10 can see R14

R10#sh ipv6 route FEC0:0:0:130::2
Routing entry for FEC0:0:0:130::2/128
 Known via "ospf 1", distance 110, metric 100, type extern 2
 Route count is 1/1, share count 0
 Routing paths:
  FE80::FF:FE00:8, Serial1/0
   Last updated 00:09:23 ago

And just to confirm we have reachability:

R10#ping FEC0:0:0:130::2

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to FEC0:0:0:130::2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 52/55/60 ms
R10#

R1#ping FEC0:0:0:200::1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FEC0:0:0:200::1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/26/28 ms
R1#

On R5 the configuration is pretty much the same

ipv6 router ospf 1
 router-id 5.5.5.5
 log-adjacency-changes
 redistribute rip v6RIP metric 100
!
ipv6 router rip v6RIP
 redistribute ospf 1 metric 5

Now at this point my 14 routers are starting to slow down, R4 is getting hit quite badly and is reporting %SYS-2-MALLOCFAIL errors, so its probably time to start wrapping this up, but not before we throw in an IPv6 tunnel between R6 and R10.

IPv6 Tunnels

An IPv6 tunnel is not much different to how we set up our tunnel in part 7:

R10#sh run int tunnel 1
Building configuration...

Current configuration : 153 bytes
!
interface Tunnel1
 no ip address
 ipv6 address FEC0:0:0:150::2/128
 tunnel source Serial1/0
 tunnel mode ipv6
 tunnel destination FEC0:0:0:500::2
end

R6#sh run int tunnel 1
Building configuration...

Current configuration : 162 bytes
!
interface Tunnel1
 no ip address
 ipv6 address FEC0:0:0:150::1/128
 tunnel source Serial0/0
 tunnel mode ipv6
 tunnel destination FEC0::A8BB:CCFF:FE00:A00
end

R10#sh ipv6 route FEC0:0:0:150::2
Routing entry for FEC0:0:0:150::2/128
 Known via "connected", distance 0, metric 0, type receive, connected
 Route count is 1/1, share count 0
 Routing paths:
  receive via Tunnel1
   Last updated 00:00:59 ago
R10#ping FEC0:0:0:150::2

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

R6#ping FEC0:0:0:150::1

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

Thankfully we havn't had any recursive routing issues, but if we had then we could have used a distribute list like we did in part 8.

And that wraps up this part of the series. In part 10 we will cover some IPv6 filtering.

The BIG lab - Part 8 - Route-filtering and fixing route recursion using a distribute list (2.90)

Following on from part 7 when we created a tunnel between R5 and R10 (refer to part 1 for the topology) we have a little bit of tidying up to do (basically static routes are verboten on the proper exam), but first we are going to have a dip into filtering some routes.

We can be a bit creative and prevent routers from learning about specific routes - say for instance we have a "secure" network that we don't want to be advertised to some routers, depending on where we are limiting access to we have a number of options, including access-lists, prefix-lists, distribute-lists and route-maps. We arn't going to use a route-map to prevent a route, as these are mainly used during redistribution, but we can play around with access-lists, prefix-lists and distribute-lists.

R1 has a loopback interface, which will be our "secure network":

R1#sh run int lo0
Building configuration...

Current configuration : 95 bytes
!
interface Loopback0
 ip address 10.10.1.1 255.255.255.0
 ip ospf network point-to-point
end

This is accessible by R10:

R10#ping 10.10.1.1
Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.10.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/36 ms

R10#
R10#sh ip route 10.10.1.0
Routing entry for 10.10.1.0/24
 Known via "eigrp 10", distance 170, metric 2937856, type external
 Redistributing via eigrp 10
Last update from 10.31.1.1 on Serial1/0, 00:22:07 ago
 Routing Descriptor Blocks:
 * 10.31.1.1, from 10.31.1.1, 00:22:07 ago, via Serial1/0
   Route metric is 2937856, traffic share count is 1
   Total delay is 50000 microseconds, minimum bandwidth is 1544 Kbit
   Reliability 255/255, minimum MTU 1500 bytes
   Loading 1/255, Hops 2
R10#

Controlling routes through an access-list

So assuming that everything before R10 is allowed to this "private" network we need to prevent R10 from seeing this route (but lets keep access to R1's interface (1.2.3.4/24) accessible. we can do this in a number of ways. The most obvious place to put any configuration would be on R8's s0/2 interface.

I am going to use a distribute list for this, which references an access-list.

router eigrp 10
 distribute-list 1 out Serial0/2
 network 10.0.0.0
 no auto-summary
!
access-list 1 deny 10.10.1.0 0.0.0.255
access-list 1 permit any

Then I shut down the S0/2 interface on R8, cleared the IP routing table on R10 using "clear ip route *" and brought up the S0/2 interface on R8.

And now do we see the 10.10.1.0/24 network magically disappear from R10?

R10#sh ip route | beg 10.10
D EX  10.10.1.0/24 [170/27136000] via 10.120.2.1, 00:02:47, Tunnel0
D     10.20.1.0/24 [90/3193856] via 10.31.1.1, 00:02:47, Serial1/0

No, it has now learned it from its tunnel interface, that we created in part 7.

So let's add the same access-list to R5 (the other end of the tunnel):

R5(config)#access-list 1 deny 10.10.1.0 0.0.0.255
R5(config)#access-list 1 permit any
R5(config)#router eigrp 10
R5(config-router)#distribute-list 1 out Tunnel 0
R5(config-router)#exit
R5(config)#int tunnel 0
R5(config-if)#shut

Now let's clear the route from R10 

R10#
*Nov 25 13:06:24.635: %DUAL-5-NBRCHANGE: EIGRP-IPv4 10: Neighbor 10.120.2.1 (Tunnel0) is down: holding time expired
R10#sh ip route | i 10.10
R10#

And bring the tunnel back up again, does R10 still have a route to the loopback on R1?

R10#
*Nov 25 13:10:36.375: %DUAL-5-NBRCHANGE: EIGRP-IPv4 10: Neighbor 10.120.2.1 (Tunnel0) is up: new adjacency
R10#sh ip route | i 10.10
R10#

No, it doesn't.

Controlling routes through a prefix-list

Suppose we are told (for some reason) that we are not allowed to use an access-list, we could use a prefix list. So let's first put the 10.10.1.0/24 network back onto R10.

R10#
*Nov 25 13:17:31.431: %DUAL-5-NBRCHANGE: EIGRP-IPv4 10: Neighbor 10.120.2.1 (Tunnel0) is down: peer restarted
R10#
*Nov 25 13:17:35.935: %DUAL-5-NBRCHANGE: EIGRP-IPv4 10: Neighbor 10.120.2.1 (Tunnel0) is up: new adjacency
R10#sh ip route | i 10.10
D EX  10.10.1.0/24 [170/27136000] via 10.120.2.1, 00:00:31, Tunnel0
R10#sh ip route | i 10.10
D EX  10.10.1.0/24 [170/2937856] via 10.31.1.1, 00:00:01, Serial1/0
R10#
*Nov 25 13:18:08.659: %DUAL-5-NBRCHANGE: EIGRP-IPv4 10: Neighbor 10.31.1.1 (Serial1/0) is resync: peer graceful-restart
R10#sh ip route | i 10.10
D EX  10.10.1.0/24 [170/2937856] via 10.31.1.1, 00:00:13, Serial1/0
R10#

We can also use a prefix-list to accomplish the same thing, again we will need to put it on both R8 and R5

R8(config)#ip prefix-list deny-10.10.1.0 seq 5 deny 10.10.1.0/24
R8(config)#router eigrp 10
R8(config-router)#distribute-list prefix deny-10.10.1.0 out s0/2
R8(config-router)#
*Nov 25 13:21:29.207: %DUAL-5-NBRCHANGE: EIGRP-IPv4 10: Neighbor 10.31.1.2 (Serial0/2) is resync: route configuration changed
R8(config-router)#

We can see that EIGRP does its stuff, and again R10 gets its path to 10.10.1.0/24 through the tunnel.

R10#sh ip route | i 10.10
D EX  10.10.1.0/24 [170/2937856] via 10.31.1.1, 00:03:19, Serial1/0
R10#
*Nov 25 13:21:29.223: %DUAL-5-NBRCHANGE: EIGRP-IPv4 10: Neighbor 10.31.1.1 (Serial1/0) is resync: peer graceful-restart
R10#sh ip route | i 10.10
D EX  10.10.1.0/24 [170/27136000] via 10.120.2.1, 00:00:08, Tunnel0

So lets do the same commands on R5:

R5(config)#ip prefix-list deny-10.10.1.0 seq 5 deny 10.10.1.0/24
R5(config)#router eigrp 10
R5(config-router)#distribute-list prefix deny-10.10.1.0 out tunnel 0
R5(config-router)#exit

R10#sh ip route | i 10.10
D EX  10.10.1.0/24 [170/27136000] via 10.120.2.1, 00:00:08, Tunnel0
R10#
*Nov 25 13:23:50.015: %DUAL-5-NBRCHANGE: EIGRP-IPv4 10: Neighbor 10.120.2.1 (Tunnel0) is resync: peer graceful-restart
R10#sh ip route | i 10.10
R10#

Now R10 has no knowledge of the 10.10.1.0/24 network, but has also lost many of the other routes:

R10#sh ip route | beg Gateway

Gateway of last resort is not set
   10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
S    10.1.7.1/32 is directly connected, Serial1/0
C    10.31.1.0/24 is directly connected, Serial1/0
L    10.31.1.2/32 is directly connected, Serial1/0
C    10.120.2.0/24 is directly connected, Tunnel0
L    10.120.2.2/32 is directly connected, Tunnel0
   172.20.0.0/16 is variably subnetted, 9 subnets, 3 masks
C    172.20.20.0/24 is directly connected, Loopback0
L    172.20.20.1/32 is directly connected, Loopback0
C    172.20.30.0/24 is directly connected, Loopback1
L    172.20.30.1/32 is directly connected, Loopback1
D    172.20.40.0/23 is a summary, 00:40:49, Null0
C    172.20.40.0/24 is directly connected, Loopback2
L    172.20.40.1/32 is directly connected, Loopback2
C    172.20.41.0/24 is directly connected, Loopback3
L    172.20.41.1/32 is directly connected, Loopback3

R10 has lost the other routes due to a default deny in the prefix-list. We can overcome this by adding the following permit any any rule:

R8(config)#ip prefix-list deny-10.10.1.0 seq 10 permit 0.0.0.0/0 le 32

R5(config)#ip prefix-list deny-10.10.1.0 seq 10 permit 0.0.0.0/0 le 32

And now R10 can still reach R1, but on a different IP address:

R10#ping 1.2.3.4

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

Fixing recursive routing using a distribute list

Remember back in part 7 when we set up our tunnel, to avoid route recursion and that annoying %TUN-5-RECURDOWN error we had to add a few static routes, well Cisco (in the exam at least) don't like you to use static routes, if they did then the exam would be so much easier, and where would the fun in that be? So what can we do to keep our tunnel working and still control our metrics?

Lets start by shutting down our tunnel and removing the static routes:

R5(config)#int tunnel 0
R5(config-if)#shut
R5(config-if)#
*Nov 25 14:33:24.711: %DUAL-5-NBRCHANGE: EIGRP-IPv4 10: Neighbor 10.120.2.2 (Tunnel0) is down: interface down
R5(config-if)#exit
R5(config)#
*Nov 25 14:33:26.711: %LINK-5-CHANGED: Interface Tunnel0, changed state to administratively down
*Nov 25 14:33:27.715: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down
R5(config)#no ip route 172.20.40.0 255.255.255.0 Serial0/0
R5(config)#no ip route 172.20.40.0 255.255.255.0 Serial 0/2 10

R10(config)#int tunnel 0
R10(config-if)#shut
*Nov 25 14:34:27.411: %LINK-5-CHANGED: Interface Tunnel0, changed state to administratively down
*Nov 25 14:34:28.411: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down
R10(config-if)#no ip route 10.1.7.1 255.255.255.255 Serial1/0

R10 knows of 10.1.7.0/24 through EIGRP, so the easiest thing to do is to use an incoming distribute list, coupled with an ACL to deny the EIGRP process from learning about the tunnel endpoint on R10. R5 is being used as this is the router that is complaining about route recursion.

router eigrp 10
 distribute-list prefix deny-10.10.1.0 out Tunnel0
 distribute-list 20 in
 network 10.0.0.0
 redistribute rip metric 10000 1000 255 1 1500
 no auto-summary
!
ip prefix-list deny-10.10.1.0 seq 5 deny 10.10.1.0/24
ip prefix-list deny-10.10.1.0 seq 10 permit 0.0.0.0/0 le 32
access-list 20 deny 10.120.2.2

And with this in place our tunnel is stable and we have avoided using any static routes.

In part 9 we will add IPv6 onto our network, which should be interesting!