Showing posts with label CCNP Troubleshoot Exam. Show all posts
Showing posts with label CCNP Troubleshoot Exam. Show all posts

Wednesday, December 31, 2014

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


Saturday, November 15, 2014

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


Monday, November 3, 2014

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

Sunday, March 10, 2013

EIGRP Practice Lab - For CCNP/CCIP/CCDP ROUTE Candidates (With Video Solutions)

PHYSICAL TOPOLOBY

LOGICAL TOPOLOBY 
Lab Task List


IOS Details

GNS Project File


Initial Configurations:
###################

R1
===

!
en
!
conf t
!
no cdp run
!
ho R1
!
no ip do lo
!
int lo0
 ip add 1.1.1.1 255.255.255.255
 exit
!
int s0/0
 encap frame
 ip add 123.0.0.1 255.255.255.0
 no frame inv
 frame map ip 123.0.0.2 102 b
 frame map ip 123.0.0.3 103 b
 frame map ip 123.0.0.1 102
 no sh
 exit
!
line con 0
 logging syn
 no exec-time
!
end
!

##########################################


R2
==

!
en
!
conf t
!
no cdp run
!
ho R2
!
no ip do lo
!
int lo0
 ip add 2.2.2.2 255.255.255.255
 exit
!
int s0/0
 encap frame
 ip add 123.0.0.2 255.255.255.0
 no frame inv
 frame map ip 123.0.0.1 201 b
 frame map ip 123.0.0.3 201
 frame map ip 123.0.0.2 201
 no sh
 exit
!
int s0/1
 encap frame
 ip add 205.0.0.2 255.255.255.0
 no frame inv
 frame map ip 205.0.0.5 205 b
 frame map ip 205.0.0.2 205
 no sh
 exit
!
int f0/0
 ip add 150.0.0.2 255.255.255.0
 no sh
 exit
!
int f0/1
 ip add 26.0.0.2 255.255.255.0
 no sh
 exit
!
int f1/0
 ip add 25.0.0.2 255.255.255.0
 no sh
 exit
!
line con 0
 logging syn
 no exec-time
!
end
!



##########################################


R3
===


!
en
!
conf t
!
no cdp run
!
ho R3
!
no ip do lo
!
int lo0
 ip add 3.3.3.3 255.255.255.255
 exit
!
int s0/0
 ip add 123.0.0.3 255.255.255.0
 encap frame
 no frame inv
 frame map ip 123.0.0.1 301 b
 frame map ip 123.0.0.2 301
 frame map ip 123.0.0.3 301
 no sh
 exit
!
line con 0
 logging syn
 no exec-time
!
end
!


##########################################

R4
===

!
en
!
conf t
!
no cdp run
!
ho R4
!
no ip do lo
!
int lo0
 ip add 4.4.4.4 255.255.255.255
 exit
!
int f0/0
 ip add 150.0.0.4 255.255.255.0
 no sh
 exit
!
int f0/1
 ip add 46.0.0.4 255.255.255.0
 no sh
 exit
!
int f1/0
 ip add 45.0.0.4 255.255.255.0
 no sh
 exit
!
line con 0
 logging syn
 no exec-time
!
end
!


##########################################


R5
===

!
en
!
conf t
!
no cdp run
!
ho R5
!
no ip do lo
!
int lo0
 ip add 5.5.5.5 255.255.255.255
 exit
!
int f0/0
 ip add 150.0.0.5 255.255.255.0
 no sh
 exit
!
int f0/1
 ip add 25.0.0.5 255.255.255.0
 no sh
 exit
!
int f1/0
 ip add 45.0.0.5 255.255.255.0
 no sh
 exit
!
line con 0
 logging syn
 no exec-time
!
end
!

##########################################


R6
===


!
en
!
conf t
!
no cdp run
!
ho R6
!
no ip do lo
!
int lo0
 ip add 6.6.6.6 255.255.255.255
 exit
!
int f0/0
 ip add 150.0.0.6 255.255.255.0
 no sh
 exit
!
int f0/1
 ip add 46.0.0.6 255.255.255.0
 no sh
 exit
!
int f1/0
 ip add 26.0.0.6 255.255.255.0
 no sh
 exit
!
line con 0
 logging syn
 no exec-time
!
end
!


Solution Videos

 TASK 1& 2 Solution




TASK 3 Solution




TASK 4 Solution



TASK 5 Solution



TASK 6 Solution



TASK 7 Solution


TASK 8 Solution


TASK 9 Solution


TASK 10 Solution



TASK 11 Solution



TASK 12 Solution


TASK 13 Solution


TASK 14 Solution


TASK 15 Solution



HTH...
Deepak Arora

Evil CCIE

Monday, December 24, 2012

HSRP Preemption On Standby Router - Required Or Not ?

Often I ask this question to CCNPs during interviews - "Do we require PREEMPT command on HSRP Standby router or not ? "

And often candidates either reply "NO" or looks Struggling.

Although Short answer is "YES". But here is the detailed explanation using a test bed.

For those which are new to HSRP. I would recommend first read following posts from Gr8 CCNP Intructor Chris Bryant, CCIE#12933


http://www.thebryantadvantage.com/CCNPCertificationBCMSNExamHSRPInterfaceTracking.htm

http://www.thebryantadvantage.com/CCNPCertificationExamBCMSNHSRPPriorityActive.htm

http://www.thebryantadvantage.com/CCNPCertificationBCMSNExamHSRPMACAddress.htm


Now lets get started with topology details later followed by Detailed Explanation using Test Bed:




















Further Readings:




 
HTH...
Deepak Arora
EVIL CCIE