Tuesday, August 30, 2011

URL Redirects using NAT

In my previous post, "Router URL Filtering using NBAR", I explained how it was possible to block users from accessing websites simply by using NBAR, a class-map and a policy-map.

In this post I'll describe how you can redirect your users' web requests instead of simply blocking them. This time we'll use NAT instead of NBAR.

For this example, let's say you'd prefer everyone on your network to use Google instead of Yahoo, so every time someone goes to Yahoo.com, they'll be re directed to Google.com.au

To do this, you'll need to obtain the web server IP addresses for both Yahoo and Google. This can be done easily enough with a ping: 

Pinging yahoo.com [98.137.149.56] with 32 bytes of data:

Pinging google.com.au [74.125.237.51] with 32 bytes of data:


Now all we'll need to do is put these two IP addresses in to a single NAT entry and we're done, like so: 

ip nat outside source static 98.137.149.56 74.125.237.51

As mentioned in previous post however, using IP addresses instead of domain names is not ideal as large websites such as Google, YouTube, etc, use multiple IP addresses for their websites and therefore the above method will not get you a 100% success rate.

As always, if you have any questions or have a topic that you would like me to discuss, please feel free to post a comment at the bottom of this blog entry, e-mail at myciscolabsblog@gmail.com, or drop me a message on Twitter (@OzNetNerd).

Note: This website is my personal blog. The opinions expressed in this blog are my own and not those of my employer.

Monday, August 29, 2011

Router URL Filtering using NBAR

There are many ways you can block users from accessing websites they shouldn't be, such as firewalls, proxy servers, DNS servers, etc. However, if you have a small setup, chances are you may not have any of these in place already, and you may be reluctant add another piece of equipment to your network.

This is where your Cisco router can come to the rescue again.

(Note: No matter how small your network is, it is highly recommended that you do use firewall(s) to protect your network, whether they come in the form of software installed on each PC, or CBAC configured on your border router).

Using NBAR and a policy map, you can have your URL filtering set up in a matter of seconds. Here's an example: 

class-map match-any BLOCKED_SITES
 match protocol http host "*facebook*"
 match protocol http host "*youtube*"
!
!
policy-map DROP_TRAFFIC
 class BLOCKED_SITES
   drop
!
interface Dialer1
 service-policy output DROP_TRAFFIC


The configuration is quite self explanatory.

Step 1: You simply create a class-map and use the "match protocol" command to specify the URLs you'd like to block.

(Note: You can use Regular Expressions to match the URL. This is what the asterisks (*) mean in the example strings above).

Step 2: Create a policy-map that tells the router what to do with traffic that matches the criteria set out by the class-map.

Step 3: Apply the policy-map to your Internet facing interface, in the outbound direction.

You can then verfiy that your configuration is working by issuing the sh policy-map interface dialer 1 command: 

Router#show policy-map interface dialer 1
 Dialer1

  Service-policy output: DROP_TRAFFIC

    Class-map: BLOCKED_SITES (match-any)
      36 packets, 44247 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: protocol http host "*facebook*"
        10 packets, 8391 bytes
        5 minute rate 0 bps
      Match: protocol http host "*youtube*"
        26 packets, 35856 bytes
        5 minute rate 0 bps
      drop


Unfortuantely, URL filtering is not 100% reliable and can be circumvented quite easily, however, it is a good technique to know nevertheless.

Note: Some people feel that using an outbound ACL on your Internet facing interface is sufficient. However, as the ACL statically defines a public IP address, if the website's IP address changes or if the site is load balanced over several IPs, the ACL will not be sufficient. By applying your filter based on the URL, you can be sure that the site will always be blocked so long as it never changes its name.

As always, if you have any questions or have a topic that you would like me to discuss, please feel free to post a comment at the bottom of this blog entry, e-mail at myciscolabsblog@gmail.com, or drop me a message on Twitter (@OzNetNerd).

Note: This website is my personal blog. The opinions expressed in this blog are my own and not those of my employer.

Subnetting Made Easy - Formula

I covered subnetting in my earlier posts, Subnetting Made Easy, Part 1 and Subnetting Made Easy, Part 2.

In the latter mentioned post, I explained how you can use simple additions or subtractions to work out the First Usable Address, the Last Usable Address and the Broadcast Address of a subnet.

As the post was quite long, I thought I should re post the formulas in case they got lost in the sea of text.

