CCNA and Beyond: Packet Tracer files download

I have been asked to provide the lab files in Packet Tracer format.


Whilst I would strongly advise using a platform such as UNetLab, it's been asked for, so I feel it should be provided.

The config lab files are over in the forum, and I will be adding the troubleshooting section PT files in due course.

There is a mapping of the interfaces referenced in the book (which was written with UNetLab in mind) to the interfaces used in Packet Tracer.

Enjoy and happy studying!

Stuart.

CCNA v3.0: Describe the impact of firewalls in an Enterprise Network (Part 2)

In part 1, we saw the effect of putting a firewall into an enterprise network. If you have not read that post then please read it before reading this one, otherwise somethings may not make sense. In the post we saw that we can go from higher-level interfaces to lower, but not from lower to higher, and this is all about the trust we put in our zones.

In this part, we will add a DMZ to our network, and explain why we do this. We will also fix the network so that the Internet router can telnet into our network, but will be confined to the DMZ. Before we do this though, let's go back to a little theory and discuss the difference between stateful and stateless firewalls.

Stateful vs. Stateless firewalls

Our ASA is a stateful firewall. Stateful firewalls keep a connections table, and this is the users traffic. We can look at the traffic in a number of ways, just on the source and destination (layer-3), or we can go all the way up to layer-7 and include the protocol, and the ports being used.

Stateless firewalls (which were the first type of firewall) just perform packet filtering, and are more like extended access lists. There is less intelligence with stateless firewalls. Each request is treated separately to the response. So we need to be much more careful with stateless firewalls, and make sure that for each outgoing ACL (Access List), we have one to allow the return traffic, instead of the stateful firewall, which adds more intelligence, and will dynamically allow the return traffic, if the return traffic is part of an existing outgoing connection.

We saw this in the previous post, where we could telnet from Inside-1 to the Internet router, and the connection was set up, the return traffic was allowed through because of the stateful nature of the firewall. The firewall could see that the outgoing connection was set up, and the response was matched to this connection entry.

Before we added NAT, we could allowed the incoming telnet connection (originating from the Internet router), because we knew exactly who Inside-1 was. We then implemented NAT, which hid Inside-1 behind the external IP address of the ASA (10.1.1.2). Now, with NAT, the Internet router will not be able to telnet directly to the Inside-1 router, as the ASA will not know to which host the traffic is destined for. For this to work we would need to add another NAT rule, giving Inside-1 an external address, which can then be used by the ASA to correctly direct the traffic. However, this is really not the best design. Incoming connections should be directed to a DMZ (Demilitarized Zone), which adds another level of security to the network. So let's do this now.

DMZs

DMZs allow us to accept incoming connections, but keep them separated from our LAN.  These get their own security level (0 by default, like the Outside). If we add this to our network, it starts to look like this:


We have another router hanging off the ASA, and this will get a security level of 0, as we can see if we set it up:
ASA(config)# int gi0/2
ASA(config-if)# ip add 172.16.1.1 255.255.255.0
ASA(config-if)# no shut
ASA(config-if)# nameif DMZ
INFO: Security level for "DMZ" set to 0 by default.
ASA(config-if)# security-level 50
ASA(config-if)# 

