Understanding Wildcard Masks

Introduction to Wildcard Masks
Before I begin, I should mention how important it is that you have solid binary to decimal and decimal to binary math skills.  In order to develop these masks (and understand them) at the the fastest speed possible, you need to know your math.  So if you are weak in this area, now would be a good time to practice!  Cisco has a binary math game on the Cisco Learning Network.  You can find it here, but note that you will need a Cisco login and username.  If you aren't on the Cisco Learning Network, I highly encourage you to sign up! They have great study resources and places where you can ask questions on concepts that you don't understand.


Wildcard Mask Logic
When you write an ACL statement, you identify the addresses that you want to either deny or permit access to by matching it with a wildcard mask.  The logic behind comparing an IP address with the mask is this:

• For each 0 in each octet of the wildcard mask, the IP address that is being compared against the network statement must match in the corresponding octet.
• At the binary level, each 0 must means the IP address binary must match the corresponding bit value of the network statement
• Anything other then zero indicates the acceptable range of IP addresses that do not have to match the network statement
• At the binary level, each 1 means that the IP address binary does not have to match the corresponding bit value of the network statement

It's likely that you may be confused after reading these "rules".  If so, write these down or copy and paste them into a file and compare the rules against the following examples as you go through them.

Also, before I get started with these, understand that there are shortcuts to creating wildcard masks, and once you get good at it, you can write them out much faster then breaking it down into the binary.  The problem is that if you don't understand what is happening at the binary level, you will really be missing out, especially when it comes to creating some more..interesting ACL statements (I'll throw in one at the bottom of this post).

Example 1
The following ACL would match any host with a source IP from the network 10.0.0.0/24 and apply the "deny" action, preventing the traffic from passing through the interface

deny ip 10.0.0.0 0.0.0.255

IP address 10.0.0.1 would match this statement.  Why?  Lets look at this at the bit level

wildcrd mask:  00000000.00000000.00000000.11111111

network addr: 00001010.00000000.00000000.00000000

ip address    :  00001010.00000000.00000000.00000001

In green, I have highlighted the bit values that must match, given the wildcard mask.  As you can see, the IP address will be matched as long as the bit values in the first three octets are the same-or the address begins with 10.0.0.X  and the fourth octet, as the wildcard mask is all 1's here, can be any value.  So network addresses 10.0.0.1-10.0.0.255 will be matched.

Excercise 1

Lets try a basic wildcard mask excersise.

Determine the range of addresses that will be matched and denied by the following ACL statement. 

deny ip 192.168.0.0 0.0.1.255

Begin by breaking down the network statement and wildcard masks down into binary.  Determine which bits must match, and which do not.  Finally, do the math on the bits that do not have to match to determine the acceptable range of addresses that will be matched by this statement.  When you think you have it, jump down to see the answer!

Excercise 1 answer: Addresses 192.168.0.1 - 192.168.1.255

Start by breaking down the network statement (192.168.0.0)  and wildcard mask (0.0.1.255) into their associated bits.

    mask : 00000000.00000000.00000001.11111111

network: 11000000.10101000.00000000.00000000

Now that you have your mask and network in binary form, you know which bit values must match.  Here, you can see that the address must at least be 192.168.X.X  for the first two octets.  The third octet can be confusing when you are doing this for the first time.  The wildcard mask is a 1 for the 8th bit value of the third octet.  Remembering the previous rules, you know that a "1" value means the mask does not check this bit.  Therefore, the bit can either be on or off, and the remaining octet is entirely composed of 1's.  Therefore, the acceptable range of possible network addresses is 192.168.0.1-192.168.1.255

Excercise 2: Determine if an Address will be matched

Given the following ACL statement, determine if address 192.10.16.224 will be matched

deny ip 192.10.0.0 0.0.15.255

Solve this by taking your network statement, wildcard mask, and IP address, and breaking them down into binary.  When you think you have the answer, jump down to check and see an explanation

Answer: No, because the range of addresses that will be matched is 192.10.0.1-192.10.15.255

Begin by breaking down your addresses into bit values.

mask:    00000000.00000000.00001111.11111111

network:11000000.00001010.00000000.00000000

address: 11000000.00001010.00010000.11100000

Now you see that when you break it down into binary, how simple the wildcard masks really become. As an added bonus, by repeating this practice, you get to improve on your binary to decimal math skills-a skill that in my opinion, is essential if you want any chance at passing the CCNA. In this above example, the "1" value in the address in the fourth digit of the third octet, does not match the mask!  According to the mask, that value must be a 0.  Since it is not, the address will not be matched and will be ignored.  How did I determine the acceptable range?  Math-you can see that the "1's" begin in the fifth digit of the third octet.  This place has a value of 8.  8+4+2+1 = 15.  So you know that in the third octet, the acceptable values are 0 through 15.  The fourth octet is composed entirely of 1's and is ignored by the mask.  Therefore, your acceptable range is 192.10.0.1-192.10.15.255

Shortcuts..

Some of you may be aware of a few shortcuts.  An example of one, is that the wildcard mask itself is the upper most limit of the value in each octet that can be matched.

0.0.15.255

is the same as our range 192.10.0.1-192.10.15.255

However, now I will show you the problem with relying entirely on shortcuts.  Lets say you have a network