Here they are:

First Address = Network Address + 1
Broadcast Address = Next Network Address - 1
Last Address = Broadcast Address - 1 

If they make no sense to you, please re-read my previous post.

As always, if you have any questions or have a topic that you would like me to discuss, please feel free to post a comment at the bottom of this blog entry, e-mail at myciscolabsblog@gmail.com, or drop me a message on Twitter (@OzNetNerd).

Note: This website is my personal blog. The opinions expressed in this blog are my own and not those of my employer.

Sunday, August 28, 2011

Subnetting Made Easy, Part 2

In my previous post, "Subnetting Made Easy, Part 1", I demonstrated the way I use to find the Network Address, First Usable Address, Last Usable Address and Broadcast Address when given any IP address and subnet mask. This time I will demonstrate how this process can also be used when dealing with multiple, consecutive subnets.

To make things easier, I'll use the same setup as last time.

As per my previous blog entry, we found that the network address was 195.70.16.156. We also knew that we were only going to be dealing with the fourth octet as this is a /30 address. We then converted this information in to binary format and were left with this:

128 64 32 16  8  4 2 1
SN  SN SN SN SN SN H H
1   0  0  1   1  1 1 1

Now, let's get started on the next part. To put a clear division between the Subnet Bits and the Host Bits, what I like to do is put a line between them, like this:

128 64 32 16  8  4  |  2 1
SN  SN SN SN SN SN  |  H H
1   0  0  1   1  1  |  1 1

Now we can clearly see that the last Subnet Bit is 4. This instantly tells us that if we want to create additional, identical subnets, all of the Network Addresses are going to be 4 apart. To help me better explain what I mean, I'll use the below table.

Legend:
N = Network Address
First = First Usbale Address
Last = Last Usable Address
B/C = Broadcast Address
|----------------------
| N | First| Last| B/C|
|----------------------
|   |      |     |    |
|----------------------
|   |      |     |    |
|----------------------

Once again, looking at the previous entry, we found the following information:

Network Address: 195.70.16.156
First Usable Address: 195.70.16.157
Last Usable Address: 195.70.16.158
Broadcast Address: 195.70.16.159


When inserted in to the table, it looks like this:

|----------------------
| N | First| Last| B/C|
|----------------------
|156|  157 | 158 | 159|
|----------------------
|   |      |     |    |
|----------------------

Now, as mentioned above, we know that the Subnets are going to be 4 bits apart. This means all we need to do is add 4 to the current network address. e.g 156 + 4 = 160. Then, to get the next network address after that, we'd do 4 + 160 = 164. And so on. Using this forumula, the table now looks like this:

|----------------------
| N | First| Last| B/C|
|----------------------
|156|  157 | 158 | 159|
|----------------------
|160|      |     |    |
|----------------------
|164|      |     |    |
|----------------------
|168|      |     |    |
|----------------------


Now all we need to do is some more basic maths. Using the following formulas, we can fill in the rest of the table:


First Address = Network Address + 1
Broadcast Address = Next Network Address - 1
Last Address = Broadcast Address - 1


There are two things to note here. As you can see, the Last Address formula requires that you first find out what the Broadcast Address is.

The second thing to note is that the "Next Network Address" that the Broadcast Address formula is referring to is network address of the following subnet. For example, as per the table above, if we were working on the network address 195.70.16.160, we know the next network address is 195.70.16.164.

Speaking of which, let's do that now.

Using the above formulas and the 195.70.16.160 Network Address, this is what we end up with:


First Address = 160 + 1 = 161
Broadcast Address = 164 - 1 = 163
Last Address = 163 - 1 = 162

|----------------------
| N | First| Last| B/C|
|----------------------
|156|  157 | 158 | 159|
|----------------------
|160|  161 | 162 | 163|
|----------------------
|164|      |     |    |
|----------------------
|168|      |     |    |
|----------------------

 Then if we do the same with for the 195.70.16.164 subnet, this is what we'd end up with:

|----------------------
| N | First| Last| B/C|
|----------------------
|156|  157 | 158 | 159|
|----------------------
|160|  161 | 162 | 163|
|----------------------
|164|  165 | 166 | 167|
|----------------------
|168|      |     |    |
|----------------------

I'll leave the 195.70.16.168 network blank so that you can have a try yourself.

