Hot Standby Router Protocol (HSRP) Overview: You’ve Got A Friend

When you’re down and troubled and you need a helping hand
And nothing, whoa, nothing is going right
Close your eyes and think of me and soon I will be there
To brighten up even your darkest nights

You just call out my name, and you know wherever I am
I’ll come running, oh yeah baby, to see you again
Winter, spring, summer, or fall
All you got to do is call and I’ll be there, yeah, yeah, yeah
You’ve got a friend

Whenever I see Hot Standby Router Protocol (HSRP), it always reminds me of a song. As what James Taylor said, “You’ve Got a Friend.” If you already know what HSRP is, you might’ve as well other things that make you remember what it does.

If you’re kinda new and trying to understand what this is, this is a good start as I will not make this topic complicated. Although there are lots of things to tackle with HSRP, we will stick with the basics and some links are provided below to further discuss other HSRP topics.

HSRP is not a router and definitely not a routing protocol. When I first studied HSRP, the first thing that came up in my mind is that this is a routing protocol like EIGRP, BGP, OSPF, or RIP but it isn’t as it does not affect the routing table.

HSRP is a Cisco proprietary redundancy protocol. One device will act as active and the other is passive. Once the active device is down, the passive device will take over. The active device will be responsible for handling the traffic of the VIP (virtual IP). Since the VIP is shared between these two devices, when the active device fails, traffic will failover to the standby device. However, keep in mind that pre-emption is not enabled by default.


Port-Channel in NX-OS: Let’s Bundle Up!

I am pretty exhausted after having a great NYE. It’s the third week of January but it feels like I need six months of hibernation after 1 night of celebration. If you are feeling the same way, well, we definitely meet up because we’re a good fit for each other. We’re compatible! Let’s be friends!


The topic I like to discuss today is about port-channel in Nexus. Port-channel bundles physical links to form one logical link by using the channel group that provides aggregated bandwidth and redundancy. On the M-series module, you can bundle up 8 physical links but with the release of Cisco NX-OS 5.1, you can bundle up to 16 ports on the F series module. The Port-channel feature does not need a license in order for you to use it. However, since you are going to use VDCs, you need to have the Advanced Services license. This need to be installed before you configure ports within the VDC. Make sure that all member ports are in the same VDC. You can have them configured in any desired VDC but if you are going to configure the load balancing, you must do it in the default VDC. (more…)

VLAN Trunking Protocol (VTP) in Nexus NX-OS – Slight Difference with IOS

VLAN Trunking Protocol (VTP) is also available in Nexus NX-OS. The creation, modification and deletion of VLAN are easy with the use of VTP. Like in the Cisco Catalyst switches, the configuration is just the same. There is not much difference when configuring it but there are some few things to take note. These things make it unlikeable to deploy VTP in a data center environment.

Firstly, let’s discuss VTP version 3. Do you recall what is VTP version 3? Ok, this is the 3rd version of VTP. So what’s the difference with this new version compare to old versions? VTP version 1 and 2 only support a normal range of VLANs from 1 – 1005 but VTP version 3 expands the VLAN range up to 4094. Yes, it is supporting the entire VLAN range! It also supports enhanced authentication where you can configure the password as hidden or secret. VTP version 3 also supports MST and transfer information of private VLANs. Not only that, there is primary server and secondary server concept here where the primary server is responsible for updating and sending updates to VLANs while secondary server serves as a backup. Interesting right? However, in Cisco NX-OS there is no VTP version 3. Yeah, after giving you a lot of exciting features, you cannot use it in Nexus. (more…)

BGP Route Reflectors (RR) – The iBGP Reflection Mechanism

Light when bounces off an object is called “reflection.” Remember the “Law of Reflection” during High School days? The angle of incidence equals to the angle of reflection. Thinking about this might somehow give you a better grasp on the BGP Route Reflectors. As we progress this topic, you will see how routes are reflected.

Remember the split horizon rule in iBGP? Route Reflector (RFC 4456) is one of the three solutions and often use as an alternative to Full Mesh topology. Route Reflectors allows iBGP speaker to have partial mesh topology while still propagating iBGP routes to another iBGP speaker. It modifies the iBGP split horizon rule by allowing the router to forward incoming iBGP updates to an outgoing iBGP session under. With Route Reflector, it lowers CPU and memory requirements by reducing the number of TCP sessions to be maintained.

Route Reflector has two iBGP peers: Client peers and Non-Client peers. Route-Reflector clients behave like normal iBGP routers. They are not required to form full mesh, can have any number of eBGP sessions and they can have only one iBGP session and that is the connection to Route-Reflector. When Route Reflector fails, they can no longer receive or send updates to the rest of the AS. In this kind of design, Route Reflector represents a single point of failure. In order to solve this, we need redundant Route Reflectors. Each Clients needs to connect to redundant Route Reflectors. Route Reflectors receive the same iBGP update from its Clients and reflect it all other Clients and Route Reflectors send same routes to each Clients.

