All Entries in the "Cisco-routing" Category
Cisco: How to configure HSRP
In this post I proposed to discuss a little bit about Hot Standby Router Protocol and how it can be configured on a Cisco device. For this I have chosen the following topology:
I had in mind this scenario due to the fact that the traffic can take multiple paths in case of link being down and this give us the possibility to have a little bit of conversation on HSRP topic.
HSRP is defined in the document RFC2281 and according to the definition in this document: “The Hot Standby Router Protocol, HSRP, provides a mechanism which is designed to support non-disruptive failover of IP traffic in certain circumstances.” If you want to read more about the details how HSRP is working, please the RFC2281. I think there is not point in reproducing here what is already written there.
Regarding our topology, what you should know is that after configuring HSRP on R1 and R2 we will achieve a failover mechanism for the traffic from the Client (192.168.0.10) to the Server(10.10.10.10). From the beginning we will assume that R1 and R2 have the proper routing already configured to reach this destinations.
In the below presentation, you will see how the failover is achieved and what’s happening when you have a proper HSRP configuration in case that the link SC – R1 is broken:
So, how to achieve this behavior? From the topology you notice that proper configuration of HSRP involves 3 IP addresses from the same subnet (in our case this is 192.168.0.0 /24). One of the IP is configured on R1 the second one on R2 and the third one is HSRP IP address, which will be announced to the Client as gateway.
Configuration is straight forward on R1:
configure terminal
interface fa0/0
ip address 192.168.0.1 255.255.255.0
standby 1 ip 192.168.0.254
standby 1 priority 110
and on R2:
configure terminal
interface fa0/0
ip address 192.168.0.2 255.255.255.0
standby 1 ip 192.168.0.254
First we configure an IP address on the interface. Then we configure HSRP by typing the command “standby” followed by HSRP group (in our case group 1) and then the IP address. HSRP default priority is 100, and the principle is the higher the better. To force the path R1-SC to be the preferred one, we increse the priority to 110, making R1 to be the “Active” one. The other router, in our case R2, will have the HSRP status “Standby“. Maybe you are wondering what happens if you don’t configure the priority and both routers are having the same value 100. In this case HSRP has a mechanism that help it to chose the active router by comparing the IP addresses and chosing the one with the higher value. In our case this would be R2 (192.168.0.2 > 192.168.0.1).
Another useful feature that I recommend to configure for HSRP is “preemption“. The HSRP preemption feature enables the router with highest priority to immediately become the Active router. The configuration is also very simple and inquire only one additional line to the above ones:
standby 1 preempt
Also recommended is to configure “authentication“ between the HSRP participants:
standby 1 authentication somepassword
where “somepassword” can be what ever you want.
Going back to the topology, another scenario can take place. What if the link R1 – SC remains active, and instead the R1 – SS goes down. Since the R1 – SC is UP, the router R1 has no intention to cease the HSRP Active status. If you are having some kind of dynamic routing between R1 and R2, then you are on the safe side as the traffic will flow like in the scenario below (I’m assuming R1 to be the Active one for both R1-SC and R1-SS):
Remember that if do not have some routing between R1 and R2, the packets will be dropped on R1 as they will not have any path to the Server IP address 10.10.10.10.
This situation can be avoid with another HSRP feature, that will force the R1 to change it’s status from Active to Standby by monitoring the interface from R1 to SS. This feature is called “interface tracking“. This HSRP feature you have to configure at least on the router which is usual in Active mode:
standby 1 track FastEthernet1/0 30
In this scenario I assume that interface Fa1/0 is the connection to SS switch. This tracking command is watching for the status on the interface Fa1/0. When it’s status changes to “down” the “priority” value (110 in this example) is decremented with 30 (or whatever you will configure in the command line). After decremental, the “priority”
will have a value of 80 which is lower than the default one (100), forcing R2 to become the Active router and changing the R1 status to Standby.
Checking the status of an HSRP participant is very easy, and you can see this in the output below:
R1#show standby brief
P indicates configured to preempt.
|
Interface Grp Prio P State Active Standby Virtual IP
Fa0/0 1 110 P Active local 192.168.0.2 192.168.0.254R2#show standby brief
P indicates configured to preempt.
|
Interface Grp Prio P State Active Standby Virtual IP
Fa0/0 1 100 P Standby 192.168.0.1 local 192.168.0.254
All the HSRP configuration from this article can be fine tuned or extended according to your needs. I have presented here only the basics about the HSRP configuration. If you want don’t be afraid to explore and to “play” with the commands. Of course I would recommend to do that in test environment first.
Popularity: 12% [?]
Cisco: OSPF conditional inject of a Default Route
I believe most of you are familiar how OSPF is injecting a default route in a normal area. If not, you can find here all the documentation that you need. Please be familiar with this concept before reading this article.
Now, let’s assume that we have the following topology (click on image to have a more detailed view) :
As you can see we have a BGP peering between PE and CE router, with CE router having and OSPF connection with the Core. CE router is injecting a default route to Core:
router ospf 1
default-information originate always
This configuration is OK, but we can run into the following issue. Imagine that for some reason the BGP peering between PE and CE is broken (e.g. line being down), the CE router will have no clue about this and will still propagate the default route to the Core. In this situation, the Core will still forward all the packets without specific route to CE where it will have no further route to reach the destination, as the CE does not receive any route from the BGP peer. As you can imagine is better to avoid this situation, especially if for some reasons you are not monitoring the connection between PE and CE and you cannot react to change manually the route in case of a failure. We are lucky because some smart engineers have developed a solution to avoid this problem, called Conditional inject of a default route in OSPF.
With this solution, OSPF is monitoring the reachability of the point-to-point IP connection between PE and CE. When OSPF process on CE router notice that the IP connection is not available anymore, it automatically retract the propagation of the default route to the Core. The solution is simple an assume use of an ACL or prefix-list then match this on a route-map and finally use this route-map under “router ospf” process. For step-by-step configuration check below.
First we will create and ACL matching the IP subnet between PE and CE. In this example I’m using a p2p subnet 10.10.10.0 /30:
access-list 1 permit 10.10.10.0 0.0.0.3
Then I will match this into a route-map as follow:
route-map WAN-LINK permit 10
match ip address 1
Finall, we will use this route-map to implement the OSPF conditional injection of default route to Core router (192.168.0.0 /30 is the p2p IP subnet between CE and Core):
router ospf 1
log-adjacency-changes
network 192.168.10.2 0.0.0.0 area 0
default-information originate always route-map WAN-LINK
Now, the OSPF process on CE will inject a default route to the Core as long as the IP subnet between CE and PE is reachable.
IMPORTANT NOTE: This solution might not work if your connection from CE to PE is Ethernet and not Serial like in the example. I will explain why on the next post, when I’ll achieve the same behavior but using EEM together with an Ethernet based connection instead of a Serial one.
Please check below to see a small presentation how this is working on a test environment:
Popularity: 9% [?]
Cisco: How to selective drop packets without using an access-list
The title actually was a request that I encounter during my CCIE RS preparation. Of course, that in the real world, I would go straight forward and implement an access-list do drop selected packets. But since the lab environment is different for the real one, you might get a task like the above one.
Let’s assume that we have a network topology with a central router (R1) that connects 2 routers (R2 and R3), like in a hub and spoke diagram. Communication between R2 and R3 is done through R1. In this environment routing is already functional, implemented by dynamic or static routing (actually doesn’t matter this is not a topic for this presentation) and R2 can reach R3. We will drop all packets from R2 to R3, but telnet related packets (just to do things a little bit more interesting). As I specified before all this has to be achieved without access-list implementation.
Please have a look to this topology, to have a clear picture of the network environment. After you have checked the topology, watch the video presentation below:
Popularity: 8% [?]
Cisco: Engineer’s trick to avoid suboptimal path
I was explaining in the previous post what is the difference between optimal and suboptimal path and how to avoid the use of not such a good path in your routed environment. Also there I presented this so call “dirty trick” you can use to force the routing protocol to choose the path that you want, based on the Administrative distance modification.
As I said there is another way (for sure more than one) to do it, using a more elegant approach and from the networking point of view more safe considering the complex routing environment. I will use the same topology like in the previous post to offer you the possibility to compare these 2 methods presented and to choose the one that you understand and fit better to your needs. Also there are some other ways to do it and please feel free to discussed them in the comments section and maybe to present them here in a future post.
We will achive the desired results by setting one community on R1 for the advertised network 192.168.82.1 and dropping the prefixes, marked with the same community, on R2. Please be aware that for this method to work you have to allowed BGP peers to send communities list with the command “neighbor xx.xx.xx.xx send-community …” under “router bgp xxx” process.
Please see the example by clicking the image below:
Popularity: 12% [?]