Note: You may notice that all of the numbers are simply four higher than one another each time you go down a row. It is not advisable to just keep adding four to the numbers because while it may work in this case, if you were dealing with different subnet masks it wouldn't, however, the formula still would.

Update

Please see my "Subnetting Made Easy, Part 3" post for more information.

As always, if you have any questions or have a topic that you would like me to discuss, please feel free to post a comment at the bottom of this blog entry, e-mail at myciscolabsblog@gmail.com, or drop me a message on Twitter (@OzNetNerd).

Note: This website is my personal blog. The opinions expressed in this blog are my own and not those of my employer.

Saturday, August 27, 2011

Subnetting Made Easy, Part 1

There are a wide range of techniques people use to work out their network, host and broadcast addresses. I prefer to take the binary approach as I find it the quickest and easiest method, and is never wrong.

Remember, the four most important things to know about a subnet is the following:

Network Address:
First Usable Address:
Last Usable Address:
Broadcast Address:

Let's say for example, we were given the IP address 195.70.16.159 and told that it is in a /30. This is how I'd go about filling in the template above...

First of all, as IP addresses are 32 bits long, and each octet is 8 bits in length, we know that:
  • Bits 0 to 8 are covered in the first octet.
  • Bits 9 to 16 are covered in the second octet.
  • Bits 17 to 24 are covered in the third octet.
  • Bits 25 to 32 are covered in the fourth octet.
So, as this subnet address has 30 bits in it, we know we're dealing with the fourth octet.

Now, because know bits 25 to 30 are subnet bits (referred to as SN below), we also know that the remaining two bits are host bits (referred to H below). Here is what it looks like when written down:


25 26 27 28 29 30 31 32
SN SN SN SN SN SN H  H
x  x  x  x  x  x  x  x


Now let's replace the bit numbers with their values:


128 64 32 16  8  4 2 1
SN  SN SN SN SN SN H H
x   x  x  x   x  x x x
 

Now, let's replace the x's with the value of the fourth octet in the address, which in this case, is 159.


128 64 32 16  8  4 2 1
SN  SN SN SN SN SN H H
1   0  0  1   1  1 1 1
 

If you are wondering how I came up with the above, it is very simple. All I did was:
  • Subtract 128 from 159, which left me with 31
  • I then subtracted 16 from 31, whcih left me with 15
  • I then subtracted 8 from 15, which left me with 7
  • I then subtracted 4 from 7, which left me with 3
  • I then subtracted 2 from 3, which left me with 1
  • I then subtracted 1 from 1, which left me with 0

Note: While this may sound overly complicated, it is actually very quick and easy to do when doing it on a piece of paper.

Now to find out the network address all we do is add the SN bits that have a 1 underneath them, together. (128 + 16 + 8 + 4 = 156).

When you add this 156 to the first three octets of the address, we're left with the Network Address 195.70.16.156.

Now, as we know that the first usable address is always the Network Address plus one, all we need to do is perform the following calculation: (156 + 1 = 157).

This gives us a First Usable Address of 195.70.16.157.

Now let's skip the Last Usable Address for a moment and find the Broadcast Address. To find out what it is, all we need to do is add all of the H bits together (regardless of whether they are a 1 or a 0) and then add this number to the Network Address. (2 + 1 + 156 = 159).

This gives us a Broadcast Address of 195.70.16.159.

And finally, let's work out the last usable address. This process is similar to finding the First Usable Address, however, instead of adding one to the network address, we actually subtract one from the Broadcast Address. (159 - 1 = 158).

This gives us a Last Usable Address of 195.70.16.158.


And there we have it! Our temaplte is complete. For easy reference, here it is again:

Network Address: 195.70.16.156
First Usable Address: 195.70.16.157
Last Usable Address: 195.70.16.158
Broadcast Address: 195.70.16.159

For more subnetting information, please see Subnetting Made Easy, Part 2.

As always, if you have any questions or have a topic that you would like me to discuss, please feel free to post a comment at the bottom of this blog entry, e-mail at myciscolabsblog@gmail.com, or drop me a message on Twitter (@OzNetNerd).

Note: This website is my personal blog. The opinions expressed in this blog are my own and not those of my employer.

Friday, August 26, 2011

Single Public IP NATing to Multiple Hosts


In my previous blog entry, Multiple Public IP NATing to Multiple Hosts, I described how you can use "one to one" NATing to allocate one public IP address per internal host. This is a great solution for those who have multiple public IPs, however, these usually come at an added monthly cost.