DMZ(config)#int gi 0/0
DMZ(config-if)#ip add 172.16.1.10 255.255.255.0
DMZ(config-if)#no shut
DMZ(config-if)#exit
DMZ(config)#ip route 0.0.0.0 0.0.0.0 172.16.1.1
DMZ(config)#end
DMZ#ping 172.16.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.1.1, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 2/2/3 ms
DMZ#
Notice that I have set a security level of 50. Security levels are all about trust. Our internal network got a security level of 100 (we trust it a lot), the Internet got a security level of 0 (we really don't trust it), but we do trust the DMZ, just not as much as the internal network, so we can set it to 50.

The next step is to allow the Internet router to telnet to the DMZ router. To do this we need to add another NAT rule to forward traffic from an address in the 10.1.1.0/24 network (10.1.1.100), to the DMZ router (172.16.1.10), and permit the traffic:
ASA(config)# object network obj-DMZ 
ASA(config-network-object)# host 172.16.1.10
ASA(config-network-object)# exit                                         
ASA(config)#
ASA(config)# object network obj-DMZ-External
ASA(config-network-object)# host 10.1.1.100
ASA(config-network-object)# exit
ASA(config)#
ASA(config)# nat (DMZ,Outside) source static obj-DMZ obj-DMZ-External 
ASA(config)# 
Notice that I have not actually added an ACL to permit this traffic. This is because we actually added one that permits this traffic in the previous post:
ASA(config)# access-list outside->in permit tcp host 10.1.1.1 any eq telnet
ASA(config)# 
As such we do not need to add one to permit traffic coming from the outside to the DMZ. But we did need to add the NAT rule. For more information on NAT, pick up the CCNA and Beyond study guide from Amazon, there are a lot of NAT exercises in there.

We can see that this works by telnetting from the Internet router to the IP address 10.1.1.100, and we can also see the hit count on the ASAs ACL increase:
Internet#telnet 10.1.1.100
Trying 10.1.1.100 ... Open


User Access Verification

Password: 

DMZ>exit

[Connection to 10.1.1.100 closed by foreign host]
Internet#

ASA# sh access-list outside->in
access-list outside->in; 2 elements; name hash: 0x307dc218
access-list outside->in line 1 extended permit icmp any any (hitcnt=0) 0x6d9415b4 
access-list outside->in line 2 extended permit tcp host 10.1.1.1 any eq telnet (hitcnt=2) 0x95b68c2a 
ASA# 
Returning to the NAT rule we set up, instead of referencing IP addresses, we used objects.

Firewall objects

Working with objects makes life much easier. We can group related services (such as HTTP and HTTPS) into one object (such as calling it "WEB-Traffic"):
ASA(config)# object service WEB-Traffic
ASA(config-service-object)# service tcp destination eq http
ASA(config-service-object)# service tcp destination eq https
ASA(config-service-object)# 
We can now reference this in our NAT or ACL statements, and this makes reading the configuration much easier (and keeps things cleaner). The downside to this is that it becomes harder to match ACL hits to an individual endpoint. If you have ten hosts within an object and a thousand hits on the ACL, it's hard to see which of these hosts are actually receiving the traffic. But this is just one of those things that you learn from as you go.

NAT order of operations

Before we leave this post we should return to a bit of theory, and look at the order of operations that a Firewall goes through as traffic comes in, or goes out.

The actual order of events is fairly similar, but changes depending on the direction of the traffic.

The Cisco doc here, outlines all the steps taken. We can test this within the ASA itself though, using the packet-tracer command (I have truncated the output a bit to make it a little more readable):
ASA# packet-tracer input inside tcp 192.168.1.10 telnet 10.1.1.1 telnet detailed

Phase: 1
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
found next-hop 10.1.1.1 using egress ifc  Outside

Phase: 2
Type: NAT
Subtype: 
Result: ALLOW
Config:
nat (Inside,Outside) after-auto source dynamic INSIDE-NAT-SUBNETS interface
Additional Information:
Dynamic translate 192.168.1.10/23 to 10.1.1.2/23
 Forward Flow based lookup yields rule:
        input_ifc=Inside, output_ifc=Outside

Phase: 3      
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:

Phase: 4
Type: IP-OPTIONS
Subtype: 
Result: ALLOW
Config:
Additional Information:

Phase: 5
Type: QOS
Subtype: 
Result: ALLOW
Config:
Additional Information:

Phase: 6
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
nat (Inside,Outside) after-auto source dynamic INSIDE-NAT-SUBNETS interface
Additional Information:

Phase: 7
Type: QOS
Subtype: 
Result: ALLOW
Config:
Additional Information:
 Reverse Flow based lookup yields rule:

Phase: 8
Type: NAT
Subtype: per-session
Result: ALLOW 
Config:
Additional Information:
 Reverse Flow based lookup yields rule:

Phase: 9
Type: IP-OPTIONS
Subtype: 
Result: ALLOW
Config:
Additional Information:
 Reverse Flow based lookup yields rule:
        input_ifc=Outside, output_ifc=any

Phase: 10     
Type: FLOW-CREATION
Subtype: 
Result: ALLOW
Config:
Additional Information:

Module information for reverse flow ...

Result:
input-interface: Inside
input-status: up
input-line-status: up
output-interface: Outside
output-status: up
output-line-status: up
Action: allow

ASA# 
The above is for traffic leaving the network, going from 192.168.1.10 to 1.1.1.1. In Phase 1, we look to see if we have a route to the destination, and this gives us our "egress" interface. In Phase 2, we perform NAT, mapping our inside subnets to our external interface's IP address (10.1.1.2). Because the type of NAT we are using is PAT (and again pick up CCNA and Beyond to understand more about PAT), this is setup and allowed in Phase 4. Phase 5 passes, because we have not implemented QoS (Quality of Service). Phase 6 is an additional check, called Reverse Path Forwarding, which means that we check to make sure that the reply to the traffic is going to come back through the interface we sent the original request out of. This helps eliminate routing loops, and general traffic weirdness. We have more QoS in Phase 7, which again passes, and we move on to Phase 8. Here we again set up NAT, but for the return traffic, you can tell this because it is for the "Reverse Flow". We have not set any IP options, so Phase 9 passes, and we move on to Phase 10. Here the flow is created, and we see that everything has worked.

Let's look at traffic coming in now.
ASA# packet-tracer input outside tcp 10.1.1.1 telnet 10.1.1.100 telnet detailed

Phase: 1
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (DMZ,Outside) source static obj-DMZ obj-DMZ-External
Additional Information:
NAT divert to egress interface DMZ
Untranslate 10.1.1.100/23 to 172.16.1.10/23

Phase: 2
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group outside->in in interface Outside
access-list outside->in extended permit tcp host 10.1.1.1 any eq telnet 
Additional Information:

Phase: 3
Type: NAT
Subtype: 
Result: ALLOW
Config:
nat (DMZ,Outside) source static obj-DMZ obj-DMZ-External
Additional Information:
Static translate 10.1.1.1/23 to 10.1.1.1/23

Phase: 4
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:

Phase: 5
Type: IP-OPTIONS
Subtype: 
Result: ALLOW
Config:
Additional Information:

Phase: 6
Type: QOS
Subtype: 
Result: ALLOW 
Config:
Additional Information:

Phase: 7
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
nat (DMZ,Outside) source static obj-DMZ obj-DMZ-External
Additional Information:
 Forward Flow based lookup yields rule:
 out id=0x7fb295a33350, priority=6, domain=nat-reverse, deny=false
        dst ip/id=172.16.1.10, mask=255.255.255.255, port=0, tag=any, dscp=0x0
        input_ifc=Outside, output_ifc=DMZ
              
Phase: 8
Type: QOS
Subtype: 
Result: ALLOW
Config:
Additional Information:
 Reverse Flow based lookup yields rule:

Phase: 9
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:
 Reverse Flow based lookup yields rule:

Phase: 10
Type: IP-OPTIONS
Subtype: 
Result: ALLOW
Config:
Additional Information:
 Reverse Flow based lookup yields rule:

Phase: 11
Type: FLOW-CREATION
Subtype: 
Result: ALLOW
Config:
Additional Information:
New flow created with id 41, packet dispatched to next module
Module information for forward flow ...

Module information for reverse flow ...

Result:
input-interface: Outside
input-status: up
input-line-status: up
output-interface: DMZ
output-status: up
output-line-status: up
Action: allow

ASA# 
The first step is to work out where the traffic is really supposed to go to, so in Phase 1 we un-translate 10.1.1.100 to 172.16.1.10. We then confirm that the traffic is permitted, and find a matching ACL in Phase 2. In Phase 3 we see that we are not doing any translation (or un-translation) on the source address of 10.1.1.1. In Phase 4 we allow the NAT, and again in Phase 5 and 6, because we do not have any IP options or QoS, the traffic is allowed. We again make sure that the traffic going out will match the interface that it came in on, by performing an RPF-check in Phase 7. In Phase 8 we pass the QoS, and in Phase 9 we set up the per-session NAT. Phase 10 passes because we have not set any IP Options, and in Phase 11 the flow is created.

So here you can see the difference between incoming and outgoing traffic, where NAT is concerned.

Whilst most of this is probably beyond the needs of the CCNA exam, this is the kind of skills you should pick up as you study. It will certainly help solidify knowledge of other areas.

In the next section of this series we will discuss the different modes a firewall can be in, and these are routed (as we have seen here), transparent, and multi-context.

CCNA v3.0: Describe the impact of firewalls in an Enterprise Network (Part 1)

The CCNA v3.0 added a new topic; to describe the impact of firewalls, access points and wireless controllers in an Enterprise Network.

We will start by looking at firewalls today, and over a couple of posts, because there is a lot to them. Don't worry too much though as the exam syllabus lists this as a "describe", rather than a "configure". So there will only be a couple of questions on these in the exam.

We will cover access-points and wireless controllers together in a separate post (as it makes sense to do that).

What is a Firewall?

A firewall can be either software-based, or hardware-based, but pretty much all of them are based around a Linux kernel. No matter what the make or model, they all do pretty much the same thing, and that is to separate the host machine, or network, into zones.

Zones allow us to segregate the network into different security areas. We will be concentrating on the syntax for ASA firewalls, mainly, as these are Cisco devices, and so will probably be the main focus in the v3.0 CCNA exam.

You can try the ASA out on Packet Tracer, but these are the 5505 ones (so really down at the small-end of the scale), and the software version is really old. You are much better off, of you really want to play around with firewalls, by looking at UNetLab, or GNS3.

With the ASA we can assign names to an interface, the most common being "Outside", "Inside" and "DMZ". We will first look at the Outside and the Inside.

We can have more than one "Outside", if we have multiple connections to the Internet. The Outside is given a security level value, which is 0 by default. Our Inside interface will also be given a security level value, usually this is 100.

By default we can go from a higher level to a lower level, but not from lower to higher.


Once we set up a firewall, we will see this in action, but the important thing to note is that we will be able to get from the inside network to the Internet, but the Internet would not be able to get into us. Firewalls are stateful, meaning it knows what traffic is leaving it, and will allow the return traffic, but this also means that, without some specific rules, traffic cannot get in.

So, let's see this in action. This is our existing network:

CCNA v3.0 Firewalls - simple gateway

We have OSPF running through the network, and the Inside routers can reach the Internet (8.8.8.8):
Inside-1#ping 8.8.8.8
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/5 ms
Inside-1#

Inside-2#ping 8.8.8.8
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/5/6 ms
Inside-2#
The Internet can also reach the inside:
Internet#ping 192.168.1.10
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.10, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/5 ms
Internet#
Clearly, this is not very secure. So, we will look at the impact of firewalls in an Enterprise Network, by swapping the Gateway router for an ASA, which gives us a network that looks more like this:

CCNA v3.0 - Impact of a firewall in an enterprise network
First of all, we will set up our basic IP address:
ASA(config)# int gi0/1
ASA(config-if)# ip add 192.168.1.1 255.255.255.0
ASA(config-if)# no shut
ASA(config-if)# 
Can we reach this from Inside-1?
Inside-1#ping 192.168.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
Inside-1#
No, we cannot. Let's assign the interface to the "Inside" zone, and see if that helps:
ASA(config-if)# nameif Inside
INFO: Security level for "Inside" set to 100 by default.
ASA(config-if)# 

Inside-1#ping 192.168.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 3/6/12 ms
Inside-1#
So, now we have some measure of success, we can ping from Inside-1 to our ASA. We still cannot get any further, as we have not configured our Outside interface. Let's add this in:
ASA(config-if)# exit
ASA(config)# int gi0/0
ASA(config-if)# ip add 10.1.1.2 255.255.255.0
ASA(config-if)# no shut
ASA(config-if)# nameif Outside
INFO: Security level for "Outside" set to 0 by default.
ASA(config-if)# 
Instead of OSPF, we will set up some basic static routes for the moment:
Inside-1(config)#ip route 0.0.0.0 0.0.0.0 192.168.1.1
Inside-1(config)#

ASA(config-if)# route Outside 8.8.8.8 255.255.255.255 10.1.1.1
ASA(config)#end
ASA# ping Outside 8.8.8.8
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/4/10 ms
ASA#

Inside-1#ping 8.8.8.8
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
Inside-1#
Now we can ping 8.8.8.8 from the ASA, but not from a host on the Inside. The Internet does not know about the 192.168.1.0/24 network.

With our Inside and Outside interfaces assigned, our network, logically, now looks like this:

CCNA v3.0 - Firewall security levels

Before we put the ASA in the network, we had full reachability between the Inside-1 and -2 routers and the Internet. We did this through OSPF, and the ASA is no exception - we can set up OSPF on our ASA:
ASA(config)# router ospf 1
ASA(config-router)# router-id 2.2.2.2
ASA(config-router)# network 0.0.0.0 0.0.0.0 a 0
ASA(config-router)# 
The adjacencies form, and the Internet can see the 192.168.1.0/24 network, and the Inside routers can see the 8.8.8.8 network, we just can't reach it:
Internet#sh ip route ospf | b Gate
Gateway of last resort is not set

O     192.168.1.0/24 [110/11] via 10.1.1.2, 00:03:53, GigabitEthernet0/0
Internet#

Inside-1#sh ip route ospf | b Gate
Gateway of last resort is not set

      8.0.0.0/32 is subnetted, 1 subnets
O        8.8.8.8 [110/12] via 192.168.1.1, 00:00:09, GigabitEthernet0/0
      10.0.0.0/24 is subnetted, 1 subnets
O        10.1.1.0 [110/11] via 192.168.1.1, 00:23:32, GigabitEthernet0/0
Inside-1#
Inside-1#ping 8.8.8.8             
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
Inside-1#

Internet#
*May 29 14:54:10.377: ICMP: echo reply sent, src 8.8.8.8, dst 192.168.1.10, topology BASE, dscp 0 topoid 0
*May 29 14:54:12.377: ICMP: echo reply sent, src 8.8.8.8, dst 192.168.1.10, topology BASE, dscp 0 topoid 0
*May 29 14:54:14.377: ICMP: echo reply sent, src 8.8.8.8, dst 192.168.1.10, topology BASE, dscp 0 topoid 0
*May 29 14:54:16.377: ICMP: echo reply sent, src 8.8.8.8, dst 192.168.1.10, topology BASE, dscp 0 topoid 0
*May 29 14:54:18.376: ICMP: echo reply sent, src 8.8.8.8, dst 192.168.1.10, topology BASE, dscp 0 topoid 0
Internet#
The logs above do show that the Internet is sending the reply back to the Inside-1 router. But it is not reaching it, because the return traffic is not permitted by the firewall. We need an access-list (ACL) to permit this.

Firewalls have Access-lists

We will start our access-list by permitting ICMP traffic:
ASA(config)# access-list outside->in extended permit icmp any any
ASA(config)# access-group outside->in in interface Outside
ASA(config)# 

Inside-1#ping 8.8.8.8
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 7/10/13 ms
Inside-1#
We can now reach the Internet from Inside-1, because we allowed ICMP (which is the protocol used by ping) to come back into the network. We can also telnet from Inside-1 to the Internet (because we are going from a higher-level interface to a lower-level interface):
Inside-1#telnet 8.8.8.8
Trying 8.8.8.8 ... Open

User Access Verification

Password: 
Internet>
Internet>exit

[Connection to 8.8.8.8 closed by foreign host]
Inside-1#
Our Telnet source port will be one of the higher ports, to the destination port of 23, but the return traffic will be allowed because we have a stateful firewall, therefore because the traffic is initiated from the Inside, the return traffic will be permitted. What we cannot do is initiate a connection from the Internet, to Inside-1:
Internet#telnet 192.168.1.10
Trying 192.168.1.10 ... 
% Connection timed out; remote host not responding

Internet#
We can amend our ACL to permit this traffic:
ASA(config)# access-list outside->in permit tcp host 10.1.1.1 any eq telnet
ASA(config)# 

Internet#telnet 192.168.1.10
Trying 192.168.1.10 ... Open

User Access Verification

Password: 

Inside-1>
Inside-1>exit

[Connection to 192.168.1.10 closed by foreign host]
Internet#
The 10.1.1.1 address is the source address on the Internet router, and "any" means any host on the Inside of our network. Until we added this last ACL rule, we were not explicitly denying the telnet traffic, but it was still denied. This is because ACLs have a default deny rule at the end of them, therefore any traffic that is not explicitly permitted, will be denied, by the implicit deny rule. It is implicit because it does not show up in the configuration:
ASA# show access-list 
access-list cached ACL log flows: total 0, denied 0 (deny-flow-max 4096)
            alert-interval 300
access-list outside->in; 2 elements; name hash: 0x307dc218
access-list outside->in line 1 extended permit icmp any any (hitcnt=1) 0x6d9415b4 
access-list outside->in line 2 extended permit tcp host 10.1.1.1 any eq telnet (hitcnt=1) 0x95b68c2a 
ASA# 
As you can see here, we have the two rules we added, but there is no rule stating that other traffic is to be denied, the rule exists, but we just can't see it, because it is implicit.

Firewalls and NAT.

Strictly speaking, we wouldn't be running OSPF straight from the ISP into our network. The RFC1918 addresses we use on our internal network are not routable on the Internet, and if you were to advertise a default route to the ISP, well, I am sure they would not be happy about it.

Therefore we will hide our network behind Network Address Translation (NAT):
ASA(config)# object-group network INSIDE-NAT-SUBNETS
ASA(config-network-object-group)# network-object 192.168.1.0 255.255.255.0
ASA(config-network-object-group)# exit
ASA(config)# nat (inside,outside) after-auto source dynamic INSIDE-NAT-SUBNETS interface
ASA(config)# 
Can we still reach the Internet?
Inside-1#ping 8.8.8.8
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 10/11/13 ms
Inside-1#

Internet#
*May 29 15:27:23.020: ICMP: echo reply sent, src 8.8.8.8, dst 10.1.1.2, topology BASE, dscp 0 topoid 0
*May 29 15:27:23.032: ICMP: echo reply sent, src 8.8.8.8, dst 10.1.1.2, topology BASE, dscp 0 topoid 0
*May 29 15:27:23.044: ICMP: echo reply sent, src 8.8.8.8, dst 10.1.1.2, topology BASE, dscp 0 topoid 0
*May 29 15:27:23.057: ICMP: echo reply sent, src 8.8.8.8, dst 10.1.1.2, topology BASE, dscp 0 topoid 0
*May 29 15:27:23.070: ICMP: echo reply sent, src 8.8.8.8, dst 10.1.1.2, topology BASE, dscp 0 topoid 0
Internet#
We can, but now we are hidden behind the firewalls outside interface (10.1.1.2).

The takeaway from this post is that you cannot just run out, buy a firewall, plug it in, and expect it to work. At the very minimum you will need to add some access lists, and remember the default deny rule. You should always NAT your traffic as well. Because of the NAT we will not be able to telnet from the Internet router to 192.168.1.10, but we will look at how to fix this in the next part.

In the second part of this post we will also look at the role of the DMZ (Demilitarised Zone), and in the third part, we will look at the different modes a firewall can be in. So far we have been looking at a routed firewall (it has a layer-3 IP address). This is just one flavour of firewall, but is the most common, certainly the one you are most likely to encounter.

Quiz time: A game of numbers

I have made a little quiz. It is just over 30 questions, and it's all about numbers in networking.



It is scored at the end, so you can try as many times as you like!

I will be doing more of these, some will be easier, some will be harder.

I hope you enjoy it.


5 things Cisco Packet Tracer WONT teach you (but you should know).

In this post I am going to have a bit of a moan about some of the things that the Cisco Packet Tracer (PT) does not support. I am sure that this post is just the tip of the iceberg!

I have not touched PT since my CCNA days, but now, several years on, I am going back to it to have a look. This is more of a fact finding mission, expect updates as I play with it a bit more.

The version I am using is 6.3.0.0009:


So, interface-wise, nothing seems to have changed that much since I used it last time. The layout is still the same, its all very drag and drop. We have a couple of different device options, such as the 1841 and 1941 routers, the 3560 switch and the ASA, which brings us to our first problem:

1: Packet Tracer does not support new IOSes

The versions on here are OLD!
Switch   Ports  Model              SW Version              SW Image
------   -----  -----              ----------              ----------
*    1   26     WS-C3560-24PS      12.2(37)SE1             C3560-ADVIPSERVICESK

ciscoasa#sh ver

Cisco Adaptive Security Appliance Software Version 8.4(2)
Device Manager Version 6.4(5)

Router(config-if)#do sh ver
Cisco IOS Software, C1900 Software (C1900-UNIVERSALK9-M), Version 15.1(4)M4,
You do not have the option to add new versions to PT. It's very limiting! You can't run Qemu nodes, and the ASA is very out-dated (and it's a 5505 which are right the the bottom end of the scale).

Anyway, how do we know what versions we are running? Well, you would usually look at the version (show version), but if you just want to get the information, and not the waffle, you would use the pipe command to include just the version, which brings us onto point #2.

2: No piping commands!

The really sucks, you can't use the pipe command to get just the information you need!
Switch(config)#do sh ver | i Version
sh ver | i Version
       ^
% Invalid input detected at '^' marker.
 
Switch(config)#
I want to be able to truncate the information I get to just the stuff I need, like finding the configuration for a particular interface.

3: You can't sh run interface

You have to look through the entire configuration to find the details for a particular interface:
Switch#sh run int fa0/24
              ^
% Invalid input detected at '^' marker.
 
Switch#sh run ?
  <cr>
Switch#sh run interface fa0/24
              ^
% Invalid input detected at '^' marker.
 
Switch#sh run ?
  <cr>
Switch#sh run 
Keep pressing that space bar to continue! This is not an efficient use of your time, and certainly as you progress from CCNA into a network career, and start looking towards the CCNP and CCIE, you will need to now how to get to the information you need as quickly as possible! You can't spend your time searching through the configuration to find the information you need.

Let's press on a look for something a little more advanced in the switching and routing domains.

4: MST

Switch(config)#spanning-tree mode ?
  pvst        Per-Vlan spanning tree mode
  rapid-pvst  Per-Vlan rapid spanning tree mode
Switch(config)#spanning-tree mode
No Multiple Spanning-Tree. I suppose this is OK, because it's not on the CCNA. But External BGP made it into the new v3.0, so how well is BGP supported?

5: No Internal BGP (iBGP)

Router(config-if)#ip add 1.1.1.1 255.255.255.255
Router(config-if)#router bgp 10
Router(config-router)#bgp router-id 1.1.1.1
Router(config-router)#neighbor 2.2.2.2 remote-as 10
Router(config-router)#
%Packet Tracer does not support internal BGP in this version. Only external neighbors are supported.


Router(config-router)#
Seriously? Oh, come on! How hard is it to have internal BGP working as well as external BGP? That's just plain lazy!

I am sure that there are many more commands that re not supported, but this was just a quick test.

Considering PT is supposed to be the platform that engineers start with, it's not teaching you how to be an effective engineer.

There will be occasions when time is not on your side, be it when you are troubleshooting an issue, or when you are taking an exam. You need to learn the little tricks that will make your life as a network engineer easier and more efficient. Packet Tracer will limit you as an engineer. This is why I moved away from it years ago, it certainly won't help you as you progress in your studies. This is why platforms such as UNetLab and GNS3 are so popular. They support the full set of commands, allowing you to become an excellent network engineer, rather than a mediocre one.

When I started writing CCNA and Beyond, I made the decision to aim higher than PT would allow, and you should aim higher as well. Don't be limited by Packet Tracer, aim higher and use a proper platform for your studies.

Packet Tracer will not make you a good engineer, you won't learn the little tricks good engineers use to make their life easier and more effective. Achieving your potential is all about not being limited, Packet Tracer will limit you. You may not see it at the moment, but as you progress, you will start to see this.


The Sunday challenge: Minimalist networking

This week's challenge is all about minimalist networking. What do I mean by minimalist? Well, this one is all about routing table sizes. Smaller routing tables are more efficient.

This is what we are dealing with today:

Minimalist networking

Our goal is to get R7 to see all of the networks, but have as few entries in it's routing table as possible. There is a clue to the second challenge, and I promise that it's not a RED HERRING!

We will use OSPF for this one, and you can download the initial topology from the forum.

Let's start by planning the OSPF topology. Can we run area 0 though the entire network? Sure we can, but is that the best design? Not really. We have a number different sites, so we should use separate areas, something like this:


Challenge 1 (level: Medium):

1: Set up the basic OSPF configuration on the routers.
2: Advertise the /32 prefix for all the links (such as "network 5.6.7.7 0.0.0.0 area 0")
3: Add the loopback interfaces where necessary! Only add the preconfigured loopback interfaces (shown on the diagram) to OSPF.
4: I have put in one simple troubleshooting step.

By the end of this part, R7's routing table should look like this:
R7(config-if)#do sh ip route | b Gate
Gateway of last resort is not set

      1.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
O IA     1.1.1.1/32 [110/21] via 5.6.7.5, 00:06:31, Ethernet0/0
O IA     1.2.5.0/24 [110/20] via 5.6.7.5, 00:06:41, Ethernet0/0
      2.0.0.0/32 is subnetted, 1 subnets
O IA     2.2.2.2 [110/21] via 5.6.7.5, 00:06:31, Ethernet0/0
      3.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
O IA     3.3.3.3/32 [110/21] via 5.6.7.6, 00:04:04, Ethernet0/0
O IA     3.4.6.0/24 [110/20] via 5.6.7.6, 00:04:14, Ethernet0/0
      4.0.0.0/32 is subnetted, 1 subnets
O IA     4.4.4.4 [110/21] via 5.6.7.6, 00:04:04, Ethernet0/0
      5.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        5.6.7.0/24 is directly connected, Ethernet0/0
L        5.6.7.7/32 is directly connected, Ethernet0/0
      7.0.0.0/32 is subnetted, 1 subnets
C        7.7.7.7 is directly connected, Loopback0
R7(config-if)#

Challenge 2 (level: Advanced):

Get the routing table of R7 to look like this:
R7(config-if)#do sh ip route | b Gate
Gateway of last resort is not set

O IA  1.0.0.0/8 [110/20] via 5.6.7.5, 00:00:39, Ethernet0/0
O IA  2.0.0.0/8 [110/21] via 5.6.7.5, 00:00:10, Ethernet0/0
O IA  3.0.0.0/8 [110/20] via 5.6.7.6, 00:00:58, Ethernet0/0
O IA  4.0.0.0/8 [110/21] via 5.6.7.6, 00:00:02, Ethernet0/0
      5.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        5.6.7.0/24 is directly connected, Ethernet0/0
L        5.6.7.7/32 is directly connected, Ethernet0/0
      7.0.0.0/32 is subnetted, 1 subnets
C        7.7.7.7 is directly connected, Loopback0
R7(config-if)#
Make sure that R7 can reach the loopbacks on the diagram:
R7(config-if)#do ping 1.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
R7(config-if)#do ping 2.2.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
R7(config-if)#do ping 3.3.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
R7(config-if)#do ping 4.4.4.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
R7(config-if)#
The key to this challenge is not so much getting the correct answer, but finding out how to get the correct answer. Challenge 2 is more CCNP level than CCNA, but the goal here is to try and find out how to get to the solution!

Answers:


Challenge 1:

R7(config)#router ospf 1
R7(config-router)# 
%OSPF-4-NORTRID: OSPF process 1 failed to allocate unique router-id and cannot start
R7(config-router)#network 5.6.7.7 0.0.0.0 a 0
R7(config-router)#
R7(config-router)#int lo0
R7(config-if)#ip add 7.7.7.7 255.255.255.255
R7(config-if)#interface Ethernet0/0
R7(config-if)#no shutdown

R5(config)#int lo0
R5(config-if)#ip add 5.5.5.5 255.255.255.255
R5(config-if)#router ospf 1
R5(config-router)#network 5.6.7.5 0.0.0.0 a 0
R5(config-router)#

R6(config)#int lo0
R6(config-if)#ip add 6.6.6.6 255.255.255.255
R6(config-if)#
R6(config-if)#router ospf 1
R6(config-router)#network 5.6.7.6 0.0.0.0 a 0
R6(config-router)#
%OSPF-5-ADJCHG: Process 1, Nbr 5.6.7.5 on Ethernet0/1 from LOADING to FULL, Loading Done
%OSPF-5-ADJCHG: Process 1, Nbr 7.7.7.7 on Ethernet0/1 from LOADING to FULL, Loading Done
R6(config-router)#

R1(config)#router ospf 1
R1(config-router)#network 1.1.1.1 0.0.0.0 a 1
R1(config-router)#network 1.2.5.1 0.0.0.0 a 1
R1(config-router)#

R2(config)#router ospf 1
R2(config-router)#network 2.2.2.2 0.0.0.0 a 1
R2(config-router)#network 1.2.5.2 0.0.0.0 a 1
R2(config-router)#
%OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.1 on Ethernet0/0 from LOADING to FULL, Loading Done
R2(config-router)#

R5(config-router)#
R5(config-router)#network 1.2.5.5 0.0.0.0 a 1
R5(config-router)#
%OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on Ethernet0/0 from LOADING to FULL, Loading Done
%OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.1 on Ethernet0/0 from LOADING to FULL, Loading Done
R5(config-router)#

R3(config)#router ospf 1
R3(config-router)#network 3.3.3.3 0.0.0.0 a 2
R3(config-router)#network 3.4.6.3 0.0.0.0 a 2
R3(config-router)#

R4(config)#router ospf 1
R4(config-router)#network 4.4.4.4 0.0.0.0 a 2
R4(config-router)#network 3.4.6.4 0.0.0.0 a 2
R4(config-router)#
R4(config-router)#
%OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on Ethernet0/0 from LOADING to FULL, Loading Done
R4(config-router)#

R6(config-router)#
R6(config-router)#network 3.4.6.6 0.0.0.0 a 2
R6(config-router)#
%OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on Ethernet0/0 from LOADING to FULL, Loading Done
%OSPF-5-ADJCHG: Process 1, Nbr 4.4.4.4 on Ethernet0/0 from LOADING to FULL, Loading Done
R6(config-router)#

Challenge 2:

R5(config)#router ospf 1
R5(config-router)#
R5(config-router)#area 1 range 1.0.0.0 255.0.0.0 
R5(config-router)#area 1 range 2.0.0.0 255.0.0.0 
R5(config-router)#

R6(config)#router ospf 1
R6(config-router)#
R6(config-router)#area 2 range 3.0.0.0 255.0.0.0     
R6(config-router)#area 2 range 4.0.0.0 255.0.0.0
R6(config-router)#
How did you do?

Explanations:

The first challenge is all about making sure that we can actually start OSPF. We need to have a loopback interface up and working if OSPF is to pick a router ID automatically. Therefore we need to create loopback interfaces on R7, R6 and R5. The other option would be to manually assign a router id, using the command "router-id 7.7.7.7", and so on.

Did you catch that R7's interface was shut down? I hope so, otherwise nothing much would work!

Challenge 2 is more CCNP level. So, don't be upset if it took you a little time to get to the answer, and hopefully you did some googling to find out, but also never be afraid to use the context sensitive help. The key here is that we broke OSPF into different areas, that was the clue at the start. Because of this, we can area-based summarization:
R6(config-router)#area ?
  <0-4294967295>  OSPF area ID as a decimal value
  A.B.C.D         OSPF area ID in IP address format

R6(config-router)#area 1 ?
  authentication  Enable authentication
  capability      Enable area specific capability
  default-cost    Set the summary default-cost of a NSSA/stub area
  filter-list     Filter networks between OSPF areas
  nssa            Specify a NSSA area
  range           Summarize routes matching address/mask (border routers only)
  sham-link       Define a sham link and its parameters
  stub            Specify a stub area
  virtual-link    Define a virtual link and its parameters

R6(config-router)#area 1 ran
R6(config-router)#area 1 range ?
  A.B.C.D  IP address to match

R6(config-router)#
Area-based summarization allows us to keep greater control over our routing tables, and smaller routing tables are a good thing!

I hope you have enjoyed this challenge! More to come soon.

Internal vs. External EIGRP

This post will help explain what the difference between internal EIGRP and external EIGRP is.

 This is our topology:

internal vs external EIGRP

We have three different EIGRP autonomous systems (AS). From R1 we want to get to the IP 1.1.1.1, which is a loopback interface on R3. We can go through AS 100, which has a number of routers in it. Or we can see how we can get to it through AS 300 and AS 200.

The basic IP addressing is below:
R1#sh run int e0/0 | b interface
interface Ethernet0/0
 ip address 10.1.30.1 255.255.255.0
end

R1#sh run int e0/1 | b interface
interface Ethernet0/1
 ip address 10.1.6.1 255.255.255.0
end

R1#

R2#sh run int e0/0 | b interface
interface Ethernet0/0
 ip address 10.1.30.2 255.255.255.0
end

R2#sh run int e0/1 | b interface
interface Ethernet0/1
 ip address 10.1.20.2 255.255.255.0
end

R2#

R3#sh run int e0/0 | b interf
interface Ethernet0/0
 ip address 10.1.20.3 255.255.255.0
end

R3#sh run int e0/1 | b interf
interface Ethernet0/1
 ip address 10.1.3.3 255.255.255.0
end

R3#sh run int lo0 | b interf
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
end

R3#

R4#sh run int e0/0 | b interf
interface Ethernet0/0
 ip address 10.1.4.4 255.255.255.0
end

R4#sh run int e0/1 | b interf
interface Ethernet0/1
 ip address 10.1.5.4 255.255.255.0
end

R4#

R5#sh run int e0/0 | b interf
interface Ethernet0/0
 ip address 10.1.3.5 255.255.255.0
end

R5#sh run int e0/1 | b interf
interface Ethernet0/1
 ip address 10.1.4.5 255.255.255.0
end

R5#

R6#sh run int e0/0 | b interf
interface Ethernet0/0
 ip address 10.1.6.6 255.255.255.0
end

R6#sh run int e0/1 | b interf
interface Ethernet0/1
 ip address 10.1.5.6 255.255.255.0
end

R6#

internal and external EIGRP configuration

We will start by configuring AS 100, then AS 300 and AS 200. At this stage we are not adding the loopback interface on R3 into any AS:
R1(config)#router eigrp 100
R1(config-router)#network 10.1.6.0 0.0.0.255
R1(config-router)#

R6(config)#router eigrp 100
R6(config-router)#network 10.1.6.0 0.0.0.255
R6(config-router)#
%DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 10.1.6.1 (Ethernet0/0) is up: new adjacency
R6(config-router)#network 10.1.5.0 0.0.0.255
R6(config-router)#

R4(config)#router eigrp 100
R4(config-router)#network 10.1.5.0 0.0.0.255
R4(config-router)#
%DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 10.1.5.6 (Ethernet0/1) is up: new adjacency
R4(config-router)#
R4(config-router)#network 10.1.4.0 0.0.0.255
R4(config-router)#

R5(config)#router eigrp 100
R5(config-router)#network 10.1.4.0 0.0.0.255
R5(config-router)#
%DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 10.1.4.4 (Ethernet0/1) is up: new adjacency
R5(config-router)#network 10.1.3.0 0.0.0.255
R5(config-router)#

R3(config)#router eigrp 100
R3(config-router)#network 10.1.3.0 0.0.0.255
R3(config-router)#
%DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 10.1.3.5 (Ethernet0/1) is up: new adjacency
R3(config-router)#

R1(config-router)#exit
R1(config)#router eigrp 300
R1(config-router)#network 10.1.30.0 0.0.0.255
R1(config-router)#

R2(config)#router eigrp 300
R2(config-router)#network 10.1.30.0 0.0.0.255
R2(config-router)#
%DUAL-5-NBRCHANGE: EIGRP-IPv4 300: Neighbor 10.1.30.1 (Ethernet0/0) is up: new adjacency
R2(config-router)#
R2(config-router)#exit
R2(config)#router eigrp 200
R2(config-router)#network 10.1.20.0 0.0.0.255
R2(config-router)#

R3(config-router)#exit
R3(config)#router eigrp 200
R3(config-router)#network 10.1.20.0 0.0.0.255
R3(config-router)#
%DUAL-5-NBRCHANGE: EIGRP-IPv4 200: Neighbor 10.1.20.2 (Ethernet0/0) is up: new adjacency
R3(config-router)#
R3(config-router)#
With this basic setup, what is R1's view of the world?
R1#sh ip route eigrp | b Gate
Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks
D        10.1.3.0/24 [90/358400] via 10.1.6.6, 00:02:16, Ethernet0/1
D        10.1.4.0/24 [90/332800] via 10.1.6.6, 00:02:51, Ethernet0/1
D        10.1.5.0/24 [90/307200] via 10.1.6.6, 00:03:29, Ethernet0/1
R1#
We can see all of the prefixes in AS 100, but none in AS 200. We will not see the AS 300 link, as this will show as a connected route. Let's add the loopback to both of R3's EIGRP AS configurations, and see which R1 prefers.
R3(config-router)#router eigrp 100
R3(config-router)#network 1.1.1.1 0.0.0.0
R3(config-router)#router eigrp 200
R3(config-router)#network 1.1.1.1 0.0.0.0
R3(config-router)#

R1#sh ip route eigrp | b Gate
Gateway of last resort is not set

      1.0.0.0/32 is subnetted, 1 subnets
D        1.1.1.1 [90/486400] via 10.1.6.6, 00:00:23, Ethernet0/1
      10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks
D        10.1.3.0/24 [90/358400] via 10.1.6.6, 00:05:29, Ethernet0/1
D        10.1.4.0/24 [90/332800] via 10.1.6.6, 00:06:04, Ethernet0/1
D        10.1.5.0/24 [90/307200] via 10.1.6.6, 00:06:42, Ethernet0/1
R1#
So, we can now see it, and it prefers the one through R6. For R1 to see it through AS 200 and AS 300, we must perform some redistribution on R2:
R2(config-router)#router eigrp 200
R2(config-router)#redistribute eigrp 300
R2(config-router)#router eigrp 300
R2(config-router)#redistribute eigrp 200
R2(config-router)#
R1 can now see the prefixes originated by AS 200:
R1#sh ip route eigrp | b Gate
Gateway of last resort is not set

      1.0.0.0/32 is subnetted, 1 subnets
D        1.1.1.1 [90/486400] via 10.1.6.6, 00:02:24, Ethernet0/1
      10.0.0.0/8 is variably subnetted, 8 subnets, 2 masks
D        10.1.3.0/24 [90/358400] via 10.1.6.6, 00:07:30, Ethernet0/1
D        10.1.4.0/24 [90/332800] via 10.1.6.6, 00:08:05, Ethernet0/1
D        10.1.5.0/24 [90/307200] via 10.1.6.6, 00:08:43, Ethernet0/1
D EX     10.1.20.0/24 [170/307200] via 10.1.30.2, 00:00:55, Ethernet0/0
R1#
Without redistribution, as above, two EIGRP AS's are completely separated. So we need to redistribute from one AS to another (A to B), and to make sure that the traffic can get back again, from B to A. Nevertheless, we still prefer the route to 1.1.1.1 through R6.

Notice the difference we have for the AS 200 route. It is displayed as "D EX", meaning it is an external EIGRP route, and has a higher metric, 170 instead of 90. Let's dig in a bit further and see if R1 actually knows about the 1.1.1.1 network from AS 300:
R1#sh ip eigrp topology 1.1.1.1/32
EIGRP-IPv4 Topology Entry for AS(100)/ID(10.1.30.1) for 1.1.1.1/32
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 486400
  Descriptor Blocks:
  10.1.6.6 (Ethernet0/1), from 10.1.6.6, Send flag is 0x0
      Composite metric is (486400/460800), route is Internal
      Vector metric:
        Minimum bandwidth is 10000 Kbit
        Total delay is 9000 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 4
        Originating router is 1.1.1.1
EIGRP-IPv4 Topology Entry for AS(300)/ID(10.1.30.1) for 1.1.1.1/32
  State is Passive, Query origin flag is 1, 0 Successor(s), FD is Infinity
  Descriptor Blocks:
  10.1.30.2 (Ethernet0/0), from 10.1.30.2, Send flag is 0x0
      Composite metric is (435200/409600), route is External
      Vector metric:
        Minimum bandwidth is 10000 Kbit
        Total delay is 7000 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 2
        Originating router is 10.1.30.2
      External data:
        AS number of route is 200
        External protocol is EIGRP, external metric is 409600
        Administrator tag is 0 (0x00000000)
R1#
It does, but it still prefers the internal EIGRP route, even though the router through R2 is better, with a shorter hop count of 2 instead of 4, and it also has a better delay, which is used in calculating the best route.

EIGRP will always prefer internal routes to external routes. Internal EIGRP routes have a metric of 90, and external ones have a metric of 170. A lower metric will always be preferred. External EIGFRP routes are ones that come from redistribution, either between different EIGRP AS's, or via a different protocol. Which we will look at now, by switching EIGRP AS 200, to OSPF.
R2(config)#no router eigrp 200
R2(config)#
R2(config)#router ospf 200
R2(config-router)#network 10.1.20.0 0.0.0.255 area 0
R2(config-router)#

R3(config)#no router eigrp 200
R3(config)#
R3(config)#router ospf 200
R3(config-router)#network 10.1.20.0 0.0.0.255 area 0
R3(config-router)#
%OSPF-5-ADJCHG: Process 200, Nbr 10.1.30.2 on Ethernet0/0 from LOADING to FULL, Loading Done
R3(config-router)#
R3(config-router)#network 1.1.1.1 0.0.0.0 area 0
R3(config-router)#
R3(config-router)#

R2(config-router)#redistribute eigrp 300
R2(config-router)#
R2(config-router)#router eigrp 300
R2(config-router)#redistribute ospf 200 metric 10000 10 255 1 1500
R2(config-router)#
Now if we look at R1 again, we can see that we still know about the 10.1.20.0/24 network; it still appears as an external route, and we still prefer the internal EIGRP route to 1.1.1.1.
R1#sh ip route eigrp | b Gate
Gateway of last resort is not set

      1.0.0.0/32 is subnetted, 1 subnets
D        1.1.1.1 [90/486400] via 10.1.6.6, 00:29:56, Ethernet0/1
      10.0.0.0/8 is variably subnetted, 8 subnets, 2 masks
D        10.1.3.0/24 [90/358400] via 10.1.6.6, 00:35:02, Ethernet0/1
D        10.1.4.0/24 [90/332800] via 10.1.6.6, 00:35:37, Ethernet0/1
D        10.1.5.0/24 [90/307200] via 10.1.6.6, 00:36:15, Ethernet0/1
D EX     10.1.20.0/24 [170/284160] via 10.1.30.2, 00:01:00, Ethernet0/0
R1#
R1#sh ip eigrp topology 1.1.1.1/32
EIGRP-IPv4 Topology Entry for AS(100)/ID(10.1.30.1) for 1.1.1.1/32
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 486400
  Descriptor Blocks:
  10.1.6.6 (Ethernet0/1), from 10.1.6.6, Send flag is 0x0
      Composite metric is (486400/460800), route is Internal
      Vector metric:
        Minimum bandwidth is 10000 Kbit
        Total delay is 9000 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 4
        Originating router is 1.1.1.1
EIGRP-IPv4 Topology Entry for AS(300)/ID(10.1.30.1) for 1.1.1.1/32
  State is Passive, Query origin flag is 1, 0 Successor(s), FD is Infinity
  Descriptor Blocks:
  10.1.30.2 (Ethernet0/0), from 10.1.30.2, Send flag is 0x0
      Composite metric is (284160/258560), route is External
      Vector metric:
        Minimum bandwidth is 10000 Kbit
        Total delay is 1100 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 1
        Originating router is 10.1.30.2
      External data:
        AS number of route is 200
        External protocol is OSPF, external metric is 11
        Administrator tag is 0 (0x00000000)
R1#
This time though, we know that the route has originated through OSPF, and into EIGRP AS 300.

In a nutshell, the difference between internal EIGRP and external EIGRP is that external routes come to us through redistribution, either between different EIGRP AS's, or through a different protocol, such as OSPF.

To read more about EIGRP, grab a copy of CCNA and Beyond!

CCNA v3.0: Why you should not be scared!

Cisco have just announced an update to the CCNA exam(s), moving from version 2.0 to 3.0:

"The CCNA Routing and Switching exams and trainings are being revised from v2.0 to v3.0. Candidates can choose to take either the version 2.0 exams or version 3.0 exams. The last day to test for the 200-120 CCNA v2.0 and 100-101 ICND1 v2.0 exams will be August 20, 2016. The last day to test for the 200-101 ICND2 v2.0 exam will be September 24, 2016.".

CCNA exam updated to v3.0

In this post we will look at the changes and what they mean to you, and how it will shape your certification studies!

Don't be scared!

Firstly, don't be scared. This is annoying, and Cisco do this fairly regularly across all certification tracks, at all levels. They take things out, and add things, and this is to keep in-line with market trends, and making sure that the exams are relevant. We will break down each section and highlight what is new, and then cover what has disappeared afterwards.

1.0 Network Fundamentals

Overview: More design and methodology
There is a large emphasis on network design in the CCNA v3.0. It's bringing in elements of the CCDA certification, which will actually make it easier if you decide to pursue that qualification.

1.3 Describe the impact of infrastructure components in an enterprise network
1.3.a Firewalls
1.3.b Access points
1.3.c Wireless controllers

The key here is that we only need to describe them, not configure them. Probably a few hours of reading, and I'll do some blog posts about these.

1.4 Describe the effects of cloud resources on enterprise network architecture
1.4.a Traffic path to internal and external cloud services
1.4.b Virtual services
1.4.c Basic virtual network infrastructure

This is new and is all about Cisco embracing Cloud services, again, this is something they are doing across all of the certification tracks. We will look at these in separate posts.

1.5 Compare and contrast collapsed core and three-tier architectures

This is design-based, similar to the next section.

1.6 Compare and contrast network topologies
1.6.a Star
1.6.b Mesh
1.6.c Hybrid

As with 1.5, these are design considerations. We'll cover these in some blog posts.

1.8 Apply troubleshooting methodologies to resolve problems
1.8.a Perform and document fault isolation
1.8.b Resolve or escalate
1.8.c Verify and monitor resolution

There are a number of different methodologies, but Cisco will probably favor their own approach. Stay tuned for a post on these.

2.0 LAN Switching Technologies

Overview: Not a huge change!
Minor changes here (in what's been added), the biggest being the different types of access ports, and the inclusion of LLDP and the switch stacking and chassis aggregation.

2.4 Configure, verify, and troubleshoot VLANs (normal/extended range) spanning multiple switches
2.4.a Access ports (data and voice)
2.4.b Default VLAN
2.8 Configure and verify Layer 2 protocols
2.8.a Cisco Discovery Protocol
2.8.b LLDP
2.10 Describe the benefits of switch stacking and chassis aggregation

Much of this section remains unchanged, and the new bits will be covered here.

3.0 Routing Technologies

Overview: Nothing to sweat over!
Frame rewrite is new to the syllabus, and there are a couple of little bits added (routing protocol codes for example). The biggest change is that OSPF is no longer restricted to single areas, which is great!

3.1 Describe the routing concepts
3.1.c Frame rewrite
3.2 Interpret the components of a routing table
3.2.d Routing protocol code
3.2.e Administrative distance
3.8 Configure, verify, and troubleshoot IPv4 and IPv6 static routing
3.8.b Network route
3.8.c Host route
3.8.d Floating static
3.9 Configure, verify, and troubleshoot single area and multi-area OSPFv2 for IPv4 
(excluding authentication, filtering, manual summarization, redistribution, stub, virtual-link, and LSAs)
3.10 Configure, verify, and troubleshoot single area and multi-area OSPFv3 for IPv6
(excluding authentication, filtering, manual summarization, redistribution, stub, virtual-link, and LSAs)
3.13 Configure, verify, and troubleshoot RIPv2 for IPv4 
(excluding authentication, filtering, manual summarization, redistribution)

In CCNA and Beyond I actually cover multi-area OSPF already, because you need to know this. I was surprised that it was not on the v2.0 syllabus. In the book I explain how multi-area OSPF works, why single areas are easier, but not always suitable (especially in terms of scalability). I also cover redistribution, stub areas, virtual links and LSAs.

Similarly with EIGRP I also cover redistribution, as it is something you should know as an engineer!

I am surprised that RIP is included, but I cover that in the CCNA and Beyond study guide as well!

4.0 WAN Technologies

Overview: Some new things here! MLPPP, GRE and WAN topologies, as well as the newer WAN access connectivity options. BGP is new to the syllabus, as is QoS.

4.1 Configure and verify PPP and MLPPP on WAN interfaces using local authentication
4.3 Configure, verify, and troubleshoot GRE tunnel connectivity
4.4 Describe WAN topology options
4.4.a Point-to-point
4.4.b Hub and spoke
4.4.c Full mesh
4.4.d Single vs dual-homed
4.5 Describe WAN access connectivity options
4.5.a MPLS
4.5.b Metro Ethernet
4.5.c Broadband PPPoE
4.5.d Internet VPN (DMVPN, site-to-site VPN, client VPN)
4.6 Configure and verify single-homed branch connectivity using eBGP IPv4 
(limited to peering and route advertisement using Network command only)
4.7 Describe basic QoS concepts
4.7.a Marking
4.7.b Device trust
4.7.c Prioritization
4.7.c. [i] Voice
4.7.c. [ii] Video
4.7.c. [iii] Data
4.7.d Shaping
4.7.e Policing
4.7.f Congestion management

I have written books on BGP, MPLS, and different VPNs already, and also have a poll over on 802101.com to see how many people are interested in one on QoS (and Multicast), but will cover these here as well. These will be some full-scale labs, certainly for MPLS and BGP (QoS is a little harder to lab properly, at least what I call "properly").

If you are interested in something a little deeper, then check out BGP for Cisco networks, MPLS for Cisco networks, and VPNs and NAT for Cisco networks. They are on Amazon, and you will love them!

5.0 Infrastructure Services

Overview: Minor additions here. DNS, DHCP and HSRP were in the v2.0, but it looks like this is a little more focussed.

5.1 Describe DNS lookup operation
5.2 Troubleshoot client connectivity issues involving DNS
5.3 Configure and verify DHCP on a router (excluding static reservations)
5.3.a Server
5.3.b Relay
5.3.c Client
5.3.d TFTP, DNS, and gateway options
5.5 Configure, verify, and troubleshoot basic HSRP
5.5.a Priority
5.5.b Preemption
5.5.c Version

These topics are covered in the CCNA and Beyond book already.

6.0 Infrastructure Services

Overview: Section 6.2 is new, as is 6.4, and 6.6. 6.5 just adds a little extra.

6.2 Describe common access layer threat mitigation techniques
6.2.a 802.1x
6.2.b DHCP snooping
6.2.c Nondefault native VLAN
6.3 Configure, verify, and troubleshoot IPv4 and IPv6 access list for traffic filtering
6.3.a Standard
6.3.b Extended
6.3.c Named
6.4 Verify ACLs using the APIC-EM Path Trace ACL analysis tool
6.5 Configure, verify, and troubleshoot basic device hardening
6.5.a Local authentication
6.5.b Secure password
6.5.c Access to device
6.5.c. [i] Source address
6.5.c. [ii] Telnet/SSH
6.5.d Login banner
6.6 Describe device security using AAA with TACACS+ and RADIUS

Section 6.5 is covered pretty well in CCNA and Beyond, and we do touch on AAA, TACACS+ and RADIUS. These will be covered in separate posts on here though.

7.0 Infrastructure Management

Overview: Some cool additions here! Nothing scary, mostly logical additions to existing topics.

7.2 Troubleshoot network connectivity issues using ICMP echo-based IP SLA
7.3 Configure and verify device management
7.3.a Backup and restore device configuration
7.3.b Using Cisco Discovery Protocol or LLDP for device discovery
7.3.c Licensing
7.3.d Logging
7.3.e Timezone
7.3.f Loopback
7.4 Configure and verify initial device configuration
7.5 Perform device maintenance
7.5.a Cisco IOS upgrades and recovery (SCP, FTP, TFTP, and MD5 verify)
7.5.b Password recovery and configuration register
7.5.c File system management
7.6 Use Cisco IOS tools to troubleshoot and resolve problems
7.6.a Ping and traceroute with extended option
7.6.b Terminal monitor
7.6.c Log events
7.6.d Local SPAN
7.7 Describe network programmability in enterprise network architecture
7.7.a Function of a controller
7.7.b Separation of control plane and data plane
7.7.c Northbound and southbound APIs

I covered IP SLA in my previous post (explaining why in a particular scenario, floating static routes and IP SLA were a better option than HSRP). Most of the core items are covered in CCNA and Beyond (it goes into the configuration register in great depth, as well as password recovery, device management, logging and so on). We will cover Local SPAN (and Remote SPAN because it makes sense to cover both), as well as LLDP in separate posts here. Network programmability will be covered over a series of posts.

What's been removed from the CCNA v3.0?

Most noticeably, Frame Relay has gone. I said (in CCNA and Beyond) that I would expect it to disappear at some stage and it looks like I was correct! Apart from that, not much has actually been removed. Some things have been simplified though.

Overall thoughts.

Most of the new things make a lot of sense, and the harder topics, such as QoS are "describe" only. It really looks like Cisco is trying to bridge some of the huge gap between the CCNA and the CCNP certification exams, which, believe me, is a good thing.

Most importantly, don't worry too much. There is still time to sit the v2.0 exam(s) if you want, and we will cover ALL the new topics here, in a mixture of discussion and labs.

If you sign up to the newsletter, you will get access to the members section of the forum. In there will be some cool stuff, by way of labs, downloadable memory sheets for the different topics, and whatever else I can think of, or that you would like to see.

Many of the new topics (and more) are already covered in the CCNA and Beyond study guide, so do yourself a favor and grab it from Amazon!

You can get the full list of the CCNA v3.0 exam topics from here: https://learningnetwork.cisco.com/community/certifications/ccna/ccna-exam/exam-topics

Answering the question: IP SLA vs. HSRP (and other FHRPs)

There was a question posted in a Facebook CCNA group today, regarding redundancy over different ISP links, and whilst the suggestions were good, most favoured HSRP, or one of the other FHRP protocols, over something like IP SLA.

So, first of all, the question, from Jeril Abraham is:

Hi all,
There are two static router to different ISP like this.
10.0.0.0 255.255.255.0 172.14.35.8-ISP1
11.0.0.0 255.255.255.0 172.35.26.8-ISP2
so my question is, The ISP one is went down so is it possible to divert the all traffic to ISP2 automatically?

thanks in adv


OK, so, we have two destinations, via different ISPs. Let's visualize this:
IP SLA vs. HSRP, VRRP and GLBP

We need to get from the Source router to the Destination router. Let's make a simple configuration, and start by confirming access:
Source(config)#int gi0/0
Source(config-if)#ip add 172.14.35.10 255.255.255.0
Source(config-if)#no shut
Source(config-if)#int gi0/1
Source(config-if)#ip add 172.35.26.10 255.255.255.0
Source(config-if)#no shut
Source(config-if)#exit
Source(config)#ip route 10.0.0.0 255.255.255.0 172.14.35.8
Source(config)#ip route 11.0.0.0 255.255.255.0 172.35.26.8
Source(config)#

ISP-1(config)#int gi 0/0
ISP-1(config-if)#ip add 172.14.35.8 255.255.255.0
ISP-1(config-if)#no shut
ISP-1(config-if)#int gi 
ISP-1(config-if)#ip add 1.1.1.1 255.255.255.0
ISP-1(config-if)#no shut
ISP-1(config-if)#
ISP-1(config-if)#ip route 0.0.0.0 0.0.0.0 1.1.1.2
ISP-1(config)#

ISP-2(config)#int gi0/0
ISP-2(config-if)#ip add 172.35.26.8 255.255.255.0
ISP-2(config-if)#no shut
ISP-2(config-if)#int gi 0/1
ISP-2(config-if)#ip add 1.1.2.1 255.255.255.0
ISP-2(config-if)#no shut
ISP-2(config-if)#ip route 0.0.0.0 0
ISP-2(config)#

Destination(config)#int gi0/0
Destination(config-if)#ip add 1.1.1.2 255.255.255.0
Destination(config-if)#no shut
Destination(config-if)#int gi 0/1
Destination(config-if)#ip add 1.1.2.2 255.255.255.0
Destination(config-if)#no shut
Destination(config-if)#int lo10
Destination(config-if)#ip add 10.0.0.1 255.255.255.0
Destination(config-if)#
Destination(config-if)#int lo11
Destination(config-if)#
Destination(config-if)#ip add 11.0.0.1 255.255.255.0
Destination(config-if)#
Destination(config-if)#ip route 172.14.35.0 255.255.255.0 1.1.1.1
Destination(config)#ip route 172.35.26.0 255.255.255.0 1.1.2.1
Destination(config)#
With this, we should be able to get from the Source to the Destination:
Source#ping 10.0.0.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/6 ms
Source#ping 11.0.0.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 11.0.0.1, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 4/4/5 ms
Source#
And we can. We can also see that the routes taken are the ones we would expect:
Source#trace 10.0.0.1 num
Type escape sequence to abort.
Tracing the route to 10.0.0.1
VRF info: (vrf in name/id, vrf out name/id)
  1 172.14.35.8 4 msec 4 msec 4 msec
  2 1.1.1.2 5 msec *  4 msec
Source#trace 11.0.0.1 num
Type escape sequence to abort.
Tracing the route to 11.0.0.1
VRF info: (vrf in name/id, vrf out name/id)
  1 172.35.26.8 3 msec 3 msec 3 msec
  2 1.1.2.2 5 msec *  5 msec
Source#
So, before we look at the solution, let's explain why HSRP (and by extension, VRRP and GLBP which make up the FHRP, or First Hop Redundancy Protocols) are not the the right solution in this instance.

When is FHRP the wrong choice?

Look at the topology we have here. We connect from the source to two different ISPs. We only have one source, and will have no control over the ISP routers, so who would we create an HSRP group with? To use any FHRP solution, we would need another router within our own environment, something a little more like this:


We would have two routers, Source-1 and Source-2, and they would be joined in an HSRP group, providing the internal users and devices with a virtual IP address to connect to. In the event that one router went down, the other would take over.

Back to our conundrum. How would we provide the redundancy we need? The answer here would either be through floating static routes, redistribution from the ISP, or IP SLA.

Floating static routes

Floating static routes would be the easiest option, but on their own, only have limited success. We supply the initial routes (as we have already done above), then add a second route via a different next-hop, with a higher metric, such as:
Source(config)#do sh run | i ip route
ip route 10.0.0.0 255.255.255.0 172.14.35.8
ip route 11.0.0.0 255.255.255.0 172.35.26.8
Source(config)#ip route 10.0.0.0 255.255.255.0 172.35.26.8 50
Source(config)#ip route 11.0.0.0 255.255.255.0 172.14.35.8 50
Source(config)#
Source(config)#do sh run | i ip route                        
ip route 10.0.0.0 255.255.255.0 172.14.35.8
ip route 10.0.0.0 255.255.255.0 172.35.26.8 50
ip route 11.0.0.0 255.255.255.0 172.35.26.8
ip route 11.0.0.0 255.255.255.0 172.14.35.8 50
Source(config)#do sh ip route | b Gate
Gateway of last resort is not set

      10.0.0.0/24 is subnetted, 1 subnets
S        10.0.0.0 [1/0] via 172.14.35.8
      11.0.0.0/24 is subnetted, 1 subnets
S        11.0.0.0 [1/0] via 172.35.26.8
      172.14.0.0/16 is variably subnetted, 2 subnets, 2 masks
C        172.14.35.0/24 is directly connected, GigabitEthernet0/0
L        172.14.35.10/32 is directly connected, GigabitEthernet0/0
      172.35.0.0/16 is variably subnetted, 2 subnets, 2 masks
C        172.35.26.0/24 is directly connected, GigabitEthernet0/1
L        172.35.26.10/32 is directly connected, GigabitEthernet0/1
Source(config)#
How well does this work? Let's test by shutting down the Gi0/0 interface on ISP-1:
ISP-1(config)#int gi0/0
ISP-1(config-if)#shut
ISP-1(config-if)#
%LINK-5-CHANGED: Interface GigabitEthernet0/0, changed state to administratively down
%LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/0, changed state to down
ISP-1(config-if)#
This does not really work that well though, so simulating a failure on the ISP-1 router, has little effect on our routing table:
Source#sh ip route 10.0.0.0   
Routing entry for 10.0.0.0/24, 1 known subnets
S        10.0.0.0 [1/0] via 172.14.35.8
Source#
Let's turn the ISP-1 interface back up and turn our interface down, then see what effect this has:
ISP-1(config-if)#no shut
ISP-1(config-if)#
%LINK-3-UPDOWN: Interface GigabitEthernet0/0, changed state to up
%LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/0, changed state to up
ISP-1(config-if)#

Source(config)#int gi0/0
Source(config-if)#shut
Source(config-if)#
%LINK-5-CHANGED: Interface GigabitEthernet0/0, changed state to administratively down
%LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/0, changed state to down
Source(config-if)#
Source(config-if)#do sh ip route 10.0.0.0
Routing entry for 10.0.0.0/24, 1 known subnets
S        10.0.0.0 [50/0] via 172.35.26.8
Source(config-if)#
Source(config-if)#do ping 10.0.0.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/5 ms
Source(config-if)#
This works, we can send all our traffic through ISP-2 and get to 10.0.0.1, but shows that the floating static route only really works if the problem lies with us, not with an upstream device. Let's turn the network up a notch and set ip IP SLA tracking.

IP SLA

IP SLA is a feature that allows you to implement some monitoring of a line, we can use it to ping devices and if a failure is detected, make changes appropriately.

We will do this by adding another loopback address to the Destination router, and track that. We will also turn the interface on the Source back on, and remove the floating static routes.
Source(config-if)#no shut
Source(config-if)#
*May 14 15:34:43.044: %LINK-3-UPDOWN: Interface GigabitEthernet0/0, changed state to up
*May 14 15:34:44.043: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/0, changed state to up
Source(config-if)#
Source(config-if)#do sh run | i i proute
Source(config-if)#do sh run | i ip route
ip route 10.0.0.0 255.255.255.0 172.14.35.8
ip route 10.0.0.0 255.255.255.0 172.35.26.8 50
ip route 11.0.0.0 255.255.255.0 172.35.26.8
ip route 11.0.0.0 255.255.255.0 172.14.35.8 50
Source(config-if)#no ip route 10.0.0.0 255.255.255.0 172.35.26.8 50
Source(config)#no ip route 11.0.0.0 255.255.255.0 172.14.35.8 50
Source(config)#

Destination(config)#int lo8
Destination(config-if)#
Destination(config-if)#desc We will track this interface
Destination(config-if)#
Destination(config-if)#ip add 8.8.8.8 255.255.255.255
Destination(config-if)#

Source(config)#ip route 8.8.8.8 255.255.255.255 172.14.35.8
Source(config)#ip route 8.8.8.8 255.255.255.255 172.35.26.8
Source(config)#
Source(config)#do sh ip route 8.8.8.8
Routing entry for 8.8.8.8/32
  Known via "static", distance 1, metric 0
  Routing Descriptor Blocks:
    172.35.26.8
      Route metric is 0, traffic share count is 1
  * 172.14.35.8
      Route metric is 0, traffic share count is 1
Source(config)#do ping 8.8.8.8
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/5 ms
Source(config)#do trace 8.8.8.8
Type escape sequence to abort.
Tracing the route to 8.8.8.8
VRF info: (vrf in name/id, vrf out name/id)
  1 172.14.35.8 4 msec
Source(config)#do trace 8.8.8.8 num
Type escape sequence to abort.
Tracing the route to 8.8.8.8
VRF info: (vrf in name/id, vrf out name/id)
  1 172.14.35.8 4 msec
    172.35.26.8 4 msec
    172.14.35.8 6 msec
  2 1.1.2.2 4 msec
    1.1.1.2 4 msec * 
Source(config)#
Notice the routing table and the trace, this shows that both routes are working at the same time. Now let's set up tracking!
Source(config)#ip sla 10 
Source(config-ip-sla)#icmp-echo 8.8.8.8 source-interface gigabitEthernet 0/0 
Source(config-ip-sla-echo)#frequency 5
Source(config-ip-sla-echo)#exit 
Source(config)#ip sla sched 10 life forever start-time now
Source(config)#track 10 ip sla 10 reachability
Source(config-track)#exit
Source(config)#
Source(config)#ip route 10.0.0.0 255.255.255.0 172.14.35.8 track 10
Source(config)#
Source(config)#do sh run | i ip route
ip route 10.0.0.0 255.255.255.0 172.14.35.8 track 10
ip route 8.8.8.8 255.255.255.255 172.14.35.8
ip route 8.8.8.8 255.255.255.255 172.35.26.8
ip route 10.0.0.0 255.255.255.0 172.14.35.8
ip route 11.0.0.0 255.255.255.0 172.35.26.8
Source(config)#no ip route 10.0.0.0 255.255.255.0 172.14.35.8
Source(config)#end
Source#
We start by creating an IP SLA entry, with a number. We then use an ICMP echo to track the IP address 8.8.8.8, through our Gi0/0 interface. We send five pings, we need to schedule it to start, and also set up a tracking object that references the SLA entry we created first.

Let's test this. Firstly, by making sure that our tracking is working, then by taking the interface down on ISP-1, and seeing what happens:
Source#show track
Track 10
  IP SLA 10 reachability
  Reachability is Up
    1 change, last change 00:00:51
  Latest operation return code: OK
  Latest RTT (millisecs) 5
  Tracked by:
    Static IP Routing 0
Source#

ISP-1(config)#int gi0/0
ISP-1(config-if)#shut
ISP-1(config-if)#
ISP-1(config-if)#
*May 14 15:48:58.593: %LINK-5-CHANGED: Interface GigabitEthernet0/0, changed state to administratively down
*May 14 15:48:59.592: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/0, changed state to down
ISP-1(config-if)#

Source#
*May 14 15:49:08.666: %TRACK-6-STATE: 10 ip sla 10 reachability Up -> Down
Source#
Source#show track
Track 10
  IP SLA 10 reachability
  Reachability is Down
    2 changes, last change 00:00:06
  Latest operation return code: Timeout
  Tracked by:
    Static IP Routing 0
Source#

Source#sh ip route 10.0.0.0
% Network not in table
Source#
So we have lost the network, but can add it in again, using the floating static route, as before:
Source(config)#ip route 10.0.0.0 255.255.255.0 172.35.26.8 50
Source(config)#
Source(config)#do sh ip route 10.0.0.0
Routing entry for 10.0.0.0/24, 1 known subnets
S        10.0.0.0 [50/0] via 172.35.26.8
Source(config)#do ping 10.0.0.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/5/8 ms
Source(config)#

ISP-1(config)#int gi0/0
ISP-1(config-if)#no shut
ISP-1(config-if)#

Source(config)#
*May 14 16:13:03.755: %TRACK-6-STATE: 10 ip sla 10 reachability Down -> Up
Source(config)#
Source(config)#do sh ip route 10.0.0.0
Routing entry for 10.0.0.0/24, 1 known subnets
S        10.0.0.0 [1/0] via 172.14.35.8
Source(config)#
So now, if we lose the access through ISP-1 to the 10.0.0.0/24 network, we will go through ISP-2. Let's try once more, and see what happens (this time simulating a failure elsewhere in the network):
Destination(config)#int lo8
Destination(config-if)#shut
Destination(config-if)#
*May 14 16:14:42.302: %LINK-5-CHANGED: Interface Loopback8, changed state to administratively down
*May 14 16:14:43.302: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback8, changed state to down
Destination(config-if)#

Source(config)#do sh ip route 10.0.0.0
Routing entry for 10.0.0.0/24, 1 known subnets
S        10.0.0.0 [1/0] via 172.14.35.8
Source(config)#
*May 14 16:14:43.761: %TRACK-6-STATE: 10 ip sla 10 reachability Up -> Down
Source(config)#                       
Source(config)#do sh ip route 10.0.0.0
Routing entry for 10.0.0.0/24, 1 known subnets
S        10.0.0.0 [50/0] via 172.35.26.8
Source(config)#
Above, if we shut down the Lo8 interface on the destination (the object we are tracking), our traffic goes through ISP-2. Let's add another tracker, and protect all our routes!
Destination(config-if)#no shut
Destination(config-if)#
Destination(config-if)#
*May 14 16:16:37.442: %LINK-3-UPDOWN: Interface Loopback8, changed state to up
*May 14 16:16:38.445: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback8, changed state to up
Destination(config-if)#

Source(config)#do sh run | i ip route
ip route 10.0.0.0 255.255.255.0 172.14.35.8 track 10
ip route 8.8.8.8 255.255.255.255 172.14.35.8
ip route 8.8.8.8 255.255.255.255 172.35.26.8
ip route 10.0.0.0 255.255.255.0 172.35.26.8 50
ip route 11.0.0.0 255.255.255.0 172.35.26.8
Source(config)#
Source(config)#no ip route 11.0.0.0 255.255.255.0 172.35.26.8
Source(config)#ip route 11.0.0.0 255.255.255.0 172.35.26.8 track 11
Source(config)#ip route 11.0.0.0 255.255.255.0 172.14.35.8 50
Source(config)#
Source(config)#ip sla 11
Source(config-ip-sla)#icmp-echo 8.8.8.8 source-interface gigabitEthernet 0/1
Source(config-ip-sla-echo)#freq 5
Source(config-ip-sla-echo)#exi
Source(config)#ip sla schedule 11 life forever start-time now
Source(config)#
Source(config)#track 11 ip sla 11 reachability
Source(config-track)#exi
Source(config)#
So, if all is good, then traffic to 10.0.0.1 should go through ISP-1 and traffic for 11.0.0.1 should go through ISP-2. If 8.8.8.8 goes down, then this traffic should switch ISPs:
Source#trace 10.0.0.1 num
Type escape sequence to abort.
Tracing the route to 10.0.0.1
VRF info: (vrf in name/id, vrf out name/id)
  1 172.14.35.8 5 msec 3 msec 4 msec
  2 1.1.1.2 5 msec *  4 msec
Source#trace 11.0.0.1 num
Type escape sequence to abort.
Tracing the route to 11.0.0.1
VRF info: (vrf in name/id, vrf out name/id)
  1 172.35.26.8 4 msec 3 msec 3 msec
  2 1.1.2.2 4 msec *  5 msec
Source#

Destination(config)#int lo8
Destination(config-if)#shut
Destination(config-if)#
*May 14 16:30:25.463: %LINK-5-CHANGED: Interface Loopback8, changed state to administratively down
*May 14 16:30:26.464: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback8, changed state to down
Destination(config-if)#

Source#
*May 14 16:30:28.822: %TRACK-6-STATE: 10 ip sla 10 reachability Up -> Down
*May 14 16:30:28.823: %TRACK-6-STATE: 11 ip sla 11 reachability Up -> Down
Source#
Source#trace 10.0.0.1 num
Type escape sequence to abort.
Tracing the route to 10.0.0.1
VRF info: (vrf in name/id, vrf out name/id)
  1 172.35.26.8 3 msec 3 msec 3 msec
  2 1.1.2.2 5 msec *  6 msec
Source#
Source#trace 11.0.0.1 num
Type escape sequence to abort.
Tracing the route to 11.0.0.1
VRF info: (vrf in name/id, vrf out name/id)
  1 172.14.35.8 4 msec 3 msec 3 msec
  2 1.1.1.2 5 msec *  4 msec
Source#
Source#
IP SLA works really well, in conjunction with floating atatic routes, and can be used to redirect traffic within a few seconds.

In the real-world though, you would track more than one address, so that in the event that it is a particular end-point thats failed, outside of your network, you don't go reconfiguring the network for everyone. Instead you would track three addresses (or so), and then if all three fail, chances are the linked is messed up, at which point failing over to a different link would be a good idea.

HSRP, VRRP and GLBP are all covered in the CCNA and Beyond study guide, which you can purchase now, or read a sample.

You can download the UNetLab file for this here.

Free sample of the CCNA and Beyond study guide

I thought it might be a good idea to put up a free sample of the CCNA and Beyond study guide.

Free sample of the CCNA and Beyond study guide


It's a PDF, but embedded into the page for you to read, all I ask is that you show a little bit of social love through Twitter, Facebook, or Google Plus.

It is just a short extract of a few different bits, and is designed to give you a feel for the layout, and writing style of the book. I did try to include the table of contents, but Word had an issue with the TOC, so I removed it from the sample. Overall, the book runs to over 500 pages.


Win the CCNA and Beyond study guide!

I am running a little competition where you can win a copy of the CCNA and Beyond study guide.

Win the CCNA and Beyond study guide

Head over to the Competitions page to take part.

The competition is open for six days.

Please take part, follow on Twitter, retweet or like on Facebook.

If it is popular, then I will run more competitions, with more prizes/bigger prizes and more ways to enter!


5 reasons why the CCNA is NOT a dying trade

I came across this post, on Why the CCNA is a dying trade, and felt that it deserved a counter-argument.

It is a well written article, but I feel that it is more cloud-focussed than the current market trend actually is.

How does cloud adoption affect you as a network engineer?

It is true that more and more companies are adopting cloud services, it alleviates the pressure on internal staff, allowing another company to take the pressure, whilst at the same time potentially having a cost-saving.

Nevertheless, there will always be a need for qualified network engineers (at all levels). This is for several reasons:

1: Cloud services still need network engineers. 

Although the likes of Amazon Web Services (AWS) and Google, use whitebox switches (custom written network operating systems), which allow for a more tuned network environment, more suited to the product, they still need engineers to manage them.

Whilst the CCNA will not teach you how to use this custom software, it will give you the overall knowledge of how switching and of how routing works, and this foundation is transferable to different vendor equipment.

2: Users of Cloud services still need network engineers

Most people work in an office. Offices have networking equipment. The network equipment needs someone to look after it.

There will still be a need to have trained people to configure the network, segment it for security using VLANs, configure the routing so that users can actually access the Cloud. Having a cloud presence is fine, but you still need to be able to access it!

3: It's not JUST about the Cloud

Similar to the above, not everything is getting Cloudified. Working within a company that offers a Cloud solution, I still look after racks of switches and firewalls. There is a wealth of software we use that is not in the Cloud, and our users need to access it.

4: SDN will not take over from hands-on configuration.

In the above post, Kieran states "it’s now all software defined networking and can be done by a relatively inexperienced (and cheap) technical resource, removing the need for those expensive Cisco engineers". SDN is great, it's so cool that networking tasks can be scripted, and SDN can make this a much more agile endeavour, But someone still needs to do the initial hardware installation, and that's if the equipment actually supports the API (Application Program Interface), not all router and switches do. Higher-end ones do, lower end ones, not so much.

If anything, SDN will make the network engineer a dual-threat, one who knows his (or her) routing and switching, as well as programming languages such as Python.

Returning to the post: "The thing is, a traditional engineer, taking days to configure switches, routers etc… has no place in the fast-paced cloud environment. If I can provision a new server in a couple of minutes". the initial configuration of a switch or router should not take days. If it does, then your methodology is wrong. Taking a switch as an example, it needs a hostname, management IP address, add it to VTP (so it gets the VLANs from the VTP server), and configure the ports as needed. This should be a day at the very most. After that, there will be the little tweaks and administration, as with any equipment.

In the same paragraph: "If I can provision a new server in a couple of minutes, I want to be able to utilize it as soon as possible and don’t want to wait for my engineer to configure it." This depends on the backend architecture. If it's cloud-based then someone else has already done the hard work in setting up the template systems. I can install an OS from a PXE server within a few minutes as well, run a few updates etc and it's good to go. This applies to virtual servers and physical servers, but these are only as good as the template used, and you can still spend quite a few hours installing updates to secure the system, and whatever software is required for the purpose of the machine. Management software like Puppet or Chef can expedite this, but still, hands-on time is required for the initial install.

5: There is an increase in number of jobs looking for CCNAs

One final quote from the article: "With all of this in mind, I would expect to see a year-on-year reduction in CCNA certified engineers in each of the companies that have already adopted the cloud and would expect to see a noticeable, industry-wide reduction in the next 5 years – with the financial sector being the last to relinquish control of their on-premise networks. My guess is that in 10 years CCNA will be a virtually forgotten qualification.".

Well, according to ITJobsWatch.co.uk, there is actually a rise in the number of job postings looking for CCNAs. In 2014 the number of permanent jobs citing CCNA was 1837, and in 2015 this rose to 2179. in the three months to May 2016, this figure stands at 1848, so has already beaten 2014's figure.

The salary has also risen, from about £35,000 in 2004 to around £40,000 in 2015/2016. Since 2004 there has been a 3-4% rise in the number of jobs stating CCNA as a preference (from about 4% to 7%). Expanding this forward, in ten years, one in ten jobs (in the sector) will be looking for a CCNA.

CCNA job demand in thee UK

So, if anything, the market shows that demand for CCNAs has increased, rather than decreased.

The cloud is great, but will never replace the network engineer, or the qualifications this entails.