Connectivity alone is no longer sufficient in today’s digital world, and IT simplification plays a vital role in delivering seamless digital outcomes and unified experiences. To achieve this, organizations need to ensure digital experiences across all critical networks, making network and service assurance a strategic component.

Accedian, known for its expertise in network performance monitoring, enables the smooth operation of service provider transport and 5G networks. The company’s deep technical understanding, SaaS-first service assurance platform, and commitment to innovation have made it a trusted partner in the industry. By joining forces with Cisco, Accedian aims to leverage its critical capabilities and expand its solutions within Cisco’s Networking portfolio, building on the strong partnership they have established over the years.

Collaboration between Cisco and Accedian has already proven successful, as they have jointly delivered automation and assurance solutions for service provider customers through the Cisco SolutionsPlus program. With the acquisition, Cisco further enhances its assurance approach, empowering service providers with agility, efficiency, and scalability. Accedian’s portfolio, which includes microsecond-level sensors and the powerful Skylight Analytics platform, combined with Cisco’s robust offerings, will enable the delivery of transformational solutions to service provider customers.

One notable opportunity resulting from the acquisition is the integration of Accedian’s sophisticated network performance and user experience monitoring capabilities for CSP customers into Cisco ThousandEyes’ cloud. This integration will provide end-to-end network assurance, bringing unprecedented visibility and insights to enhance performance.

The acquisition of Accedian will be finalized during the first quarter of Cisco’s FY24, with the Accedian team joining Cisco’s Data Center and Provider Connectivity organization. Cisco is excited to welcome the talented Accedian team and work together to accelerate the vision of delivering high-performance assurance to service providers. The existing partnership between the two companies will continue to thrive, enabling seamless collaboration and innovation.

With this strategic move, Cisco reinforces its commitment to providing advanced network and service assurance solutions, empowering organizations to meet the evolving demands of the digital era.

What is BGP?

BGP, or Border Gateway Protocol, is an exterior gateway protocol designed for exchanging routing information between autonomous systems (ASes) on the internet. Unlike interior gateway protocols (IGPs) such as OSPF or EIGRP, which operate within a single network, BGP enables interdomain routing, making it the glue that connects the various networks forming the internet.

Working of BGP:

1. AS and BGP Speakers:
   At the heart of BGP are autonomous systems (ASes). An AS is a network or a group of networks under a single administrative control, following a common routing policy. Each AS participating in BGP has at least one BGP speaker, which is a router responsible for running BGP and exchanging routing information with other ASes.
2. BGP Peering:
   BGP peers establish TCP connections to exchange BGP routing information. Peers can be classified into two categories: internal BGP (iBGP) peers within the same AS and external BGP (eBGP) peers between different ASes. These peering relationships allow BGP speakers to exchange routing updates, negotiate capabilities, and synchronize routing tables.
3. BGP Messages and Attributes:
   BGP operates through the exchange of messages between peers. The two main types of BGP messages are Update and Keepalive. Update messages carry information about reachable network prefixes and associated attributes. Attributes define additional properties of the routes, such as path preference, metrics, or policy attributes.
4. BGP Path Selection:
   BGP uses a set of rules to determine the best path for reaching a destination network. These rules consider various path attributes, including the length of the AS path, the origin of the route, the next-hop address, and optional attributes like communities or local preference. BGP selects the path with the highest preference, preferring customer routes over peer or provider routes based on configured policies.
5. BGP Route Advertisement:
   BGP allows ASes to advertise their routes to neighboring ASes. When a BGP speaker learns a new route, it can propagate the information to its peers. This process of route advertisement propagates across ASes, ultimately allowing global reachability of networks on the internet.
6. BGP Stability and Convergence:
   BGP aims to provide stable and loop-free routing. It achieves this through mechanisms like route dampening, which suppresses unstable routes, and route reflectors, which simplify the propagation of routing information within large ASes. BGP convergence refers to the process of updating routing tables and ensuring consistent routing paths in response to network changes or failures.

Border Gateway Protocol (BGP) plays a crucial role in enabling interdomain routing on the internet. It facilitates the exchange of routing information between autonomous systems (ASes), ensuring the efficient delivery of data packets across networks. By following a set of rules for path selection and employing various mechanisms for stability and convergence, BGP forms the backbone of global internet connectivity. Understanding BGP’s fundamentals is essential for network administrators, as it allows them to optimize routing decisions, troubleshoot issues, and ensure the reliability of internet connectivity for their organizations and users.

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.