An alternative to this method would be to run your services on different port numbers. For example, if you have three web servers, you could run one on port 80, the next on port 8080 and the last one on port 8081. However, some System Administrators do not like forcing their applications to run on non-standard ports and some applications may not even offer you the option.

So how do we fix this issue you ask? Rather than do the port change on the application(s) themselves, you can simply do it on the router itself. This is a great solution because the applications themselves do not need to be changed and you've got a central point of configuration for all of the port changes. Also, should you decide to invest in additional IP addresses later on down the track, you can migrate the server(s) to their new IP address(es) by simply changing a few lines of configuration.

Using the diagram below, I'll describe how you can achieve this:




Using the  "ip nat inside source static tcp/udp" command, we can map port 23 (telnet) for each of the LAN hosts (192.168.45.2, 192.168.45.3 and 192.168.45.4) to different ports (23, 2300 and 2301 respectively). 

R1(config)#do sh run | inc ip nat inside source static
ip nat inside source static tcp 192.168.45.2 23 94.56.43.2 23 extendable
ip nat inside source static tcp 192.168.45.3 23 94.56.43.2 2300 extendable
ip nat inside source static tcp 192.168.45.4 23 94.56.43.2 2301 extendable


What this means is that if we try to telnet to:
  • 94.56.43.2 on port 23, we'll connect to 192.168.45.2
  • 94.56.43.2 on port 2300, we'll connect to 192.168.45.3
  • 94.56.43.2 on port 2301, we'll connect to 192.168.45.4
As mentioned above, the beauty of configuring the port changes on the internet router itself (R1), we don't need to force telnet to run on different ports on the other hosts LAN hosts (R2, R3 and R4).

Let's look at some examples. Here is R1's NAT table before any traffic has been sent: 

R1(config)#do sh ip nat trans
Pro Inside global      Inside local       Outside local      Outside global
tcp 94.56.43.2:23      192.168.45.2:23    ---                ---
tcp 94.56.43.2:2300    192.168.45.3:23    ---                ---
tcp 94.56.43.2:2301    192.168.45.4:23    ---                ---


Now I'll initiate some telnet sessions from R1 to 94.56.43.2 and it's multiple ports. I'll start with port 23: 

R5#telnet 94.56.43.2 23
Trying 94.56.43.2 ... Open


Now let's take a look at the NAT translation table: 

R1(config)#do sh ip nat trans
Pro Inside global      Inside local       Outside local      Outside global
tcp 94.56.43.2:23      192.168.45.2:23    203.43.94.1:42931  203.43.94.1:42931
tcp 94.56.43.2:23      192.168.45.2:23    ---                ---
tcp 94.56.43.2:2300    192.168.45.3:23    ---                ---
tcp 94.56.43.2:2301    192.168.45.4:23    ---                ---


Now I'll try ports 2300 and 2301: 

R5#telnet 94.56.43.2 2300
Trying 94.56.43.2, 2300 ... Open
R5#
R5#telnet 94.56.43.2 2301
Trying 94.56.43.2, 2301 ... Open


And now let's take another look at the NAT translation table: 

R1(config)#do sh ip nat trans
Pro Inside global      Inside local       Outside local      Outside global
tcp 94.56.43.2:23      192.168.45.2:23    ---                ---
tcp 94.56.43.2:2300    192.168.45.3:23    203.43.94.1:23292  203.43.94.1:23292
tcp 94.56.43.2:2300    192.168.45.3:23    ---                ---
tcp 94.56.43.2:2301    192.168.45.4:23    203.43.94.1:49225  203.43.94.1:49225
tcp 94.56.43.2:2301    192.168.45.4:23    ---                ---


As always, if you have any questions or have a topic that you would like me to discuss, please feel free to post a comment at the bottom of this blog entry, e-mail at myciscolabsblog@gmail.com, or drop me a message on Twitter (@OzNetNerd).

Note: This website is my personal blog. The opinions expressed in this blog are my own and not those of my employer.

Multiple Public IP NATing to Multiple Hosts

I have seen quite a lot of ask the question, "how do I NAT multiple public IPs to multiple inside hosts?". I think what confuses most people is when they are given two different subnets. As per the diagram below, R1 has a 203.43.94.x address for its internet connection and a 94.56.43.x range for its internal hosts.

This type of configuration is known as "one to one" NATing. What it does is statically map an internal host's IP address to an external IP address.

Note:  Please also see my Single Public IP NATing to Multiple Hosts post for a similar setup but using only a single public IP address.

As per the diagram below, the mappings are as follows:
  • R2's Private IP is 192.168.45.2 and its public IP is 94.56.43.2
  • R3's Private IP is 192.168.45.3 and its public IP is 94.56.43.3
  • R4's Private IP is 192.168.45.4 and its public IP is 94.56.43.4
With these mappings, all traffic sent from R2 on to the internet will leave with a source IP address of 94.56.43.2. When traffic is sent from R3 on to the internet, it's source IP address will be 94.56.43.3, and so on.

The true is in reverse too. For example, when traffic from the internet is sent to 94.56.43.2, it will be sent to the host with the IP address 192.168.45.2 (R2), when traffic from the internet is sent to 94.56.43.3, it will be sent to the host with IP 192.168.45.3 (R3), and so on.




In the above topology, Routers R1 through to R4 are used to emulate a LAN network, and the connection between R1 and R5 are used to emulate a standard internet connection.

Please note that routers R2 through to R4 can be replaced by any network enabled device(s). I have only used routers in this example as they are the only devices that can be emulated by GNS3.

As you would on any network host (e.g a PC, laptop, server, etc), router's R2 through to R4 have basic configurations on them - simply an IP address and a default route pointing to R1's fa0/0 interface. Here is an example: 

R2:

R2#sh run int fa0/0
Building configuration...

Current configuration : 97 bytes
!
interface FastEthernet0/0
 ip address 192.168.45.2 255.255.255.0
 duplex auto
 speed auto
 


R5 also has a basic configuration on it, however, in the real world it would be administered by an ISP so I won't delve in to it's setup.

Now let's talk about R1. This is where all the magic happens.

Interface fa0/0 and fa0/1 are configured the way you'd expect - (note the "ip nat inside" and "ip nat outside" commands: 

R1:

interface FastEthernet0/0
 ip address 192.168.45.1 255.255.255.0
 ip nat inside
!
interface FastEthernet0/1
 ip address 203.43.94.2 255.255.255.252
 ip nat outside


This is a standard setup for any NAT configuration. Now for the special part: 

ip nat inside source static 192.168.45.2 94.56.43.2
ip nat inside source static 192.168.45.3 94.56.43.3
ip nat inside source static 192.168.45.4 94.56.43.4


It's as simple as that! In case you are unfamiliar with the "ip nat inside source static" command, it is actually very simple. The first IP address is that of the internal host and the second IP address is the public IP address you'd like to map to the internal host.

Now let's take a look at R1's NAT table: 

R1(config)#do sh ip nat trans
Pro Inside global      Inside local       Outside local      Outside global
--- 94.56.43.2         192.168.45.2       ---                ---
--- 94.56.43.3         192.168.45.3       ---                ---
--- 94.56.43.4         192.168.45.4       ---                ---


And now let's send some some test traffic and see the results. As R5 is used to emulate an internet host, we'll use it to send test data to the internal hosts through their corresponding public IP addresses.

Here is a ping from R5 to R2's public IP, 94.56.43.2: 

R5#ping 94.56.43.2

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


And here is the NAT table on R1: 

R1(config)#do sh ip nat trans
Pro Inside global      Inside local       Outside local      Outside global
icmp 94.56.43.2:0      192.168.45.2:0     203.43.94.1:0      203.43.94.1:0
--- 94.56.43.2         192.168.45.2       ---                ---
--- 94.56.43.3         192.168.45.3       ---                ---
--- 94.56.43.4         192.168.45.4       ---                ---


And for the next example, we'll telnet from R5 through to R4: 

R5#telnet 94.56.43.4
Trying 94.56.43.4 ... Open


And here is the NAT table on R1: 

R1(config)#do sh ip nat trans
Pro Inside global      Inside local       Outside local      Outside global
--- 94.56.43.2         192.168.45.2       ---                ---
--- 94.56.43.3         192.168.45.3       ---                ---
tcp 94.56.43.4:23      192.168.45.4:23    203.43.94.1:23781  203.43.94.1:23781
--- 94.56.43.4         192.168.45.4       ---                ---


