First Hop Redundancy Protocol: VRRP
First hop redundancy protocols are important to any network, after all why should any carefully designed network be dependent on any single IP address or any single device for that matter? A FHRP allows us to make the default gateway for any subnet a virtual address that can float between multiple physical devices. However some of our FHRP choices are Cisco proprietary (IE: HSRP & GLBP), and recently I had to setup a FHRP between a Cisco router and Red Hat box, so VRRP was my FHRP of choice.
Now the configuration for VRRP for the Cisco side:
The VRRP 5 commands are what makes this happen. VRRP 5 is the VRRP group (and the router ID) this instance belongs to, next we have VRRP 5 IP 10.0.1.1 this where we specify the virtual IP address. This is going to the IP Address we want to ensure is available to our clients such as a default gateway. The VRRP 5 timers learn command tells this router to learn the VRRP advertisement timers from the master router. Next we have the VRRP 5 preempt delay minimum 60 this specifies a set of time in seconds before the master role is taken back.
Delaying the preempt may not appear to be inviting at first but it is useful. Let’s say the master comes back online and it resumes the role of the default gateway before it has had time to re-converge it’s routing table, well the VRRP master is now going to black hole traffic until your routing protocol re-converges.
Next we have VRRP 5 priority 150 this allows us to specify the priority of each router to control who will be the master router and who will be the backup router. The device with the highest priority is the device that will be the master router for VRRP. The final line in this configuration is the VRRP 5 track 1 decrement 100 command, this allows us to tie some type of tracking or IP SLA monitoring into the VRRP configuration. This way if the IP SLA or tracking mechanism goes down the VRRP priority will automatically be decremented ensuring this device will not be the master. After all, if the master VRRP router looses connectivity to the rest of the network due to an interface failure or link failure we don’t want it to be the master router anymore.
Let’s also go a step further an think about the preempt delay we spoke about earlier, lets say we set the preempt delay to 60 seconds and we are tracking the outside interface the preempt delay will make sure the outgoing interface is stable for at least 60 seconds before taking back its master role, now that preempt delay isn’t looking so bad now is it?
Now let’s verify our VRRP configuration using the show vrrp command:
This will show the current state of this router in the VRRP process, that state will either be Init, backup, or master. The Init state just mean VRRP is not running or is starting up. Next we see the virtual IP and the virtual MAC address, a VRRP virtual MAC address will start with 00:00:5E:00:01:XX where XX is going to be the Virtual Router ID (or VRRP process ID) Then we will see the preemption settings and our advertisement intervals. So the Show VRRP command provides us a nice summary of our VRRP configuration.
Now let’s check out some debug logs for VRRP:
The first message in there states the router received an advertisement with a priority of 150 from IP 10.0.1.92, then the VRRP event states that this priority is higher or equal to it’s own priority, the next advertisement has a priority of 0, and then the Master down timer expires, which causes the this router to become the master. The last few VRRP message show advertisements going with checksums, which is normal for VRRP operations.
I also figured I would show a VRRP Packet:
From here we can see the VRRP version currently running on the router. This will also show us the Virtual Router ID, and the IP address we are advertising along with the priority of the 10.0.1.92 host. Also check out the Layer 2 information Wireshark identifies that the MAC address is associated with VRRP and knows the Router ID is 5. Now check out the Layer 3 IP destination, it’s 224.0.0.18 so these advertisements are sent out via Multicast to all VRRP routers on this LAN.
More information on VRRP can be found in RFC 3768, note this RFC is for VRRPv2. RFC 5798 covers VRRPv3, but this post covers VRRPv2 running on Cisco routers. Cisco also has few articles to go over the configuration: VRRP & Configuring VRRP
You don’t have to block ICMP completely.
This is something that I typically see all over the place, security administrators blocking the ICMP (Ping) protocol completely. Normally I am ok with that, after all ping is a troubleshooting tool and in some cases not the best troubleshooting tool to rely on. However, it’s when people think their network is more secure when they have blocked ICMP. The truth is you can actually allow the ICMP types that are required for troubleshooting purposes without compromising security. So let’s first consider what ICMP messages we typically use for troubleshooting:
- Echo Request – ICMP Type 8 Code 0
- Echo Replies – ICMP Type 0 Code 0
- Time Exceeded – ICMP Type 11 Code 0
- Fragment needed but DF bit set – ICMP Type 3 Code 4
Now we all know the echo request is the icmp packet from the host to the target, and the echo reply is response from target back to the host. The time exceeded packet is returned to the host when performing a traceroute. The fragment needed but DF bit set packet is used for path MTU discovery and can used to troubleshoot MTU issues, it basically replies back telling you the packet was dropped because it needed to be fragment but the DF (Do not fragment) bit was set on the packet so it could not be fragmented.
One ICMP parameter that should be blocked are ICMP fragments, fragmented ICMP packets can be used to cause DoS attacks. Remember ICMP packets typically send 64 bytes of data, so you should only see larger ICMP packets or expect fragments when testing MTU. (Other then that I can’t think of any other legit reason to see large ICMP packets). RFC 1858 goes pretty in depth concerning the danger of IP Fragments, it’s definitely worth a read.
Now here is a configuration snippet that accomplishes everything I discussed here:
Now if you want to learn about ICMP in greater detail check out RFC 792.
Let’s look at Generic Routing Encapsulation (GRE)
Generic Routing Encapsulation, not much to say about it, its generic right? Well, it’s pretty tough to find a network that does not utilize GRE tunnels in one way, shape, or form. Whether they are Encrypted GRE tunnels or GRE tunnels riding over IPSec tunnels for branch connectivity chances are GRE is being used somewhere in your network. After all GRE provides us with various features that traditional IPSec tunnels do not offer us. Such as allowing multicast traffic to traverse the tunnel providing us scalability with the use of a routing protocol. It provides us these features because of how it interacts with the IP packet, some people refer to GRE as a layer 3.5 protocol because of how it encapsulates the existing layer 3 IP packet.
Below we can see how GRE interacts with the IP packet:
Notice you can see two sets of IP address in that packet, the first set of IP addresses (10.0.0.1 & 10.0.0.2) are the tunnel addresses, the second set of addresses under the GRE header is the real data that was sent through the tunnel, and it’s simple ICMP echo request from 1.1.1.1 to 2.2.2.2.
And for a closer at the fields within the GRE encapsulation.
Also notice the protocol type at the bottom, GRE can be used to encapsulate more than just IP Packets SNA, IPX, Appletalk and quite a few others can also be encapsulated with GRE.
More information can be in RFC 2784 which explains the IP Packet fields in greater detail then I covered here.
Now, as far as how the configuration goes for a normal GRE tunnel goes it is fairly minimal:
However, there are a few things that can be a little rough to get the hang of at first. The first thing unlike physical interface you can declare tunnel interfaces from configuration mode and you can start at any number. Now like any other interface you will want to assign your tunnel its own IP address since these GRE tunnels operate around layer 3 they will need IP addresses on the same subnet so both tunnel interfaces can communicate. The only other requirements for configuring a GRE tunnel is specifying the tunnel source and the tunnel destination. The tunnel source can be a physical interface or an IP address just keep in mind the tunnel source needs to be local on the router. The tunnel destination is going to the address of the remote router you are terminating the tunnel to. You will want to make sure the tunnel source and tunnel destination configured have connectivity to each other since it is between these addresses the GRE tunnel will run over.
There you go, GRE in a nutshell!
Debugging a specific IPSec VPN.
Let’s say you’ve got a router with well over 100 IPSec VPN peers, and you’ve got this one tunnel that just won’t form correctly. Your not sure why and want nothing more than to debug the IPSec process for this one peer but you know if you debug the isakmp or ipsec process your going to suck up way too much resources, what do you do? Well we are going to debug the IPSec process, but we are going to debug this for only the specific peer we are having trouble with.
First thing we need to do is define our debug crypto condition.
As you can see we can debug by quite a few different criteria, many of which will come in handy (some more than others).
So let’s create a condition that will look for a specific peer address.
Now if (or I should say when) you want to check the current debug crypto conditions you can issue the sh crypto debug-condition command, this is a good way for you check and see whether or not someone left a condition in there from a previous troubleshooting session that could affect the output you’re looking for:
So the sh crypto debug-condition tells us the conditional debugging is turned on and it’s filtering by the IKE peer IP Address. Now when you start debugging the crypto process you will only see messages that match the peer address of 10.1.1.1, which will certainly make looking through debug logs much easier.
Now if we want to disable our existing crypto debug filters, we issue the debug crypto condition reset command, this will remove all existing conditions and allow us to add new filters to troubleshoot another issue.
Working with Cisco Access Control Lists / ACLs.
I know ACLs, how complicated can they be and how hard is it to work with ACLs? Not a very tough concept right, well what happens when you want to add ACEs (Access Control Entry) into an ACL before other entries? Remember an ACL will match from the top down. I’ve seen people completely rip out an ACL just to put it back in with one addition entry. Let’s take a look at an ACL and what we can do to change this around.
Now here we got a simple ACL:
First thing we see on the left is the sequence number for each specific ACE, remember all ACEs are given a sequence number, and by default the first ACE starts at sequence number 10, and any subsequent ACEs are given a sequence number 10 digits up. This is why the sequence numbers are incrementing by 10.
Now, let’s say the 192.168.2.0 /24 network was recently subnetted and we need to deny FTP traffic from the 192.168.2.0 /25 subnet, well we need to add the new entries before sequence number 20. So let’s jump into ACL Configuration mode and see what we can do.
So from global configuration mode we enter ip access-list extended OutBoundAccess, make note you can also change standard ACLs like this. So this is not just limited to extended ACLs. Notice the configuration mode has changed, now we are in R1(config-ext-nacl)# allowing us to continue configuring this OutBoundAccess ACL. So let’s go ahead and continue with our configuration, first we want to start with a sequence number lower then 20 and we want to deny FTP traffic from the 192.168.2.0 /25 subnet.
Once we add the command we can issue the show command to verify the new ACE is in the correct location, and indeed it is.
Now let’s go a step further, let’s say we ran out of sequence numbers between 10 to 20 and we need get a few more ACEs in there.
Sure, we could add them before sequence number 10 but for the sake of this example let’s see we can’t. What we need to do is re-sequence the ACL.
We entered the command ip access-list resequence OutBoundAccess 10 10 resequencing the OutBoundACL starting with sequence number 10, in increments of 10. Look at the sequence numbers now. This allows us to keep adding entries where we need to. This definitely makes it easier to add entries and move entries around an ACL with minimal effort.
Passed QoS and got my CCIP!
Well after 7 months of studying and 2 exams later I’ve finally obtained my CCIP! When I initially thought about going after my CCIP I said this shouldn’t be too bad after going through Routing TCP/IP Volume II, BGP Design & implementation, and half way through MPLS fundamentals (See my Library page on the left for links) I was really starting to feel it. I kept moving along and passed the 642-691 I got a little bit of hope and jumped right into QoS. The funny thing about QoS was I didn’t realize how much I really new about it, nor did realize how much more I could do with it. QoS certainly was an interesting topic to learn, and I am sure I’ll be learning even more about it as time goes on.
Now that I’m done with my CCIP, I think I am going to take a small break from studying. I am going to focus back on my blog (So hopefully I will get some more updates out) and I am going to start building my own home lab for whenever I decide to start studying for my CCIE (not sure when but I will pursue that eventually). Not a bad way to start the new year right?
CCIE or Null! 