HSRP ELECTION: HSRP PRIORITY

What is the criterion for becoming the active device? -> the configured priority. The higher the priority value, the better. You can configure the priority value from 0-255. What if you don’t configure the priority value? Then the default is 100. What if they have the same priority value? Then, the highest configured IP address will be the active device.

NICE TO KNOW:

• You can configure up to 255 HSRP groups. It is locally significant so you can use the same HSRP group number for all the VLAN interfaces. However, it is recommended to match the group number with the VLAN number to avoid confusion or configuration error.
• HSRP uses a virtual MAC address of 0000.0C07.ACxx where xx is the hex value of the HSRP group number. For example,

a. HSRP group number is 1, then the MAC address is 0000.0C07.AC01
b. HSRP group number is 100, then the MAC address is 0000.0C07.AC64

HSRP TOPICS:

• HSRP Versions
• HSRP and Object Tracking
• HSRP Lab Configuration
• HSRP States
• HSRP Authentication
• HSRP Troubleshooting
• VPC and HSRP

Yeah!

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.

Though they always said that it’s not good to compare, it’s not true in the networking technology or maybe in other technologies not only in the network world. We always compare. Like in IOS, NX-OS requires all the members of port-channel to have compatible parameters. Else, the port-channel will not form.

So, the first thing that you need to do is to verify whether the following parameters are the same for all member ports:

• port mode
• speed
• MTU
• shut lan
• MEDIUM
• span mode
• load interval
• Access VLAN, Trunk native VLAN, and Allowed VLAN list
• 802.3x flow control setting

How do you do that? Use the “show port-channel compatibility-parameters” command. We will discuss more of it in my future port-channel lab post.

Another thing that is important to take note is that Cisco NX-OS does not support PAgP. The Cisco proprietary Port Aggregation Protocol (PAgP) is not supported for some reasons.

PORT-CHANNEL TOPICS:

• Default Port-Channel Parameters
• Port-Channel Basic Settings
• Configuring Port-Channel
• Port-Channel Load Balancing
• Port Channel Verification

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.

There is, however, another limitation. IOS VTP pruning is only good for normal VLAN range but in Nexus 5K (Nx5K), it does not support VTP pruning at all.

In NX-OS, the default mode is disabled. Like the routing protocols that need to be enabled manually, you also need to manually enable VTP using the “feature vtp” command. Moreover, NX-OS supports VTP mode off. Off mode behaves like transparent mode but it does not forward VTP packets on trunks.

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.

The use of redundancy in Route Reflectors may introduce routing loops in the network. However, no need to worry as Route Reflector has Cluster_List and Originator_ID attributes.

Route Reflector and its Clients formed a cluster. Each cluster must have a unique Cluster ID. The Cluster ID is being prepended to the “Cluster_List” each time the route is being reflected. Cluster_List is an Optional Non-Transitive BGP attribute. Remember the BGP Path selection process? It is the 12th criteria of BGP selection attribute. Like AS Path, the minimum cluster list length is more preferred. Also like AS Path, it shows the path the route has passed. It also serves as a loop avoidance mechanism as it discarded routes with the same local Cluster ID. Take note that Cluster ID is configured in Route Reflector. When a Route Reflector receives a routing update from another Route Reflector in the same cluster, it rejects the update.

There is another loop avoidance mechanism of Route Reflector and that is the Originator_ID. It is another Optional Non-Transitive BGP Attribute and as the name suggests, it identifies the originator of the route. The router ID is added as the Originator_ID to the route when received from eBGP peer and when there is already one exists, a router needs not to add another Originator_ID. When a routing update is received from the same local Originator_ID, then the update is discarded.

All other that are not part of the cluster are non-clients. Non Clients do not support Route Reflector functionalities. Unlike with Clients, Non-Clients need to fully mesh.

Route Reflector Forwarding of Prefixes Rules

Route Reflector propagates eBGP learnt prefixes and iBGP prefixes learnt prefixes from Clients and Non-Clients to Clients. Route reflector propagates eBGP learnt prefixes and iBGP learnt prefixes from Clients to Non-Clients. It will not forward learnt iBGP prefixes from Non-Clients to Non-Clients.

