A Simple Routing Protocols Decomposition Model - Part 2 (Peering Mgmt.)

 

So in the first part of the series, we started with rather a simple decomposition model to get bit more insights into the routing protocol internals.

So let's continue the series by expanding on the very first layer in our model - Peering Management.

In any routing protocol before we get fancy in terms of which all features, functions and knobs to use, the very basic requirement is to peer with other devices into the network since eventually a routing protocol is nothing but a distributed database. Routing protocols are designed to convey different set of information to its peer devices such as:

- Topology Information

- Reachability Information

- Policy Information

The type of information that a given routing protocol would exchange with its peers would largely depend on the protocol itself (OSPF, IS-IS, BGP) & where that proposed routing protocol is used into the network (Campus, WAN, Metro-E, DC) as implementation specifics do change.

[ Click on Image to Enlarge ]

As you may notice, there are lot of things working behind the scenes when it comes to peering in a routing protocol context. But don't get carried away by looking at the complexity. Once you look closely, all of these pieces kind of makes sense.

So let's start with the top row, reading it from left to right. 

Self Identity - Before the routing protocol determines whom it needs to communicate with and what information needs to be exchanged, it must find its own identity first. The most common way to give an identity to the routing protocol instance itself is assigning it a router id (RID). The RID can be configured manually or it can be derived automatically depending upon the platform and NOS. 

In real life assuming network virtualization is much more common today, you are allowed to configure unique RID for each routing protocol as well as a unique RID for each instance/process under same protocol. 

Protocol Addressing - Once the routing protocol is able to define its identify with a RID, the next step is to understand it's addressing. The addressing serves many purposes but the most basic one is to provide location services from the overall network view standpoint. Though protocols such as LISP was an attempt to separate device identity from device location, due to limited use cases (such as mobility) and other problems it never really took off well.

Every routing protocol has it's own addressing scheme which may further have impact on its scaling and expected working behavior if not done correctly.

Participation - The next step for the routing protocol is to determine its participating interfaces on a given device and in certain cases the entire device itself. Depending upon the design you may run into some interesting challenges though.

Reliable Transport - Every routing protocol needs a reliable transport to be able to effectively communicate with its peer device. The reliability itself is an important aspect and while some routing protocols such as BGP rely upon existing TCP stack, others like OSPF uses IP protocol 89 & EIGRP choose its own transport protocol namely RTP.

Neighbor Discovery - In the next step the protocol must discover its peer/neighbor/adjacent device depending upon which routing protocol you are following. The protocol while ideally should keep a track of its neighbor and relationship state, this may or may not be implemented.

The neighbor could be configured manually or dynamically discovered, while the discovery phase itself may use unicast or multicast as a transport for reachability purpose to the next hop device. Also the reachability to the neighbor could be over layer 2 transport or layer 3 transport depending upon the protocol. IS-IS and many other IOT industrial protocols operate at layer 2 for example. In case of eBGP, the neighbor in fact may be multiple physical hops away.

Neighbor Identity - While we may have discovered our neighbor, it doesn't mean the neighbor itself is a an intended neighbor or a legitimate neighbor always. After all someone might want to spoof or sometimes we may end up discovering somebody completely un-intentionally. So sharing any information with an unexpected neighbor won't make any sense. To prevent this we have several measures which we can put in place such as Authentication, Validating neighbor's identity (remember they also have RID), Validating neighbor based on IP Packet's TTL value etc. such as in OSPF & BGP. The modern day solutions such as SD-WAN usually uses RPKI over TLS/DTLS channel.

Establish Session - Once the neighbor is discovered and validated, we finally establish a session with it. Depending upon the protocol, we might have a single session vs. multiple sessions going on. A simple example would be networks running IPv4 & IPv6 at the same time under single routing protocol instance. While some implementations exchange information related to both IPv4 and IPv6 over a single session, some may do it over a separate dedicated session for each of them. Long time ago there was an attempt to run multi session bgp for MTR (Multi Topology Routing) for network virtualization use cases.

Capabilities Exchange -  This is an another interesting step where the routing protocol running on separate devices exchange capabilities with each other to find the lowest common denominator. For example we know BGP is more like an application that runs on top of TCP as opposed to a pure layer 3 routing protocol which only carries routes. BGP though can carry layer 3 routing information and in case with most vendors it's been the default behavior, BGP does allow us to carry many other set of information depending upon the use case in the form of AFI/SAFI which is essentially an encoding format. For example BGP can carry MAC Addresses information under Layer 2 VPN EVPN address family when enabled. Though with BGP, you got to be cautious about enabling a new capability/address family in production network as highlighted here.

Establish Adjacency - The protocol reach this far and finally the peers are ready to exchange required set of information needed to populate RIB & other details such as topology graph. An interesting example in a routing protocol context would be (In case you are wondering in which scenario two devices would be neighbors but not adjacent) OSPF.

Messages Exchange - Finally we [assuming by now you are thinking like a routing protocol :) ] reach this stage where in we finally start exchanging information through messages. The messages needs to be sent reliably, keeping track of to understand which one to prefer in case of being received from multiple sources, acknowledged and so forth besides how to queue and dequeue them and at what intervals those should be sent out vs. being hold back for a while to pack multiple events together for optimization and getting the latest information being sent out.

Further Readings:

Cisco IP Routing: Packet Forwarding and Intra-domain Routing Protocols: Packet Forwarding and Intra-domain Routing Protocols 

Network Routing: Algorithms, Protocols, and Architectures

Network Algorithmics,: An Interdisciplinary Approach to Designing Fast Networked Devices

Inside Cisco Ios Software Architecture

HTH...

A Network Artist 🎨

A Simple Routing Protocols Decomposition Model - Part 1

 

You might have heard about this term "Mental Models" earlier too. Mental models are essentially a very simple yet very powerful tool. At its core the purpose of mental models is to provide you with necessary tools and building blocks in order to understand how something is really built and how it works behind the scenes.

Whether we recognize this or not, we all have mental models of some kind in our mind that we use and apply to situations in our daily life. It's just that some of those are developed consciously to solve certain problems or how to we approach certain things, on the other hand some of those are genetically coded into our DNA by nature.

A quick example of consciously developed mental model would be "How do you manage your finances" while the unconscious one would be to "Run fast when you see a lion charging towards you".

The mental models can be simple or complex, layered and even blend of multiple models depending upon how complex the topic is at hand and how deep you want to go down the rat hole beside in some cases tracing down the roots of the real problem into its adjacent domains.

Last but not least, your experiments and experiences always help you enrich you mental model aka "Lesson learned the hard way". On the flip side mental models do create "biases" if totally ignored, as one of the tradeoffs to follow them. But we will keep that topic besides the other tradeoffs for another time.

Now you might be wondering:

1. What is than Decomposition Model

2. Do we have some of those being available for IP Networking

To answer the 1st one - The famous consulting firms were looking for some more glamorous term which would resonate better with business people, after all technology details looks boring to them for most part and they started calling it "Decomposition Models" and heavily use this term in various cases such as for "Maturity Model" .

Coming back to 2nd one which is more relevant for this conversation, IP Networking actually taught us few mental models at the very beginning of our career as Network Engineers in the form of - OSI Model, TCP/IP Model, RINA Model, Hourglass Model and so forth. But as we advance further into our journey, the numbers of models available to us starts to shrink if not completely disappear with an ultimate answer to every question not as the "number 42" but the magical two words " It depends ". Standard bodies such as IETF, IEEE, MEF & ONUG etc. don't offer much help either for the most part.

But then nothing stops you from to being a little more creative and come up with your own models.

Let's start with a " Routing Protocol Decomposition Model ".

It's a multi-purpose simple yet effective model that you can consider for :

- As a Routing Protocol Designer it allows you to breakdown the complex equation into smaller chunks

- As a Network Architect it allows you to breakdown you design choices into smaller & distinguishable sections/containers and allow you to tune the variables to achieve certain outcomes while having a better view of "Tradeoffs" that you are going to make as part of the process

- As an Implementation Engineer it allows you to breakdown the device configuration into logical containers which are easier to manage, understand & configure beside without falling in the trap of - Order of operation issues

- As an Automation Engineer (NetDevOPS, NetOPS, NetSecDevOPS of whatever else you may call it) it allows you to break down the protocol in such a way that you can now easily write a Data Model to code it, write test units for each individual block and so forth beside develop a "YANG Model" or build a " CICD Pipeline "

- As an Operation Engineer or TAC Engineer it allows you to approach the whole process more logically if you follow the direction of "Arrow" as it allows you to understand "Dependencies" as part of layered approach

- As a Systems Architect it allows you think clearly about " Interaction Surfaces" & " Leaky Abstractions " beside understanding " Dependency Relation "

- Helps you form an " Abstraction Model " to hide complexity & inner-workings/details

- It allows you to plan " Streaming Telemetry " better as you can map your use cases and dependencies more easily and feed it into a magical " Intent Based Networking (IBN) " solution

- A consultant can use this for "Maturity Modelling" & " Assessment/Observability "

- A tool to apply " Critical Thinking " to routing protocols

In next part of this series we we bring this model from current 10,000 feet view to 1,000 feet view by start populating sub blocks under each major block.

Meanwhile as an exercise, try to think of any feature or knob of your favorite routing protocol as see if there is anything you can think of that wouldn't fit into any of those layers. :)

HTH...

A Network Artist 🎨

CCDE IGP Study Plan Part 1 - IS-IS

Finally I found some time recently to study and move on with CCDE plan. The idea is to take CCDE written in next 6 months at max. Since I have been doing on and off study for quite a while, I decided to gear up this time and work based on attack plan I had per technology duing my CCIE R&S couple of years back since the approach did well for me. The plan is more likely to work since to me CCDE is just a getting into mindset of a Network Designer but otherwise it's just a vast collection of exam topics that carefully needs to be examined and prepared for.

So to start with I picked up one of my fav routing protocol (IGP) which is yet not very well known - Integrated IS-IS or IS-IS for IP or IS-IS in general.

There are many personal reasons that I would pick it as protocol of choice if I have to pick for an ISP Network Design over more popular OSPF. But let's not get into IS-IS vs OSPF discussion yet.

Below is the study plan I used so far and I am quite happy about with progress.

1. Routing TCP/IP, Volume 1 (2nd Edition) - Jeff Doyle - Cisco Press
2. Optimal Routing Design  - Russ White - Cisco Press
3. IS-IS Network Design Solutions  - Abe Martey - Cisco Press > Two 
    Design Chapters
4. INE CCIE SP ATC IS-IS Section
5. SPF calculation in OSPF and IS-IS
6. ISIS Link-Group
7. Using BFD to Detect WAN Forwarding Errors
8. IS-IS+MPLS TE+Native IPv6=FAIL
9. Do not EVER run OSPF or IS-IS with your Internet customers
10. Missing routes when running IS-IS over Frame Relay
11. Cisco Live 365 - BRKRST-2335 - IS-IS Network Design and Deployment  
     (2012 San Diego)
12. Cisco Live 365 - BRKRST-2327 - ISIS Fundamentals and Troubleshooting
     (2013 Orlando)
13. Cisco Live 365 - BRKRST-2338 - ISIS Deployment in Modern Networks
     (2014 San Francisco) 
14. Packet Pushers - Show 89 – OSPF vs IS-IS Smackdown – Where You Can  
     Watch Their Eyes Reload
15. ISIS Authentication types
16. IS-IS Notes
17. IS-IS Study Guide Cisco IOS,IOS-XR 
18. IS-IS Routing Protocol FAQ

Under point '3' I chose Cisco Press IS-IS Network Design Solutions while there were some other good options too suggested by many CCIE and CCDE friends. But after carefully examining the contents through quick review I preferred Cisco Press book. But other books are no less either if you pick one of those like:

The Complete IS-IS Routing Protocol

OSPF and IS-IS: Choosing an IGP for Large-Scale Networks

IS-IS: Deployment in IP Networks

With that being said, hope to come up with IS-IS design articles and possibly a short IS-IS CCDE type case study in coming month.

HTH...
Deepak Arora
Evil CCIE

OSPFv3 Gets Family

It's been a while since I touched Cisco CLI during Non Office Hrs. There are lots of things keeping me busy enough these days like I have been doing a Proxy relocation to DC project which means tons of stuff to deal with as DC is a fairly complex structure with lots of moving pieces like Load Balancer ( SLB, GSLB, LLB), Firewalls and above that this particular DC runs all Juniper Devices for Routing , Switching & Security stuff.

On the flip side I am thinking to seriously start working on CCDE from Mid May 2015 onwards with first lab attempt probably in Feb or May 2016. Though initially CCIE Wireless was on Radar for this and coming year but as Cisco has just announced new blueprint , the idea went on to backseat for a while now. Voice could have been interesting also but similarly CCNA and CCNP Collab tracks are going to replace existing NA and NP Voice track soon and moreover I haven't been doing much around Voice at work as well so should consider it some time next year.

Now back on to idea of today's post about OSPF Address Family Structure. Well it's been a while since Network Industry was talking about one of advantage of IS-IS over OSPF which is IS-IS supports IPv6 natively. For IS-IS it was just a matter of adding new TLV (Type Length Value) to existing IS-IS packet ( TLV 232 & 236 ? I guess). Where as with OSPF it was a different story. They actually had to write a new routing protocol right from scratch now known as OSPFv3. Which introduced another problem from network design and management standpoint that if we just want to run OSPF as choice of routing protocol for both IPv4 & IPv6 on network as administrator, we got to run two separate routing protocol instances as OSPFv2 for IPv4 and OSPFv3 for IPv6. Which means two separate routing topologies.

Now with OSPFv3 Address family (AF) structure support we get rid of this problem of running two separate routing instances somewhat. Why "somewhat" and not "completely" ?

Well while this AF structure solves the multiple instances requirement problem, it has it's own limitations like:

> Specific IOS version like 15.x required, which may or may not be supported across all existing routers & switches serving as Distribution block

> The AFv4 requires IPv6 Link Local address on all IPv4 interfaces in order to function, otherwise it doesn't allow you to bind OSPFv3 AFv4 instance on interface. The Link local addresses are used as source address of packet over interfaces connecting OSPF enabled devices

> The device with capability of AFv4 still couldn't talk to traditional OSPFv2 Device since there is a Address Family bit carried inside new Hello packets which traditional OSPFv2 device don't understand

Which means the deployment is more likely to be successful only if it's a Green Field deployment.

Here is a quick lab with quick results :)

Further Readings:

http://www.ciscopress.com/articles/article.asp?p=2294214&seqNum=4

http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/open-shortest-path-first-ospf/whitepaper_c11-668030.html

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_ospf/configuration/xe-3s/iro-xe-3s-book/ip6-route-ospfv3-add-fam-xe.html#GUID-10C6CAB4-C220-47A5-9DEA-F57319BCFFDA

HTH...

Deepak Arora

Evil CCIE

OSPF Path Selection With Default Information Originate - How You Gonna Fix It ? - Part 2

As OSPF recent design issue discussed here can possibly turn into obnoxious CCIEv5 R&S troubleshooting scenario, I got one email from another friend who also ran into interesting OSPF design issue recently around OSPF default information originate too.

Here is a quick topology of his network design:

At high level the design looks pretty simple. R1 & R2 are peering with WAN cloud using E-BGP. Between R1-R2-R3-R4-R5 we are running OSPF Area 0. To ensure R3-R4-R5 have reachability to external prefixes (Since it's always good to avoid BGP to IGP Redistribution), R1 & R2 are injecting default route into the network using "default-information originate always metric-type 1" option.

Also R1 & R2 are connected to each other over a link running OSPF.

Now let's talk about problem...which is the fun part :)

If R1's WAN connection goes down, R4 can't reach any external prefixes using default route any longer. Whereas at the same time both R3 & R5 don't lose their connectivity to same external prefixes.

Now ideally once R1 find it's WAN interface down, it should get default route from R2 and should be able to route R4's traffic in that direction.

Let me show you same behaviour using CLI :

Before R1's WAN Link goes down

After R1's WAN Link goes down 

No ICMP Packets Received Any Longer on R6

R1 is not installing default route from R2

See if you can figure out " WHY " behind this and offer different ways we can fix this design issue. Feel Free to post you solution, recommendation and findings under comments section. I'll update the post around next weekend with my findings and solutions to the design.

HTH...

Deepak Arora

Evil CCIE



Update

 In SPF Debug

OSPF Path Selection With Default Information Originate - How You Gonna Fix It ? - Part 1

I recently got a call from friend , he was stuck with an interesting OSPF Path Selection issue. Obviously the things didn't work the way he expected it to be :)

Now initially he was been given a Consulting task that involved Design & Configuration changes to meet a new network requirement.

Here is how the network initially looked like :

The customer had active-active WAN connections where these connections were also serving both WAN as well as Internet connectivity. Where as in LAN side they were using OSPF as shown in Topology above.

Now the new requirements given were:

> Brought Up New Internet Connection that will act as Primary Path to reach internet.

> In case the New Internet connection goes down, the old WAN cloud should still work as backup path to reach internet

> From R4's perspective, the path towards R2 should be primary path to reach internet (Through New Internet GW) while path through R3 should be backup path. I am not sure why this was a Hard Requirement but I guess the path from R4 to R3 was through RF link as shown below:

> Introduction of Static Routes, PBR, NAT for whatever reasons were not allowed to be used to solve this problem 

Now my friend tried to solve this problem in an interesting way. He Introduced RIPv2 as new IGP between R5-R3-R2 to ensure he doesn't have to change anything into existing IGP since there was a large IGP domain connected to this setup.

Using RIPv2 he injected default route into RIB of R2 and R3. He had to change distance of RIPv2 originated default route so that it can get priority over BGP injected default route. Than he tried Injecting Default Routes into OSPF domain towards R4 using "Default Information Originate " option. Since the control over path selection was required here, During default route injection he used Metric Type as 1 with Higher metric given while injection route at R3 as shown below:

Obviously the solution didn't work as expected and here is why:

As you can on R4 we still have two routes instead of one in Routing Table.

Can you figure out what's the problem here and how we can fix it in easiest way ?

Or You Have any other better solution to fix it while meeting the given restrictions ?

I'll post my solution to the problem after 2 weeks.

To be on same page here is the Addressing I Used in while labbing this up:

Here is relevant configuration:

 

Good Luck  !!! :)

HTH...

Deepak Arora

Evil CCIE

Update For Ref: See comments section for further information.

HTH...

Deepak Arora

Evil CCIE

Does EIGRP Feasible Successor Always Work As Successor Fails ?

A recent discussion with friends brought this idea in my mind to write about this exiting subject. While I won't say all but many among them thought that it's always good to have EIGRP Feasible successors into Network while designing an EIGRP based network (Which of course is true ). And if EIGRP successor Route Ever fails, the EIGRP feasible successor will be installed quickly as it's a second best route in EIGRP Topology table based on feasibility condition, which will help minimizing convergence time.

And this is where most people start assuming that it's always going to be the case. Which of course is not true :)

Let's test this quickly based on following topology:

From R1's perspective it has three different paths to reach the destination - 5.5.5.5

Now let's review R1's routing table to first find which path is preferred.

As we can see, the middle path has been chosen as best path based on Dual Algorithm. Now let's next review R1's EIGRP topology table to figure out if we have feasible successor chosen at all and if So than which path.

 

 As we can see, the path through R4 has been chosen as second best path (Feasible Successor). Since there is no other entry in Topology table showing path through R2, which means it's neither successor nor feasible successor and has failed feasibility condition.

Let's verify Feasible Distance (FD) and Reported Distance (RD) for path through R2 by shutting down the path through R3 and R4.

Now here is an interesting scenario:

> Path through R3 is the best path (Lowest Metric)

> Path through R4 is meeting feasibility condition (making it feasible successor). But overall cost to destination is worst if we compare all three paths metric.

> Path through R2 is actually second best path based on total metric but got out of the equation as it failed feasibility condition

Though we can see that topology doesn't include any potential link which can lead traffic back to original source while forwarding traffic towards destination 5.5.5.5 , but EIGRP fails to recognize this fact. 

This is where we find this true that eventually EIGRP is an Advance Distance Vector protocol as it tries to avoid any possible looping with help of Dual Algorithm but is not always successful to find it's goal. But not as good as a Link State Routing protocol which would have the complete picture of the topology.

Now in this scenario what you think would happen if Successor Route fails ?

If we go by theory discussed earlier in the post, EIGRP feasible successor should take over. Right ?

But that would mean sub-optimal routing. 

But don't worry. EIGRP is intelligent enough still and it finds Optimal Path here based on overall cost to destination and avoiding sub-optimal path.

 
 To my surprise during this test two commands didn't work the way I expected. Which I must figure out sometime :)

Further Readings:

http://www.ciscopress.com/articles/article.asp?p=1763921&seqNum=5

http://books.google.co.in/books?id=XkM6vxsVJEsC&pg=PA78&lpg=PA78&dq=eigrp+convergence+with+feasible+successor&source=bl&ots=mvVF2sg2_K&sig=1jz3SMiK6TiRNnSdj1LKTIj8AHk&hl=en&sa=X&ei=EIxWVMriI8ekuQS-gIL4AQ&ved=0CD8Q6AEwBQ#v=onepage&q=eigrp%20convergence%20with%20feasible%20successor&f=false

http://www.cisco.com/c/en/us/support/docs/ip/enhanced-interior-gateway-routing-protocol-eigrp/16406-eigrp-toc.html#feasibleandreported

http://packetlife.net/blog/2010/aug/9/eigrp-feasible-successor-routes/

http://rovingengineer.wordpress.com/2010/07/28/eigrp-feasible-successor-routes/


HTH...
Deepak Arora
Evil CCIE

OSPF Route Preference: You Sure You Know It ? ... RFC 3101...Part 2 (Final)

It's sunday, got some time today. Let's wrap up this series quickly.

The physical and logical topology is gonna remain same. The only thing I changed in this part is ... IOS Version :)

 

R3 is Still the Translator:
 

Let's review the routing table of R2 quickly again and see how things are:

So now the question is why results are different with different IOS ? ( IOS used in part 1 was 12.4 (20) T ).

The previous version was actually following RFC 1587 in which the route preference is same as mentioned in post 1 i.e. E2 is preferred over N2.

But the later IOS followed the RFC3101 implementation. Which states that LSA with P-bit set is preferred over the one which has P bit as Zero. The P bit is set to 1 by ASBR while redistributing the routes into NSSA except the situation where ASBR is also ABR and P bit remains unset (0).

But as an Engineer if you would like you can still go back to older IOS behavior as following:

The reason in Part 1 , the traffic (Data Plane) took the direct path because of same cost to Forwarding Address.

Further Readings:

http://blog.ipspace.net/2008/01/e1-and-e2-routes-in-ospf.html

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_ospf/configuration/15-e/iro-15-e-book/iro-ospfv2-nssa-cfg.html#GUID-C335FD95-ED21-4A51-894F-8B63119186EC

http://networklessons.com/ospf/ospf-path-selection-explained/#ixzz3GPsDJ8N8

HTH...
Deepak Arora
Evil CCIE