10.0.0.0 and you want to only match IP addresses with an even number (maybe you have an eccentric networking scheme and all of your hosts have an even IP address).  So, you only want to match IP addresses 10.0.0.2, 10.0.0.4, 10.0.0.6, and so on.  How do you determine this?  Unfortunately, the shortcut method, will not work here.  You need to understand how this works at the bit level.  Breaking it down, you can see how you would perform this task:

mask:     00000000.00000000.00000000.11111110

network:00001010.00000000.00000000.00000000

Because the last value of the fourth octet must be turned "off", mathematically, you cannot have any odd numbers!  So, any IP address in the 10.0.0.X network with an even number in the fourth octet will be matched.

I find that the shortcuts can be handy-as long as you fully understand what is taking place when you apply them.  In my experience, if I rely only on the shortcuts, I tend to forget what is taking place, and I don't keep my understanding of the matching logic as sharp as I need to.  You can find a number of these shortcuts in other tutorials, but the only other one that I sometimes use is what I term the "magic number - 1" shortcut.  Say for example you wanted to build a wildcard mask that would block addresses in the 10.0.0.1-10.0.0.3 range.  You know that by looking at this range, this would be a /30 address.  The "magic number" (or incremental value) of a /30 is 4.  Subtract one, and you would get the value you would need for your wildcard mask, or 0.0.0.3.  At the binary level, we know this is true, because if you add the values of the last two bits together, you get 3.  So the mask 0.0.0.3 will match addresses 10.0.0.1, 10.0.0.2, and 10.0.0.3.  You know it won't match 10.0.0.4 and up because the values of those bits must be equal to 0 in order to be matched by the wildcard logic.

An Introduction to ACLs

Before I post up the lab, I'm going to cover some important topics in a series of posts:

• Introduction to ACLs
• Understanding Wildcard masks
• Standard and Extended ACL configuration
• ACL troubleshooting
• NAT configuration

Following these posts, I will tie everything in together in the lab.

So, what is an ACL and what does it do?
You might be asking, what is an ACL?  ACL stands for access control list.  It is a basic way of filtering traffic based on source and destination IP's, along with the type of traffic.  Thinking in terms of firewalls, an ACL would be an example of a stateless firewall (excluding reflexive ACL's, but more on that later.)  This means that this rudimentary firewall does not look at the "entire picture" of the conversation between two devices.  The ACL only inspects each individual packet based on source, destination, and type.  Stateful filters are considered to be more advanced because they are capable of reconstructing the "conversation" between two different devices.  This will become easier to understand if you try the lab.  Later on I intend to illustrate using a stateful firewall with this exact same topology, so it will be easier to see the differences between stateful and stateless inspection.

How does the router understand ACLs?
At the most basic level, a router uses an ACL to inspect a packet's header for the source IP, destination IP, and can then be further expanded on to match TCP and UDP port numbers and some other parameters.  Depending on the statements in the ACL, the router either decides to discard the packet, or allow it to pass.  The parameters as to what is to be inspected in the packet's header are configured in a series of ACL statements, which are processed in order of configuration.  If the packet matches a statement, it is either filtered or it is allowed to pass through.  At the end of every ACL is an implicit deny all statement-basically, if a packet comes into the interface, and does not match any of the statements, it will be dropped.  This is important to remember.

ACLs can be used for several other purposes (such as defining NAT pools and QoS) but I am only covering IP ACL's in this overview.  An IP ACL has two options if it matches a packet.  It can deny the packet, and drop it, or it can permit the packet, and allow it to pass.  We will use ACL's for NAT translation as well, but the concept is fairly similiar in that the permit keyword is used to instruct the router that matched packets are to be translated with NAT.

Placement of ACL's in terms of Direction
An ACL can be applied to a router interface either "in" or "out".  This can be a slightly confusing topic at first, and it can trip people up.  What this means is if you apply an ACL outbound on a router, the router inspects the traffic leaving that interface.  If you apply an ACL inbound on a router interface, the router inspects traffic entering the interface.  This may sound very simple, but its important not to overlook the placement of ACLs.  When you actually start configuring ACL's and you need to determine where you have to place them this concept can get start to become very confusing.
Personally, I like to picture a brick wall in front of the interface.  If I've applied the ACL inbound, I also picture a little arrow pointing towards the router.  If its outbound, the arrow is reversed.  It might also be helpful to draw this onto a piece of paper or whiteboard with your topology after you've configured the ACL's so you can keep track of what you've done and grasp the concept easier.

Example
To illustrate what I have covered so far, I am going to show a standard ACL statement.  There are two main "types" of ACL's that can be configured- standard ACL's and extended ACLs.  Standard ACLs filter based on matching the source IP address.  Extended ACLs can filter based on source and destination IP, source and destination port, and a few other parameters as well.  The placement of the ACLs varies depending on if it is a standard or extended ACL.

In this example, we have two routers, connected over the 10.0.0.0/30 WAN link.  Lets say that we want to prevent PC1 from sending traffic to PC2.  Using a standard ACL, best practice states to put a standard ACL on the interface closest to the destination you want to prevent traffic from reaching,  An extended ACL should be placed on the interface closest to the source IP.  The reason for this is fairly simple.  If we put an ACL on R2's serial interface, or on one of R1's interfaces, we might prevent legitmate traffic from PC1 from reaching other destinations-either in R2's network, or perhaps, beyond R2.  I've found that when it comes to configuring and troubleshooting problems with ACL's, where you've placed them, and what direction they are facing, tends to be the culprit of the problem.

To remember this, I think in terms of opposites: extended ---> close; and standard ---> far.  So take a look at the diagram, and remember that you want to prevent PC1 from sending traffic to PC2, but you still want it to be able to communicate with any other device within R1's network and R2's network.  Where would you place the ACL to accomplish this?

This is not the style that the entries are formatted in, but just to understand the concept, assume your ACL looks like this:
IF source = 10.1.0.100, deny
IF source = any, permit

Remember-the ACL processes the statements in order.  So if the 10.1.0.100 entry is not matched, the packet will be allowed to pass through the interface

Analysis
If you decided the correct location is R2's fa0/0 port, facing outbound, then you would be correct.  Putting the ACL anywhere else would not meet the requirements of this scenario.  If you put the ACL inbound on R1's fa0/0 interface, you would cut off PC1 from it's default gateway (R1 10.1.0.1), and subsequently, the rest of the topology.

If you placed the ACL on R2's serial port, facing inbound, you would prevent PC1 from communicating with R2 and any other network attached to R2.  You might wonder, what would happen if the ACL was placed outbound on R2's serial interface?  Considering that the standard ACL checks only on source IP, nothing would be filtered in this instance.  If PC1 pinged PC2, the packet would pass through R2 since the direction of the ACL is applied outbound.  When PC2 replied to PC1's ping, the source IP is now 10.2.0.100. which would not match the pseudo entry "IF source = 10.1.0.100, deny".

To wrap things up, remember some of the points I made above

• Standard ACL's are placed as close to the destination as possible
• Extended ACLs are placed as close to the source as possible
• Draw it out at first, or do what you need to do to picture the inbound versus outbound placement of ACLs.
• There is an implicit deny all statement at the end of every ACL

Passed the CCNA! Next step- CCNA: Security

I haven't been too active on here for the past couple of weeks as I was in my final studying stages for the CCNA, which I took and passed.  I plan to upload the rest of my CCNA level notes over the next week or so-I still want to do write about frame relay configuration, ACL's, and a few other topics before I move on to posting about my progress in working towards the CCNA: Security.

EIGRP Authentication

To illustrate the similarities (and differences) between OSPF and EIGRP, I will be using the same topology and IP addressing from my OSPF lab.

The assumed starting point with this lab is that all devices have been cabled, and IP addressing has been set on all serial, ethernet, and loopback adapters.  Since I already covered PPP authentication in my previous lab, you can either opt to enable it, or just enter encapsulation ppp on the interfaces and forgo the authentication.  EIGRP authentication will be enabled on the 10.0.0.0/8 network.

If you are continuing this lab directly after the OSPF lab, you can easily clear your OSPF settings, and keep everything else, by entering

R1(config)# no router ospf 1
R2(config)# no router ospf 1
R3(config)# no router ospf 1

Remember that with EIGRP, there aren't special neighbor relationship states like in OSPF.  Routers will either become neighbors with one another, or they will not, depending on if they pass the requirements to be neighbors-if you can't recall these, they are:

operating in the same subnet
both configured with the same AS number
matching K values
successful authentication

Interestingly, the hello timers do not need to match, however if you do modify the hello/dead timers, you need to ensure that the configuration will work, and a neighboring router's dead timer does not expire.

To begin, we will start at router R1.  Keeping in mind that we must use matching AS numbers, we will use the value 7 for our AS number on this network.  Like OSPF, EIGRP uses wildcard masks with its network statements.

R1(config)# router eigrp 7
R1(config-router)#network 10.0.0.0 255.0.0.0
R1(config-router)#network 172.30.1.0 0.0.0.255
R1(config-router)#network 192.100.254.0 0.0.0.3

R2(config)#router eigrp 7
R2(config-router)#network 10.0.0.0 255.0.0.0
R2(config-router)#network 172.30.2.0 0.0.0.255
R2(config-router)#network 192.100.254.0 0.0.0.3
R2(config-router)#network 192.100.254.4 0.0.0.3

R3(config)#router eigrp 7
R3(config-router)#network 10.0.0.0 255.0.0.0
R3(config-router)#network 172.30.3.0 0.0.0.255
R3(config-router)#network 192.100.254.4 0.0.0.3

Next, we will configure EIGRP authentication over the 10.0.0.0/8 network.  EIGRP authentication is slightly more complex then the configuration set on OSPF and has a few more features available.

EIGRP uses the concept of key chains.  These key chains can be given a lifespan, so that you can automatically rotate different passwords amongst the routers based on two parameters- accept-lifetime and send-lifetime.  The router dates and clocks must be synchronized in order for key lifetime to work correctly.

Starting on R1, our first step will be to create a key chain.

R1(config)#key chain red

Next, we define an individual key by giving it a number and a name

R1(config-keychain)#key 1
R1(config-keychain-key)#key-string LAN

In this lab, I won't be configuring lifetimes for the keys, but the command syntax is:
accept-lifetime [H:M:S] [month] [day number] [yyyy] [H:M:S] [month] [day number]

The send-lifetime command uses the same parameters.

Now we will instruct the router to use this key on its fa0/0 port

R1(config)#int fa0/0
R1(config-if)#ip authentication mode eigrp 7 md5
R1(config-if)#ip authentication key-chain eigrp 7 red

Now, for authentication to be successful (and for the neighbor relationships to form again) the key-strings and key numbers for R1, R2 and R3 must match.  The key chain name does not need to match.

R2(config)#key chain blue
R2(config-keychain)#key 1
R2(config-keychain-key)#key-string LAN
R2(config-keychain-key)#int fa0/0
R2(config-if)#ip authentication mode eigrp 7 md5
R2(config-if)#ip authentication key-chain eigrp 7 blue

R2 and R1 should now be neighbors on the 10.0.0.0/8 network.  You can confirm this with the command
show ip eigrp neighbors.  You will see 10.0.0.1 listed, but not 10.0.0.3 as authentication has not yet been configured on R3.

Authentication will now be configured on R3

R3(config)#key chain yellow
R3(config-keychain)#key 1
R3(config-keychain-key)#key-string LAN
R3(config-keychain-key)#int fa0/0
R3(config-if)#ip authentication mode eigrp 7 md5
R3(config-if)#ip authentication key-chain eigrp 7 yellow

Now, when you run show neighbors on R2, you will also see R3 as authentication matches between the three routers on the 10.0.0.0/8 network.

In a subsequent post, this lab will be expanded on and I will go into further detail about tweaking successor routes and feasible successor routes by changing the bandwidth and delay value on the links.

OSPF Lab

In this lab, we will be configuring OSPF using the following topology:

Routers R1, R2, and R3 will be connected both via ethernet links to SW1 and serial links between each other.  In my topology, I am using a NM-4A/S module on R2, so my link from R2 to R1 will be designated as S1/0 and from R2 to R3 will be S1/1.  All clocking will be configured on R2's serial links for simplicity.  PPP PAP authentication will be configured between R1 and R2, and PPP CHAP authentication between R2 and R3.

R1-3 will be configured to utilize OSPF  authentication with MD5 on the 10.0.0.0/8 network.

In this lab, we will manually configure R2 to be the DR for the ethernet network, and R1 to be the BDR.  The neighbors connected via serial link will become full neighbors as they are on a point to point type link.

The start of this lab will assume that all physical cabling has been completed, hostnames will be correctly configured on the routers and IP addresses on the serial, Ethernet, and loopback adapters have been set.  Verify connectivity by pinging all remote interfaces.

First, we will establish PPP connectivity on the serial links.  Starting at R1:

R1(config)#username R2 password pass!
R1(config)#int s0/0
R1(config-if)#encapsulation ppp
R1(config-if)#ppp authentication chap

You should see the line protocol on s0/0 drop at this point.  Lets resolve this problem by configuring PPP on R2's S1/0 link.

R2(config)#username R1 password pass!
R2(config)#int s1/0
R2(config-if)#encapsulation ppp
R2(config-if)#ppp authentication chap

Verify with a ping to IP address 192.100.254.1 from R2 that you have successfully configured CHAP.

Next, lets setup PPP with PAP on the serial link from R2 to R3.

R2(config)#username R3 password password!
R2(config-if)#int s1/1
R2(config-if)#encapsulation ppp
R2(config-if)#ppp authentication pap
R2(config-if)#ppp pap sent-username R2 password password!

R3(config)#username R2 password password!
R3(config)#int s0/0
R3(config-if)#encapsulation ppp
R3(config-if)#ppp authentication pap
R3(config-if)#ppp pap sent-username R3 password password!

At this point, you should be able to ping between R2 and R3.

Now that our PPP links have been configured, its time to configure OSPF on our routers.

Starting at R1 (and remember, the process id does not have to match with OSPF as it is purely a local concept, unlike EIGRP, but the area must match.)  Also, OSPF uses wildcard masks for the interfaces.  Pay close attention to the configuration.  A shortcut I use in determining the wildcard mask is to take the incremental value, and subtract is by one.  So for example, a /30 network has a incremental value of 4.  So the wildcard mask must be 0.0.0.3

R1(config)# router ospf 1
R1(config-router)#router-id 11.11.11.11
R1(config-router)#network 10.0.0.0 0.255.255.255 area 1
R1(config-router)#network 172.30.1.0 0.0.0.255 area 1
R1(config-router)#network 192.100.254.0 0.0.0.3 area 1


R2(config)# router ospf 1
R2(config-router)# router-id 12.12.12.12
R2(config-router)# network 10.0.0.0 0.255.255.255 area 1
R2(config-router)# network 172.30.2.0 0.0.0.255 area 1
R2(config-router)# network 192.100.254.0 0.0.0.3 area 1
R2(config-router)# network 192.100.254.4 0.0.0.3 area 1


R3(config)#router ospf 1
R3(config-router)#router-id 2.2.2.2
R3(config-router)#network 10.0.0.0 0.255.255.255 area 1
R3(config-router)#network 172.30.3.0 0.0.0.255 area 1
R3(config-router)#network 192.100.254.4 0.0.0.3 area 1

It is important to configure the RID first, if you want manual control over the election process.  Otherwise, the OSPF enabled router will use its loopback adapater as its RID.  If this were to happen, R3 would be the LAN's DR, and R2 would be the BDR.

At this point, our OSPF configuration should be complete.  Let's use some verification commands to ensure that things are operating the correctly.

Assuming a ping is successful between all devices,  lets see what running  show ip ospf neighbor reveals on each device.

As you can see, R2 is in fact the DR, and R1 is the BDR for the 10.0.0.0 network.  R3 is listed as a FULL/DROTHER.

Next, lets configure authentication between the three routers on the 10.0.0.0 network.

R1(config)#int fa0/0
R1(config-if)#ip ospf authentication message-digest
R1(config-if)#ip ospf message-digest-key 1 md5 Pass!


R2(config)#int fa0/0
R2(config-if)#ip ospf authentication message-digest
R2(config-if)#ip ospf message-digest-key 1 md5 Pass!


R3(config)#int fa0/0
R3(config-if)#ip ospf authentication message-digest
R3(config-if)#ip ospf message-digest-key 1 md5 Pass!

While entering these commands, you may lose a neighbor, but after succesfully entering all three sets of commands, you should re-establish your neighbor relationships.  If you haven't, ensure that you've spelt the key correctly amongst the devices, and enabled authentication on the correct interfaces.

At this point, the lab is complete according to the specifications set in the beginning. You can verify your configuration with the remaining commands:


show ip ospf interface -this is useful for verifying timers, neighbors, DR and BDR's and the OSPF area

show ip protocols - this command is useful for verifying the current timers 

show ip route ospf- lists out all routes learned by the OSPF routing protocol

Data-Link Protocol Overview

I'm going to provide an overview here of the different data-link protocols, and then as promised earlier, post an EIGRP lab and an OSPF lab, illustrating the differences in the configurations.  However I want to set these up in something of a more advanced lab, utilizing PPP with authentication.  Due to the complexity of Frame-Relay, it will get its own seperate lab and overview.

I'd rather not go too deep into the overall theory, as this information can be found elsewhere, instead I will provide a brief overview of the major features of each, along with how to configure these protocols.

WAN Data-Link Protocols

Three of the major configurable data-link protocols covered on the CCNA exam are:

HDLC
PPP
Frame-Relay

You can check to see what type of encapsulation an interface is using with the show int [interface] command.  The default for a ethernet port is "ARPA" which is ethernet type II.











HDLC

High-Level Data Link Control (HDLC) is fairly basic in terms of configuration compared to the other WAN data-link protocols.  It is set using the interface command encapsulation hdlc.  There is not much other configuration to be done with this protocol other then ensuring that both routers are using the same encapsulation protocol.  As far as the features offered by HDLC, they include identifying the protocol type with the 2 byte HDLC Protocol Type field, and error detection in the Frame Sequence Check (FCS) field in the data-link trailer.  The industry standard version of HDLC does not include the 2 byte type field, therefore, HDLC implemented on a Cisco router is only compatible with another Cisco router.
HDLC is the default encapsulation type used on a Cisco serial interface:

PPP

Compared to HDLC, the industry standard version of PPP (RFC 1661-by the IETF) contains the 2 byte Protocol Type field.  This means that a Cisco router using PPP on a serial link, is compatible with a non Cisco router utilizing the same layer 2 protocol on the opposing end of the link.

Besides the protocol type field, the other main features of PPP include:

Multi-link support
PAP/CHAP Authentication
Error Detection
Looped Link Detection

PPP relies on two protocols to operate-Link Control Protocol (LCP) and Network Control Protocol (NCP).  The LCP is responsible for initial link establishment, and then continues to exchange messages with the neighboring router to maintain the quality of the link.  NCP negotiates the network layer protocol which is sent over PPP.  You can find more detailed information about the initial link establishment in the RFC that I linked above.

For basic troubleshooting and configuration purposes, it is enough to know that to establish a PPP link, LCP must successfully complete an exchange with its neighboring router.  If this exchange is successful, the LCP Open state will be reached.  After the LCP Open state is reached, authentication, if it is enabled, will be performed, and if successfully passed, the NCP phase will begin.  There can be multiple NCPs per link.  Remember that NCP is used for layer 3 protocols, such as IP, AppleTalk, IPX, etc.  You can visually inspect the status of LCP and NCP with the command show interface [int]

As you can see in this example, LCP is closed.  This can be helpful in troubleshooting instances-if LCP is closed when you expect it to be open, you can start your troubleshooting process at layers 1 and 2.  If it is open and a ping fails, for example, you could probably start at layer 3.

In this example, I have set an IP address on both routers, used the interface command encapsulation ppp on both ends of the link, and then issued a show int s0/0 command.  You can see that LCP is open, and that "IPCP" and "CDPCP" NCP's are both open.  It might be confusing that these aren't displayed as "NCP".  Just remember to substitute where the "N" should be with whatever layer 3 protocol you are using when you are searching for the NCP state.

PPP Configuration


PPP isn't too complicated to configure.  First, the encapsulation must be changed from the HDLC default to PPP with the command encapsulation ppp on the desired interface(s).  Next, authentication can be configured-either PAP or CHAP.  Remember that CHAP is more secure than PAP, as it utilizes a 3 way handshake protocol, with CHAP replying to the challenge with a one way hash algorithm.

PAP is configured by issuing the command ppp authentication pap on the interfaces of both routers.  For this example, it will be between routers Seattle and Tacoma.

On router Seattle, the command ppp pap sent-username Seattle password pass!  is entered, also on the interface.  On router Tacoma, the command ppp pap sent-username Tacoma password pass! is entered.  At this point, the PAP authentication is complete.

Configuration CHAP authentication has two key differences from PAP authentication.  The first, is that the username/password is entered in global config mode.  The second, is that the username you are entering with this command, is the hostname of the neighboring router.  Continuing with the example using router's Tacoma and Seattle, the configuration would be:

In global config mode on Tacoma, username Seattle password pass! You would then switch to the interface and enter in ppp authentication chap

Next, in global config mode on Seattle, username Tacoma password pass!.  Followed with the interface command, ppp authentication chap.

Also available is the command ppp authentication chap pap which will instruct the router to attempt CHAP authentication first, and if that fails, PAP.

The last item of note is the keep-alive timer.  By default, the timer will be 10 seconds.  If a LCP keep alive message is not recieved within a number of keep alive cycles, the link will be terminated.  The keepalive is set on the serial link itself.  It is generally best to leave this setting alone.  The timer can be verified with the show interfaces command.

Troubleshooting/Debug

PPP verification can be seen with the commands

show interfaces -LCP status, NCP status, encapsulation type, keepalive time, clockrate
debug ppp authentication - here you can view the authentication messages sent and received by the router.  This could be useful for determining an authentication type mismatch.

EIGRP-Successors and Distance

The terminology describing the distance or metric as seen by a router and its neighbors in EIGRP can be confusing.  Lets start first with the Feasible Distance (FD) and Reported Distance (RD).

Feasible Distance: This is the calculated metric at the local router to a destination subnet
Reported Distance: This is the metric advertised, or reported, by an EIGRP neighbor to reach the advertised route.
It is easier to understand this concept with a diagram:

(These are hypothetical values)

R1's feasible distance to reach its directly attached fa0/0 subnet is 28,610.  When it advertises this route to R2 through either a topology exchange or a bounded update, it will advertise the metric as 28,610.  At R2, this is the reported distance.  R2 then takes into account the bandwidth and delay of its serial link to R1 in order to reach the 10.0.1.0/24 network.  This calculated metric is R2's feasible distance, or in this example 1,258,478.


The Feasibility Condition: Successor Routes and Feasible Successor Routes
Next, we have the terms Successor Route and Feasible Successor route.  A successor route is a route with the lowest metric to a destination subnet.  A Feasible Successor route is essentially a backup route, but it has to meet a certain condition in order to be eligible in EIGRP.  This "eligibility" is determined by what is called the "Feasibility Condition".  In order for a route to be considered a feasible route, it must have a RD that is lower than the successor route's FD.

Again, this is something that is easier to understand by seeing it in a network diagram.  I have again used hypothetical values RD/FD values to make it easier to understand the concept.

As you can see in the diagram, R2 is advertising a RD of 2,020,000.  R3 is advertising a RD of 220,000.  The FD from R4 to R1 is 280,000.  In order to meet the Feasibility Condition, a route's RD must be less then the successor route's FD.  R2's route clearly exceeds this with a RD of 2,020,000.  R3's RD on the other hand, is 220,000, which is less than the FD of the successor route on R4-280,000.  The route through R3 to R1's subnet is then considered a feasible successor route.

Terminology aside, in plain English: R3's route can be considered a valid backup route, since the metric R3 is reporting is lower then R4's best route metric.

In this instance, the successor route (R4-R1) would be installed in the routing table, and the feasible successor would be visible under a show ip eigrp topology


Remember though-there can in fact be more then one successor route.  Depending on the load balancing options configured on the router (the default is 4 equal metric routes), if four routes are found to have the best metric, and have equal metrics, all four of those routes will be successor routes and will be installed in the routing table.

There can also be multiple feasible successor routes, provided they meet the feasibility condition.  Feasible successor routes are not installed in the routing table, but can be seen in the EIGRP topology table.

 I'll explain the configuration details of equal and unequal load balancing in a later post.

EIGRP Theory

EIGRP- Enhanced Interior Gateway Routing Protocol
This is only meant to be a brief overview.  I will be posting about the DUAL algorithm, the "feasibility condition" and terminology (anyone who has worked with EIGRP knows how confusing the chosen terms can be), and configuration/verification in their own separate sets of posts.

EIGRP-The "hybrid" routing protocol.
EIGRP is known as a hybrid routing protocol.  Its metric can make use of bandwidth, delay, reliability, and load.  By default, only bandwidth and delay are used.  EIGRP does not send periodic updates, and routing information does not expire.  Instead, EIGRP is aware of its neighbor's connection status through the use of hello messages.  If these messages are not received within a specific interval time, and the hold timer expires, EIGRP declares the route to be down and can immediately change to a backup route (known as a feasible successor route) if it exists, or it will use the Diffusing Update Algorithm (DUAL) to send a series of queries to neighboring routers in search of a valid path to the destination subnet.

EIGRP can operate in both a classful and a classless addressing scheme.  It does enable auto-summarization by default, so this is something to watch out for if working in a discontinguous network, or one that utilizes VLSM.  Unlike OSPF, any router can make use of summary routes in order to reduce the size of the routing table.

EIGRP Neighbors
The concept of neighbors is similar to OSPF, but simpler as there are not different states of the neighbor relationship-routers either form a neighbor relationship, or do not form a relationship.

Routers may form a neighbor relationship if:
-They are operating in the same subnet
-The routers are both configured with the same Autonomous System (AS) number
-The K values on both routers match
-Both routers pass authentication, if configured