Before we end this discussion, there is one more important thing to remember. A Route Reflector can reflect route only within a single cluster. It can participate in multiple clusters but only as a client. A client can only function as a client only to Route Reflector belonging to the same cluster.

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.

“Who is going to ask me this stupid question?”

I guess an interviewer who has a doubt about your skills most especially if you put all your certifications on your resume. Funny, but it is pretty quite true.

“Is the interviewer going to judge me if I forgot what EIGRP packet header contains?”

Uhm, maybe. Depends on many reasons. We can say, the interviewer is using a bottom-up approach. In this way, it saves time and may not continue asking you further questions if you did not know the basic. Or, it can be a warm-up for more heart-pounding questions.

“What if you just forgot and neglect it during the academy session?”

I don’t think the interviewer will be interested in that kind of reason. So, if you were not able to answer, you better pray that the interview will not stop there.

I don’t want to scare you because this is just a legend. It is a traditional story popularly regarded as historical but nobody wants to confirm the truth. Anyhow, it is just my way to open up our “EIGRP Packet Header” discussion.

1. Version – This is the EIGRP header version with the current version of 2. This is a 4-bit field and it is not the same as the TLV version field.
2. Opcode – Remember the EIGRP packet types? This is how EIGRP neighbors know what kind of packet type it is. It is a 4-bit field as well like the version field and below is the equivalent values of message types:
   EIGRP Message TypeOpcode ValueUpdate1Request2Query3Reply4Hello5Reserved6-9SIA Query10SIA Reply11
3. Checksum – this is 24-bit field standard IP checksum. If the packet fails the checksum, the it is discarded.
4. Flags – This is a 32-field that defines special handling of the packet. There are 4 flag bits: INIT flag (0x01), Conditionally Received (CR) flag (0x02), Restart (RS) flag (0x04), and End-of-Table (EOT) flag (0x08). For newly discovered neighbors, the bit is set in the initial UPDATE. The INIT flag instructs the neighbor to advertise its full set of routes. CR flag is that receivers should only accept the packet if they are in Conditionally Received mode. RS flag is set in the HELLO and UPDATE packet. It is an indication that the neighbor is doing a soft restart. This In this way, adjacency is maintained. When EOT flag is set, it indicates that the neighbor has completed sending all updates. This indicates the neighbor can flush all stale routes prior to restart event.
5. Sequence – Every packet sent to the neighbor will have a 32-bit sequence number that is unique to the sender. When the value is set to 0 that means it doesn’t require any acknowledgement. 
6. Acknowledgement – this is another 32-bit field sequence number that is unique to the receiver.
7. Virtual Router ID – This is a 16-bit number that distinguishes the virtual router a packet is associated with. Any value other than listed below, will be discarded:
   
8. Autonomous System – This is the most important part in the EIGRP packet header. This is a 16-bit number which value ranges from 1 – 65535. AS should match on all EIGRP neighbors or else packet will be ignored and there will be no adjacency.

OSPF IN DOWN STATE

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.

OSPF IN ATTEMPT STATE

“ATTEMPT” state only exist on NBMA networks. The router is sending Hello packets but these are not received by its peer.

OSPF IN INIT STATE

This is the same with the “CONNECT” state of BGP. When OSPF is in INIT state, that means that the router sees the Hello packets from the neighbor but the two way communication is not yet established. The receiving router should list its own router ID to acknowledge that it has a received a valid Hello packet.

It is not good to see a neighbor that stays on “INIT” state for a long time. There are many reasons why OSPF neighbor adjacency is stuck in “INIT” state.

• It can be a configuration/mismatch on the following parameters like Hello/Dead Timers, network mask, and Area ID.
• It can be an authentication issue. When authentication is used, make sure that authentication type and authentication key matches on both ends.
• For some reason, an access-list for OSPF multicast address 224.0.0.5 is being denied, this also causes the router to stay in “INIT” state. This address plays an important role in the two-way communication because this is the destination address of Hello packets.
• If you are configuring static frame-relay and/or dialer map and you forgot the “broadcast” keyword, it would also be an issue and make you stuck in this state. The use of the “broadcast” keyword is required if broadcast and multicast traffic is to be sent over the specified DLCI.
• Finally, it can be a Cisco bug (Cisco bug ID CSCdj01682). Try to issue “show ip ospf interface” command and check the “Neighbor Count” and “Adjacent Neighbor Count.” If the “Adjacent Neighbor Count” is higher than the “Neighbor Count” then it could be a bug.