As always, if you have any questions or have a topic that you would like me to discuss, please feel free to post a comment at the bottom of this blog entry, e-mail at myciscolabsblog@gmail.com, or drop me a message on Twitter (@OzNetNerd).

Note: This website is my personal blog. The opinions expressed in this blog are my own and not those of my employer.

Monday, August 8, 2011

EIGRP Network Command Tips

I have discussed the EIGRP "network" command previously in this entry as well as this entry, and here I am talking about it again. Who knew one command could be the source of so many entries!

If given incomplete information, the EIGRP "network" command will do its best to help you complete the command, however, unfortunately it doesn't always guess correctly.

For example, if you wanted to activate EIGRP on a single interface on your router which had the IP address 172.19.65.22, you'd use the following commands: 

R3(config-router)#router ei 10
R3(config-router)#network 172.19.65.22 0.0.0.0


You could then use the "do" command which I discussed previously to verify that the router took your configuration entry correctly, as per the below: 

R3(config-router)#do sh run | begin router eigrp
router eigrp 10
 network 172.19.65.22 0.0.0.0


However,  if you were to accidentally forget to add the wildcard mask to the end of the command and you instead entered: 

R3(config-router)#router ei 10
R3(config-router)#network 172.19.65.22

The router would, incorrectly, take a guess at what you really meant to type, as per the output below: 
R3(config-router)#do sh run | begin router eigrp
router eigrp 10
 network 172.19.0.0


As you did not specify a wildcard mask, the router identified the IP as a Class B address and therefore only kept the Class B portion of your entry. This is why you need to be very careful when using the "network" command and why it is also a good idea to double check your configuration before closing your session.

Note: A similar thing occurs when you do not use the no auto-summary command.

The next EIGRP "network" command topic I'd like to discuss is the use of subnet masks. Throughout all of my EIGRP posts, I have been using wildcard masks in my configuration examples as this is what EIGRP uses to determine which networks and interfaces it should advertise or use. However, you can actually use a subnet mask instead of a wildcard mask and the IOS will automatically convert it to a wildcard mask and add it to the running configuration. Here is an example: 

R3(config-router)# network 10.16.0.0 255.255.128.0
R3(config-router)#do sh run | begin router eigrp
router eigrp 10
 network 10.16.0.0 0.0.127.255


As some might find this an easy way of doing things, I recommend manually calculating the wildcard mask yourself as it is not only good practice but may be required for exams that you sit in the future.

As always, if you have any questions or have a topic that you would like me to discuss, please feel free to post a comment at the bottom of this blog entry, e-mail at myciscolabsblog@gmail.com, or drop me a message on Twitter (@OzNetNerd).

Note: This website is my personal blog. The opinions expressed in this blog are my own and not those of my employer.

The "do" Command

Don't you just hate it when your in the middle of implementing a new configuration but then decide you'd like to issue a show or ping command so you drop down to privileged EXEC mode? For example: 

R2(config)#router eigrp 10
R2(config-router)# network 192.168.20.2 0.0.0.0

R2(config-router)#exit
R2(config)#exit
R2#
R2#ping 192.168.20.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.20.1, timeout is 2 seconds:
!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 28/52/92 ms

You could always use "Control" + "Z", however, you still lose your current "spot" in your configuration hierarchy. In the example above, in order to get back to your original configuration mode, you'd need to issue the following commands: 

R2#conf t
R2(config)#router eigrp 10

By using the "do" command you no longer have to leave your current configuration level. 

If you need to do this several times, for example, to test ping connectivity, it can be quite time consuming.  To save time you could employ the use of the "do ping" command, as per the example below: 

R2(config)#router eigrp 10

R2(config-router)# network 192.168.20.2 0.0.0.0
R2(config-router)#do ping 192.168.20.1

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


Another example would be the "do show run" command to verify that you have the correct configuration on an interface: 

R2(config-router)#do sh run int fa0/0
Building configuration...

Current configuration : 99 bytes
!
interface FastEthernet0/0
 ip address 192.168.20.2 255.255.255.252
 duplex auto
 speed auto
end


The only downfall of the "do" command is that it does not let you use the "?" or "TAB" button to assist you in completing/finding a command. For example: 

R2(config-router)#do ping ?
% Unrecognized command
R2(config-router)#do ping 192.168.20.1 source fa0/0 ?
% Unrecognized command
R2(config-router)#do ping 192.168.20.1 source fa0/0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.20.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.20.2
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/44/64 ms