Route Reflector


The EIGRP Packet Header

Virtual Router IDAustonomous System (AS)

Believe me or not, aside from passing an exam there is another important reason why you should know what is inside the EIGRP packet header. Any hypothesis?

The Job Interview

You thought you know everything when you got the Cisco professional level certification but what happens when the interviewer asked you about what is inside the EIGRP packet header? You memorized all the configurations commands. You know what is BGP route reflector. You know how to do unequal load balancing in EIGRP. You even know how to configure fabric path, ASA firewalls, and do site-to-site VPN. You know everything you did in your laboratory but you forgot what is inside the EIGRP packet header.

OSPF Neighbor Adjacency States: From Down To Full

Like BGP neighbor adjacency states, OSPF has its own too. OSPF neighbor adjacency is not a bit straightforward. You might be expecting it should be in “FULL” state for the neighbor adjacency to be established, but you shouldn’t be assuming that it needs to stop at this state at all times.


Hello packets are very important parameters in establishing adjacency in any routing protocol not only in OSPF. Now, if no hello packets have been received from the neighbor and the dead timer interval has expired, OSPF is in DOWN state. The first OSPF neighbor state is “DOWN” state. It usually happens on Non-Broadcast MultiAccess (NBMA) networks and Non-Broadcast Point-to-Multipoint networks where neighbor is manually configured.

BGP Neighbor Adjacency States: From IDLE to ESTABLISHED

BGP requires manual configuration of neighbors. Once neighbors are manually configured, it goes through 6 states until it is fully established. Knowing these states would help us determine the stage our connection is currently in. It is also very important in troubleshooting as it helps us understand what went wrong during adjacency.

BGP Neighbor Adjacency States

BGP Neighbor Adjacency States:

1. IDLE – This is normally can be seen if BGP is down / administratively down or just waiting for the next attempt. At this stage, no BGP incoming sessions are permitted.

My BGP is established between Culloden and Stirling sites and Culloden and Fyvie sites. But when I shut down s2/2 link between Culloden and Fyvie, my BGP went to IDLE state.

Culloden(config)#int s2/2
BGP-Neighbor-Adjacency-States: IDLE STATE


iBGP: BGP Next-Hop-Self Command

The BGP next hop processing distinguishes iBGP from eBGP. A route advertised from an eBGP to another eBGP peer, the next hop address will be the address of the exit point of that AS. A route advertised from an eBGP to iBGP, the next-hop address remains unchanged when sent to another iBGP peer. It will not insert its own address as the next-hop address of the advertised route. The problem here is, what if that iBGP peer doesn’t know how to reach that eBGP address?

BGP Next-Hop-Self
BGP Next-Hop-Self

Let’s take this scenario.

Colletidae, a blellum lady living in the outskirt of Edinburgh, told her neighbor Apidae that Dasypoda is having an illegal affair with somebody else. Colletidae told Apidae that she can spread that in town. And, because Colletidae wants so much attention, she told her to tell everybody that she is the one who told her about it. Colletidae knows that everybody will believe Apidae as she is known to be an honest quine. Apidae cannot believe it and she told Andrena, sister of Andrenidae, about this.

“Don’t be such a wee clipe!”, said Andrena. “Are you the one spreading that rumor?”

“No, it’s not me. It’s Colletidae who told me about that.” Apidae replied.

When Andrena told her sister about this rumor,

“Who told you that?” Andrenidae asked

“Colletidae knows everything about Dasypoda’s affair,” Andrena whispered.

“Who is Colletidae?” Andrenidae asked.

Andrenidae, who is one of Dasypoda’s best friend, knows that it was her sister who told her about the affair rumor. What she didn’t know is that it was Apidae who told her sister about this and that Apidae knows where Colletidae lives. (more…)

BGP Path Attributes: The BGP Path Selection Process

BGP Path Attributes

BGP has many attributes in choosing the best path. It is like an ice cream. It has many flavors. I bought Gianduia flavor from Gelato Messina while I was preparing this topic. I think I need loads of sugar to feed my brain as this BGP topic is robust and every attribute can be well-explained if we are going to lab it.

BGP’s attributes are mainly for path manipulation and these can influence either outbound or inbound traffic. It has a systematic process that it uses to choose the best path in the network.

BGP Path Selection Algorithm

The first thing that BGP checks is whether the WEIGHT is configured or not. WEIGHT is Cisco Proprietary so it is obvious that it prioritizes Cisco devices which has BGP WEIGHT configured. In short, if you are using Cisco devices, WEIGHT is the first thing it checks before it goes on with the series of standard BGP attributes. Keep in mind that WEIGHT is local to the router and doesn’t pass to other routers. The higher the value is more preferred. (more…)