OSPF IN 2WAY STATE

At this stage, two-way communication has been established. The router has seen its own router ID in the neighbor field of the neighbor’s packet. Do not be alarm if your routers are in “2WAY” state. In a multiaccess segments where DR and BDR are present, all DROTHERS (Not DR/Not BDR) will stay in “2WAY” state. This is normal and expected behavior as those routers will synchronize their database with DR and/or BDR only.

When there is no issue, the router checks if it is already listed as neighbor in its peer. If it is, it resets the dead timer and neighbor relationship is already formed. If not, it goes to “EXSTART/EXCHANGE” state.

OSPF IN EXSTART STATE

This is the state when the bidirectional communication has been established and in multiaccess segments, where DR and BDR election is completed, the routers enter the “EXSTART” state and start the Master/Slave relationship. In a Master/Slave relationship, it is determined by highest priority and/or router ID.

OSPF IN EXCHANGE STATE

Once the Master/Slave relationship is negotiated, the Master starts the exchange of Database Descriptor. After Master sends its DBD, the Slave sends its own DBD. If no issue occurs, it goes to “LOADING” state. However, if OSPF is stuck in “EXSTART/EXCHANGE” state the main reason is a mismatched MTU. It usually occurs when connecting a Cisco router to non-Cisco router.

A router with the higher MTU continues to accept the DBD packet of the router with the lower MTU. It will be stuck in “EXCHANGE” state. On the other hand, the router with the lower MTU will stay in “EXSTART” state. It will discard the DBD packets and will continue to retransmit the initial DBD

OSPF IN LOADING STATE

Once DBDs are acknowledged and reviewed, it now goes to “LOADING” state. OSPF stuck in “LOADING” state and generates OSPF-4-BADLSA error message is not normal. This means that LSA being exchanged is corrupted. Contact Cisco TAC support.

OSPF IN FULL STATE

IN “FULL” state, neighbors have formed and they have now the same Link State Database (LSDB).

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
Culloden(config-if)#shut
Culloden(config-if)#end

2. CONNECT – This is when BGP starts to do the TCP connection (TCP three-way handshake). Either of the BGP neighbors will initiate the BGP session. Once completed, it jumps towards the OPENSENT state. However, if there is a problem, it goes to ACTIVE state.

3. ACTIVE – At this stage, TCP connection is completed but no BGP messages have been sent to the BGP neighbor yet. There are many reasons why BGP is stuck in ACTIVE state. Usually, there are configuration issues that stop the BGP connection from getting established. It can be a wrong AS, misconfigured local IP / peer IP address, authentication issues, and others.

. OPENSENT – BGP Open message is already been sent to the peer but not yet received to the other end. You won’t usually see BGP stuck in OPENSENT state. It will immediately toggle to OPENCONFIRM state and ESTABLISHED states.

5. OPENCONFIRM – BGP Open message and keepalive has been sent and received. It won’t take long until it goes to the ESTABLISHED state.

6. ESTABLISHED – Once all the BGP requirements of establishing neighbor adjacency are met, it goes to the ESTABLISHED state. You will see prefixes Once adjacency is established between BGP neighbors, they are going to start exchanging routing information.

Putting back my s2/2 link up, makes my BGP back to ESTABLISHED state:

Culloden(config)#int s2/2
Culloden(config-if)#no shut
Culloden(config-if)#end
Culloden#

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.

This is true with partial mesh topology in iBGP. There is no route back to Colletidae.

With the use of next-hop-self command, it would force the iBGP speakers to advertise the route with the next hop address of its own.

Let’s do a simple lab about this scenario.

Let’s see what will happen after Dasypoda advertised its loopback address.

Enter configuration commands, one per line. End with CNTL/Z.
Dasypoda(config)#router bgp 600
Dasypoda(config-router)#network 6.6.6.0 mask 255.255.255.0
Dasypoda(config-router)#end

After Dasypoda advertised its loopback address, Colletidae learned it and install it in its routing table: