This is the first of many, many blog posts covering various topics I am studying for CCNP R&S. This week I am covering the Network Principles section from the ROUTE blueprint. These topics felt like a good way to get back into study mode. I had previously watched all of the ROUTE videos on CBTNuggets so I felt like diving into a book and getting into the ugly details was the way to go. I purchased “The Official Cert Guide CCNP Routing and Switching ROUTE 300-101” by Kevin Wallace off Amazon last week and got to it. Here are some talking points of the topics I’ve covered so far.
I was not familiar with Cisco Express Forwarding before this week. From my understanding CEF is a Layer 3 process which allows a Layer 3 switch or router to more efficiently (like wire speed) forward packets based on destination address prefix. The prefixes used to make forwarding decisions are stored in the forwarding information base (FIB) which is a mirror copy of the routing table! In addition to the FIB and routing table similarities, CEF also keeps an adjacency table. The adjacency table keeps track of nodes that are within a single Layer 2 hop. The setup of CEF is as easy as getting to global config mode to enable CEF, then adding a simple CEF configuration to an interface. Verification is as easy as issuing “show adjacency detail” command while in global config mode. I think I understand the concept of CEF, but I really don’t understand the use case yet. I don’t feel good about this topic at all. I’ll be spending some additional time in GNS3 to get a better grasp on the topic.
TCP Windowing is a topic that always catches my attention. It’s such a neat mechanism that always is forgotten until it’s broke. TCP is always labeled as the reliable protocol because of its’ ability to sequence segments and request re-transmissions for the segments that were dropped or missed. To me, TCP is nearly as efficient as it is reliable. This is where windowing comes in. Windowing allows multiple TCP segments to be sent while only expecting a single ACK from the destination host. The number of segments sent from the source increases exponentially (1,2,4,8…..) until an ACK is not received back from the destination host. At this point I believe the number of segments sent will increment by 1 until the process fails again. One area that did trip me up was understand how the sequence and acknowledgement numbers were generated for TCP headers. Essentially, the sequence number can be any number between 0 and 4,294,967,295 while the acknowledgement number is the sequence number + 1. This graphic from “The Official Cert Guide CCNP Routing and Switching” was a bit confusing because the ACK was the same number as the next TCP segment. In the end though, all the sequence numbers are essentially irrelevant.
IPv6 Migration is such a huge topic. It baffles me that it’s a subtopic of a subtopic in the CCNP ROUTE blueprint. Understanding the strategies of starting an IPv6 migration is the most important outcome from this section. Aside from the obvious guidelines, like making sure your network gear is IPv6 ready and checking to make sure your ISP supports IPv6 there are some interesting migrations strategies that can help cobble IPv4 and IPv6 together. The obvious choice when deploying IPv6 is to run IPv4 in parallel. This dual stack method will work well, but beware of any legacy clients or software that cannot do IPv6. This method allows a network engineer to slowly move from IPv4->Dual Stack->IPv6 once all legacy clients are out of the environment. It’s worth noting that IPv4 hosts cannot communicate with IPv6 hosts unless other migration strategies are used. These strategies include IPv6 NAT where we translate an IPv4 address to IPv6 address and 6to4 encapsulation where IPv6 packets are encapsulated in IPv4 packets. The book mentions two other strategies NPTv6 which is similar to NAT, but cannot do port translation aka overload. The other is IPv6-over-IPv4 tunnel which is similar to 6to4, but builds tunnel through the IPv4 portion of the network. Let’s argue about the differences another time.
I personally don’t see many Fortune 500 companies (outside of the large tech companies) moving to pure IPv6 anytime soon. It is certainly feasible for a company to provide access to the IPv6 Internet using one of the migration methods above, but there is little to be gained by deploying IPv6 internally. Eventually, when IPv6 does offer a better ROI it will be the legacy applications and devs that will hold progress back.
Here are some additional resources I found helpful.
See ya next week!!