As per the above, it says valid commands are invalid. However, if you know that they are correct, you can issue them anyway and the device will give you the correct output. The reason why this is a downfall is because if you cannot remember the command's syntax, you'll need to drop down to the privileged EXEC mode.

As always, if you have any questions or have a topic that you would like me to discuss, please feel free to post a comment at the bottom of this blog entry, e-mail at myciscolabsblog@gmail.com, or drop me a message on Twitter (@OzNetNerd).

Note: This website is my personal blog. The opinions expressed in this blog are my own and not those of my employer.

EIGEP Network Command - The Easy Way Out

In my previous entry titled EIGRP Route Advertising I said "in order for two routers to exchange EIGRP routes, they must both be part of the same subnet and have a network command specifying that particular subnet, or, at the very least, their specific IP address on that subnet". In that entry I then went on to use the routers' specific IP addresses. In this entry, I'm going to explain how you can specify a larger subnet in order to reduce the number of network commands you must apply.

To do this, I'll use the topology on the right.

We'll configure the R2 and R3 in the same way as we did previous, by specifying the exact addresses of the interfaces we want to advertise.  

R2:

R2(config-router)#do sh run | begin router eigrp
router eigrp 10
 network 10.34.19.1 0.0.0.0
 network 192.168.20.2 0.0.0.0
 no auto-summary
 


R3: 

R3(config-router)#do sh run | begin router eigrp
router eigrp 10
 network 10.34.19.2 0.0.0.0
 network 192.168.10.2 0.0.0.0
 no auto-summary
 

Note: Please see the no auto-summary blog entry for more information on what this command does.

In regards to the above two configurations, we have used one network command per interface, however, with R1, as its two interfaces have the same two octets, you can use one network command that covers both interfaces. Here's how: 

R1:

R1(config-router)#do sh run | begin router eigrp
router eigrp 10
 network 192.168.0.0 0.0.255.255
 no auto-summary


Doing this has the exact same affect as using two separate network commands, as you can see by R1's neighbor table: 

R1:

R1(config-router)#do sh ip ei ne
IP-EIGRP neighbors for process 10
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
1   192.168.10.2            Fa0/0             11 00:12:26  169  1014  0  13
0   192.168.20.2            Fa0/1             11 00:17:14 1311  5000  0  8


Please note though that it is best practice to be as specific as possible when dealing with things like route advertisements. Using a blanket network statement like the one used in this example is not always a good idea, especially when dealing with large, complex networks. It is also not ideal to use them on smaller networks because although you may think your network will never expand, it may some time in the future, so it is not a good idea to take shortcuts now that may make things difficult in the future.

As always, if you have any questions or have a topic that you would like me to discuss, please feel free to post a comment at the bottom of this blog entry, e-mail at myciscolabsblog@gmail.com, or drop me a message on Twitter (@OzNetNerd).

Note: This website is my personal blog. The opinions expressed in this blog are my own and not those of my employer.

Saturday, August 6, 2011

Dangers of the EIGRP "Neighbor" Command

I have touched on EIGRP a few times before and here we are again.

In my EIGRP Route Advertising post I explained how EIGRP neighbor relationships can be created using the "network" command. In this post I will explain how they can be formed using the "neighbor" command and the dangers of using it as well.

To do this, I'll be using the topology on the right.


To get started, let's create a "normal" EIGRP network on all of the routers using the "network" command.

R1:
 router eigrp 10
 network 172.16.11.1 0.0.0.0
 network 192.168.43.1 0.0.0.0
 no auto-summary


R2:
 router eigrp 10
 network 172.16.11.2 0.0.0.0
 no auto-summary


R3: 
 router eigrp 10
 network 172.16.11.3 0.0.0.0
 no auto-summary


R4: 
 router eigrp 10
 network 192.168.43.2 0.0.0.0
 no auto-summary


Once we have done that, all routers will have routes to one another. Here is an example of what R4's routing table looks like: 

R4(config-router)#do sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     192.168.43.0/30 is subnetted, 1 subnets
C       192.168.43.0 is directly connected, FastEthernet0/1
     172.16.0.0/29 is subnetted, 1 subnets
D       172.16.11.0 [90/307200] via 192.168.43.1, 00:07:39, FastEthernet0/1