If these four parameters are successfully met, the two routers become neighbors and begin by initiating a full topology transfer using the Reliable Transport Protocol (RTP).  After this topology exchange, the routers continue to send periodic hellos to the multi-cast address of 224.0.0.10.  In the event of a topology change, the router will notify its neighbor with an EIGRP update message using either the multicast address of 224.0.0.10 on multi-access networks, or the router's unicast IP address in a point to point type of relationship.  Two terms are used to describe EIGRP's update messages-bounded and partial.  A partial update will contain new information such as when a route changes, or a link goes down.  These are only sent in the event of a topology change.  The term bounded means that the updates are only sent to routers that are affected by this new change in the network topology.

Timers
The default hello interval depends on the link type being used.  Usually, a router configured to operate on a multi-point nonbroadcast multiaccess (NMBA) network such as Frame Relay, will have a default hello interval of 60 seconds.  The default hold time is 3x the hello interval.  On most other networks, the hello interval defaults to 5 seconds.  Unlike OSPF, these timers do not have to match in order to form a valid neighbor relationship, however if the timers are configured incorrectly, and the hold timer expires before receiving another hello message from its neighbor, EIGRP will drop the adjacency.

DUAL FSM
DUAL FSM (finite state machine) is the algorithm used by EIGRP to calculate the best path to a destination subnet.  It works to provide loop-free paths, and backup loop-free paths, which can be put to immediate use.  If a link goes down, DUAL makes a logical decision depending on whether it has any valid backup routes in its topology table-directly install a backup route (feasible successor route-this will be explained in further detail later), or if a feasible successor route does not exist, it will place the destination subnet in a "active" state and send queries to its neighbors.  If the neighbors have a valid route to the destination subnet, one of the types of messages they will send back is a reply message with information about the route.

OSPF Metric Calculation

This post will go abit more into detail about the OSPF metric calculation and the different bandwidth commands that can be applied.

The basic idea behind OSPF metric calculation is adding outgoing interface costs from the source network to the destination network.  The SPF algorithm calculates this metric using the formula:

Reference Bandwidth  / Interface Bandwidth

This sounds easy enough, but a potential problem that can play into calculating the metric has to do with the  units used by the formula, and what units the router config command auto-cost reference <value> and the interface command bandwidth <value> use.  When the formula is applied by the SPF algorithm, IOS converts the units to use the same type- Mbps.

By default, an Ethernet interface will use the value 10,000 for its bandwidth.  This unit type is set in Kbps, in Mbps that would be converted to a value of 10.  The default reference bandwidth value is 100.  This value is set in Mbps.  So by default, an Ethernet cost will be calculated as 100/10 = 10

It is recommended to change the reference-bandwidth value when working with bandwidth speeds at or great then 100 Mbps, otherwise the cost for both a 1 Gbps interface, and a 100 Mbps interface would be the same : 1.

Alternatively, this formula can be overriden by manually setting the interface cost value within a range of 1-6535 by using the interface command ip ospf cost.  Do not confuse this command with ip ospf priority, this command is used to modify an interface's priority value to be used with a designated/backup designated router election.

To verify your configuration, you can use the command show ip ospf interface.  The output will list detailed information about the interface, along with the calculated cost.  This example shows the default bandwidth cost on a fast ethernet interface.

By default, the formula used was 100Mbps/100Mbps
Now we will modify the reference bandwidth value to use 1000 Mbps.

As you can see now, the formula was modified to 1000Mbps/100Mbps.

Key OSPF Concepts

OSPF is a link-state routing protocol, which uses the Dijkstra Shortest Path First (SPF) algorithm to determine the best routes to destination subnets.

There are three tables maintained by OSPF: neighbors, the link-state database, and the IP routing table.
These tables can be seen with the following commands:

show ip ospf neighbor
show ip ospf database
show ip route

Importance of the RID
OSPF routers are uniquely identified by a router ID, or RID.  There are three main ways a router derives its RID.

The first is that the RID is manually set while in router config mode with the command router-id [value]
The RID is a 32 bit dotted decimal ID.

The second, is that the router picks the highest IP address out of any loopback adapters configured, and in the up state.

The last method is that the highest IP address is chosen out of an interface where at least the first interface status is "up".  So an IP address assigned to an interface with a status of up, down could be selected if it was the highest address.

Requirements for OSPF routers to become neighbors:

-Be on the same subnet with matching masks and ID's
-Having matching Hello and Dead intervals
-Be operating in the same OSPF Area
-Exchange and pass any authentication configured

Hello messages include the sending RID, Area ID, Hello and Dead timer intervals, router priority, RID of the DR and BDR, and a list of "seen" or neighbors the router already has paired with.


OSPF routers have four different neighbor states:
-Down: the neighbor is not reachable
-Init: A Hello has been received, but it does not contain the local router's RID in the seen list.
-2-Way: The local router has recieved a Hello message with its own RID listed in the seen list from the neighboring router.  These two routers must then match the required parameters for becoming neighbors.
-Full: The neighbors having matching LSDB's and are considered to be fully adjacent.


Depending on the network topology, and the types of OSPF interfaces in use, some routers will not become fully adjacent.  In a multi-access network, there will be an elected DR and BDR router.  Other routers will become fully adjacent with the DR and BDR routers and be considered to have full adjaceny and have exchanged their topology information with the DR.  Non DR/BDR routers will be displayed as DROther in the neighbor table and their state will be 2-way.

DR/BDR Election
The router sending the highest OSPF priority will become the DR.  OSPF priority is configured by interface with the command ip ospf priority <value 0-255>.  If the value is set to 0, the router will exclude itself entirely from the election.  If there is a tie, it will be broken by whichever router has the highest RID.  If a new OSPF router enters the network after the election with a higher priority/RID, it will not cause another election cycle.

In a point to point situation, there will not be a DR/BDR election, and valid neighbors will become fully adjacent with each other.

The type of OSPF interface is configured with the interface command ip ospf network <broadcast, point-to-point>  There are other types, but they are outside the scope of the CCNA.  point-to-point is assumed on serial links, such as how broadcast is assumed on Ethernet interfaces.

LSDB Exchange
When two routers have matching LSDB databases, they are considered to be in full adjacency with one another.  This happens by the two routers exchanging lists of their LSA's with one another.  Any gaps in consistency of the received LSA lists and their own LSDB tables is solved by sending a request for the LSA in question.  Maintenance of the relationship between the two routers is performed by continuing to exchange hello's every hello interval (default, 10 seconds).  If a hello is not heard within the dead interval, the connection will be considered lost to the neighbor.  LSA's are flooded every 30 minutes by default, or if there is a change to the topology.

Selecting best paths
Path selection is performed by running the SPF algorithm.  The LSDB table does not itself identify the best route to the destination subnet.  The SPF algorithm operates by adding the OSPF cost for each outgoing interface between itself as the starting point, and the destination.  The route with the lowest cost is installed in the routing table.

Load Balancing
By default, OSPF load balances over four equal cost routes.  This can be adjusted, up to a maximum of 16, with the router config command maximum-paths <value>

Metric Calculation
The cost of each interface can be set manually using the ip ospf cost command, with a value between 1 and 65,535.
The router can calculate the cost itself by taking the reference bandwidth and dividing it by the interface bandwidth.

Authentication
There are three types that can be used by OSPF.  The commands are used per interface.

Null/none (default)
 ip ospf authentication null

Plaintext                
ip ospf authentication
ip ospf authentication-key <value>

MD5        
ip ospf authentication message-digest
ip ospf message-digest-key <key number> md5 <password>

Dynamic Routing Protocol Info

Some general information regarding the different routing protocols.

Administrative Distance Summary

Type
Connected	0
Static	1
BGP (external)	20
EIGRP (internal)	90
IGRP	100
OSPF	110
IS-IS	115
RIP	120
EIGRP (external)	170
BGP (internal)	200
Untrustable	255

Multi-cast addresses used 

RIP-2: 224.0.0.9
OSPF: 224.0.0.5, 224.0.0.6
EIGRP: 224.0.0.10

All except RIP-1 support manual summarization.
RIP and EIGRP support auto-summarization, OSPF does not.
Out of RIP, OSPF, EIGRP, and IS-IS, only EIGRP is Cisco proprietary.

Configuring RIP (v1)

RIP version 1 overview

-RIP v1 is a classful routing protocol, as a result, auto-summarization is used and subnet masks are not sent in routing updates.  RIP cannot be used in discontinguous networks.

-RIP determines the subnet mask for subnet ID's by looking at the address masks configured on its own interfaces for the classful network in question.  This is why a VLSM IP address scheme cannot be used.  If the router does not have any interfaces assigned to the address received in the routing update, RIP will assume the classful mask.

-Routing updates are sent as a broadcast by default every 30 seconds on UDP port 520

-RIP Timers

This can be a confusing topic, and in general, there is conflicting information on the operation of these timers. By default, RIP uses a 30 second update timer, a 180 second invalid timer, a 240 second flush timer, and a 180 second holddown timer.

Each time a routing advertisement is received for a particular route (30 seconds by default), the invalid and flush timers reset to zero and begin counting upwards.  If the invalid timer reaches 180 seconds, the route is marked as invalid, and the hold-down timer begins.  The flush timer counts alongside the invalid timer, and upon reaching 240 seconds, the route in question will be flushed from the routing table.

There is controversy concerning the operation of the hold-down timer.  The first, and most reoccurring theory  is that during the hold-down timer, the router can accept routes from any source as long as the metric is equal to, or lower then the original metric used for the route. This is what I saw happen in my physical lab.

The second theory is that the router cannot install any routes until the hold-down timer expires, regardless of the metric.

I tested this using physical lab equipment, and it seems that using the default settings and timers, the routers will accept a route from the original source, even if the hold-down timer has not yet expired, perhaps the router behavior is different based upon the IOS version in use.

My topology consisted of :

R1 LAN --->R1 ------ > R2 ------- > R3

When I set R1's serial link to not send RIP traffic (passive-interface s0/0 in router config mode), R2 continued to send updates to R3 every 30 seconds for R1's attached fa0/0 LAN.  After the invalid timer expired, R2 sent a poisoned route for R1's LAN out all interfaces-it increased the metric from 1 to 16, declaring it an invalid route.  When I re-enabled RIP traffic on R1's serial, R2 received the advertisement for R1's LAN, and before the hold-down timer had expired, installed the route and resumed forwarding advertisements with the correct metric to R3.

First Post!

After having my notes scattered across multiple notebooks, .doc files, and various note taking programs, I have decided to settle on using this blog to compile all of my notes and random Cisco related thoughts and questions.  I'll be keeping this fairly updated, and I plan on extending this past CCNA related material after I certify and move onwards to the CCNP.