One interesting thing to note, however, is the connection between R1, R2 and R3. As they have a switch connecting the three of them together, the EIGRP multicast packets sent by each one of them reach the other two routers. This in turn allows each router to form an EIGRP adjacency to the other two routers, as per the R2's output below: 

R2(config-if)#do sh ip ei ne
IP-EIGRP neighbors for process 10
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
1   172.16.11.3             Fa0/0             11 00:10:03 1573  5000  0  6
0   172.16.11.1             Fa0/0             14 00:10:40  118  1062  0  8


The reason why this is possible is because the switch creates a Layer 2 connection between them all. As multicast can happily travel on Layer 2 connections, the multicast packets can freely flow between the routers. However, as the connection between R1 and R4 is a Layer 3 connection, the multicast packets do not travel past that segment of the network, as per R4's output below: 

R4(config-router)#do sh ip ei ne
IP-EIGRP neighbors for process 10
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
0   192.168.43.1            Fa0/1             12 00:19:19  129   774  0  11


Performing a packet capture on R2, we can see EIGRP multicast packets being sent from both R1 and R3. These are the packets that make EIGRP adjacencies form and allow them to stay up. If these packets did not reach the other router(s), the adjacency would fail and the EIGRP neighbor relationship would be bought down.


So now that we have confirmed that our "normal" EIGRP setup is up and running and all routers can communicate with one another, let's discuss the "neighbor" command. What the "neighbor" command does is it sends EIGRP messages using unicast packets as opposed to the "normal" method of using multicast packets. However, a undesirable side affect presents itself when this command is used. The interface(s) that have this command applied to them no longer send or receive EIGRP multicast packets. To better explain this, let's change the configuration on R1 and R2.

Note: The "neighbor" command must be configured on the two neighboring routers. If it is only configured on one neighbor but not the other, the neighbor adjacency will not come up.

R1:
 router eigrp 10
 neighbor 172.16.11.2 fa0/0 

R2:
 router eigrp 10
 neighbor 172.16.11.1 fa0/0

Doing the above changes makes the EIGRP adjacency between the two routers drop out momentarily, as per the below logs: 

*Mar  1 01:42:37.887: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 10: Neighbor 172.16.11.3 (FastEthernet0/0) is down: Static peer configured
*Mar  1 01:42:37.991: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 10: Neighbor 172.16.11.1 (FastEthernet0/0) is up: new adjacency


As you can see from the second line, the adjacency comes back up. We can confirm this using the "show ip eigrp neighbors" command:

R2:
R2#sh ip ei ne
IP-EIGRP neighbors for process 10
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
0   172.16.11.1             Fa0/0             12 00:00:07   88   528  0  14


However, if we take a look at R3's logs and "show ip eigrp neighbors" output, we see a very different story - there are no adjacencies at all: 

*Mar  1 01:42:37.323: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 10: Neighbor 172.16.11.2 (FastEthernet0/0) is down: Interface Goodbye received

R3#sh ip ei ne
IP-EIGRP neighbors for process 10


As mentioned above, this is because the "neighbor" command stops that particular interface from sending and receiving EIGRP multicast messages. However, as this command is interface specific, only interface 0/0 on R1 and R2 are affected. This is why R1's fa0/1 interface is still able to maintain an EIGRP adjacency to R4:

R4:
R4(config-router)#do sh ip ei ne
IP-EIGRP neighbors for process 10
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
0   192.168.43.1            Fa0/1             13 03:26:18  129   774  0  11


If we perform a packet capture on R3 now, we can see that it is the only device sending multicast packets, as opposed to the packet capture screenshot above where we saw all devices sending multicast packets:


However, if we perform a packet capture on R2, we can see that it is not only receiving R3's multicast packets, but it is also sending and receiving unicast packets to and from R1:


In conclusion what you need to remember is that an interface cannot send and receive both unicast and multicast EIGRP messages, it is one or the other. It is important to remember this as it can be easily overlooked when troubleshooting an issue.

For those who would like to read more about the neighbor command, I stumbed across this blog which has a great write up about it.

As always, if you have any questions or have a topic that you would like me to discuss, please feel free to post a comment at the bottom of this blog entry, e-mail at myciscolabsblog@gmail.com, or drop me a message on Twitter (@OzNetNerd).

Note: This website is my personal blog. The opinions expressed in this blog are my own and not those of my employer.