OSPF Troubleshooting Lab - It's All About LSA Magic

Yesterday I got this OSPF Troubleshooting Challenge sent by one CCIE candidate friend on email. So I thought to share it with you guys.


With that being said , here is the topology {Which I redraw to look better of course :-) } & quick requirements.

Note: Click Images To Enlarge

Requirements :
---------------------


On R3 we have redistribute the Loopback interfaces into OSPF process using "redistribute connected subnets" command. Over R2 we have configured "Summary x.x.x.x x.x.x.x" command under OSPF process to summarize these loopbacks of R3. But R1 is still seeing the all more specific routes for R3's loopbacks. In short it's not getting the summary route from R2. 


So how we gonna fix it ?


Ummm.... Interesting ? .... May Be :-)


Lets hop on to all three routers and check the basic configuration already done for us.

So based on this we can see that it's just a normal misconfiguration. Because to summarize the External Routes we need to put this command on R3 since it's the one who is ASBR. Or in short - Only ASBR can summarize the external prefixes not ABR. It looks simple and meaningful though but I have seen many people with this misconception that since as most of books we read says in OSPF the summarization can only be done at Boundary Routers so they assume that external routes can also be summarized by ABR. Which we can see here is that not the case. Or may be they should have mentioned this behavior explicitly :-)

So by that same token if we configure "Summary x.x.x.x x.x.x.x" command on R3 instead of R2 in that case it will work just fine.

But that will be two simple... how about if we are not allowed to put this command on R3 ?

Ummm.... that will actually make life more complicated. Lets check the database on R2 and see how it looks like with command "sh ip ospf database"

 So R2 sees those prefixes as LSA Type - 5 and we are Adv router (Originator) is 33.33.33.33 which is Router ID (RID) of R3 which I setup manually.

Ummm.... so only LSA 5 Originator can summarize the prefixes by using "Summary" command. 

Is there any way we can take charge of these prefixes and convert them to LSA Type 5 with Originator set being Ourself ?

How about NSSA ? :-) 

Because if convert Area 1 into NSSA in that case we will see those external prefixes being advertised by R3 as Type 7 LSA. Since R2 is the ABR it will convert LSA 7 into LSA 5 before advertising into Area 0. So in that sense we are now originator of LSA - 5 and very well can use summary command.

Lets see this on command line by configuring AREA 1 as NSSA on R2 & R3:

Now lets take a look at database on R2 again:

Lets see if this worked for us just fine by taking a look at R1's Routing Table.

So far so good. :-) Time for Celebration

But what if we are not even allowed to make Area 1 as NSSA ? ..... horrible ?


See if you can make it work with this restriction before I present the solution which came from a great Network Engineer and friend Michael Miller.


Take it as challenge and see if you can make this work with this last restriction by not configuring Area 1 as NSSA. 


I'll post the solution though some time next week.


And Of course.... Merry Christmas Everyone

HTH...

Deepak Arora

CCIE - 0::0/0 Null0

IPv6 Routing For Dummies (Coming Soon)

My First Grammy Award

Finally on Dec 21st INE put my name on it's blog with a little thanks note and a lovely gift. Though CCIE is not finished yet but it's nice to see that a major CCIE vendor and elite team of experts recognized your name.


Feels like I got my first Grammy Award.  

But CCIE number is yet to come. So need to put lots of hard work in coming months.


But another thing I forgot to mention above is that it was second time when I found my name on INE blog. :-)

Check here for rest of the story :


http://blog.ine.com/2010/03/04/tshoot-sample-exam-questions/


http://blog.ine.com/2010/12/21/ine-online-community-deepak-arora/ 

HTH...

Deepak Arora

CCIE - 0::0/0 Null0

Few Words On CCIE From The Guy Who Can Make You Fall In Love With Cisco

Operational differences between HSRP, VRRP & GLBP - Cliff Notes

HTH...

Deepak Arora

CCIE - 0::0/0 Null0

CCIE Voice Preparation - This is how life becomes once you go for CCIE :-)

Routing-Bits Handbook for R&S AKA CCIE R&S Short Notes - From Dual CCIE Ruhann

Just yesterday morning I got my official copy of Routing-Bits Handbook on my email and good part was that it was free of any charge :-) since I buy very first version of this couple of months back.

Not to mention that if you are working on CCIE R&S like me then you should definitely check this out . 


Also Ruhann is going to release his SP Handbook in coming month too. Which I am definitely gonna buy :-)  as my ultimate goal is to learn SP technologies at Expert Level.

HTH...

Deepak Arora

CCIE - 0::0/0 Null0

BGP synchronization - How well do you understand it ? (Short Post)

As per BGP Synchronization rule "If your autonomous system is passing traffic from another AS to a third AS, BGP should not advertise a route before all routers in your AS have learned about the route via IGP."

So BGP will wait until the IGP has propagated the route within the AS and then it will advertise that route to external peers.

If you will not be passing traffic from a different autonomous system through your AS, or if all routers in your AS will be running BGP, you can disable synchronization. Disabling this feature can allow you to carry fewer routes in your IGP and allow BGP to converge more quickly.

The IGP routing table MUST be synchronized with iBGP routing table.

Ummm... So this is what most people know and think. 

But does that mean if I am having a transit AS and Synchronization is not "OFF" and I am not running any IGP such as RIP, EIGRP, OSPF or IS-IS; in such case I can't pass the transit traffic?

Or Can I ? :-)

Lets take a look at topology and setup basic bgp peerings. Later we come back to this point.

So until now we are not running any IGP and tried to fix next hop issues with "next hop self" command. 

I would like to mention here that our only concern is traffic from R4 to R5 and vice versa.

Now since we are not running IGP lets try to put static routes for R4 and R5's loopback on R2 and see if it helps somehow. Though I have added static routes for R1/R3's loopback but it was not under our objective.

Now lets verify if static routes helped us overcome rule of synchronization and allowed R2 to advertise R4's(BB1) Loopback to R3 and R5's (BB2) Loopback address to R1.

So we can see that routes are getting advertised now.  Now lets hop on to R1/R3 and fix this issue in same way along with fixing next hop issues with static routes. 

So what we understand now is that in BGP Synchronization rule the term IGP doesn't necessarily means IGP routing in itself like RIP, OSPF, EIGRP or IS-IS but IGP reachability. Or more precisely we can say it talks about control plane reachability.

HTH...

Deepak Arora

CCIE - 0::0/0 Null0

Scott Marvin Keith Halloween

http://www.youtube.com/user/Keith6783#p/u/6/Urxvt0nCNLw

BGP synchronization - How well you understand it? (Coming Soon...)

BGP touches 350,000 route entries

http://bgp.potaroo.net/bgprpts/rva-index.html

HTH...
Deepak Arora
CCIE - 0::0/0 Null0

Ancient BGP Network Language

Yesterday while running some BGP debugs on my Cisco Gear I saw console messages which I simply couldn't understand. Can you ?

<- Console Message

Looks like Cisco has introduced some Ancient BGP language into IOS :-)

HTH...

Deepak Arora

CCIE - 0::0/0 Null0

 

BGP Client-Server Communication - How Does It Work ?

I am sure these days most of CCNP or CCNP+ people knows that BGP is technically an APPLICATION not a routing protocol which runs on top of TCP. As an application it can carry many sorts of information inside with IPv4 prefixes being one among them.


Also in past we discussed here about another important fact that BGP is a CLIENT-SERVER designed based application. Now important question comes in mind is - How do we determine which side is SERVER and which side is CLIENT.


Lets try to figure it out and see how things work:


Here is the quick topology we are going to use:

So lets do the basic configuration before we dig deeper. In first case we will establish EBGP Peering Between R1 & R2 over Serial0/0 interface on both sides.


===========================================


^^^ R1 ^^^
#########



R1(config)#int lo0
R1(config-if)#ip add 11.11.11.11 255.255.255.255
R1(config-if)#exit
R1(config)#int s0/0
R1(config-if)#ip add 12.12.12.1 255.255.255.0
R1(config-if)#no sh
R1(config-if)#exit
R1(config)#int s0/1
R1(config-if)#ip add 112.112.112.1 255.255.255.0
R1(config-if)#no sh
R1(config-if)#exit
R1(config)#router bgp 1
R1(config-router)#no au
R1(config-router)#no sync
R1(config-router)#nei 12.12.12.2 remote-as 2
R1(config-router)#net 11.11.11.11 mask 255.255.255.255
R1(config-router)#exit



^^^ R2 ^^^

#########

R2(config)#int lo0

R2(config-if)#ip add 22.22.22.22 255.255.255.255

R2(config-if)#exit

R2(config)#int s0/0

R2(config-if)#ip add 12.12.12.2 255.255.255.0

R2(config-if)#no sh

R2(config-if)#exit

R2(config)#int s0/1

R2(config-if)#ip add 112.112.112.2 255.255.255.0

R2(config-if)#no sh

R2(config-if)#exit

R2(config)#router bgp 2

R2(config-router)#no au

R2(config-router)#no sync

R2(config-router)#nei 12.12.12.1 remote-as 1

R2(config-router)#net 22.22.22.22 mask 255.255.255.255

R2(config-router)#exit

===========================================

$$$ <- Verification -> $$$

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

R1#sh ip bgp summ | b N 
Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
12.12.12.2      4     2       8       8        3    0    0 00:01:08                                1


R2#sh ip bgp summary | b N
Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
12.12.12.1      4     1       5       5        3    0    0 00:01:30                                 1


R1#ping 22.22.22.22 so lo0


Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 22.22.22.22, timeout is 2 seconds:
Packet sent with a source address of 11.11.11.11 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/11/20 ms

So far everything looks good. Our peering is up and we are able to exchange prefixes just fine.

===========================================

Now next step is to verify which side is server and which side is client and does being SERVER vs being CLIENT affects something.

From the RFC point of view, the side with higher RID will be "CLIENT" and router with lower RID (Router ID) will be chosen as "SERVER". It's going to be the CLIENT which will initiate connection towards SERVER from some random source port towards destination TCP port 179.

This is a very important piece of information in case there is any device in middle of two BGP speakers blocking traffic like firewall, proxy etc. In such case you know now in which direction you need to open which ports.

But as far real world is concerned :-)

things might behave little different. Actually the fact I explained above only comes into play when both BGP speaker start talking to each other at same time in first place. If one BGP speaker is already up and you bring another BGP speaker up in later, in such case things may be seen as opposite.

So It's important to figure out which side is SERVER & which one is CLIENT.

Ummm.... Actually it's simple. There are many IOS command to figure it out but one being my favorite one is " show tcp brief ". What are the other ones ? .... hehehe :-) go figure

R1#sh tcp brief   

TCB                Local Address                  Foreign Address              (state)

64AF469C      12.12.12.1.51473               12.12.12.2.179              ESTAB

R2#sh tcp brief

TCB                Local Address           Foreign Address        (state)

64AF406C      12.12.12.2.179          12.12.12.1.51473       ESTAB

So looking at the output for R1 you can see that R1 is initiating a TCP session with source IP as 12.12.12.1 with source port as 51473 with destination IP as 12.12.12.2 with destination port as 179.

This very much tells us that R1 is the CLIENT here and R2 is the SERVER. It also support the other fact I mentioned above that it's not always necessary that the device with higher RID will be client and initiator of the connection.

R1#sh ip bgp | i ID

BGP table version is 3, local router ID is 11.11.11.11

R2#sh ip bgp | i ID

BGP table version is 7, local router ID is 22.22.22.22

Also one more important piece of information I would like to mention here is that in BGP it's only the SERVER side which need to receive BGP connection from the valid source matching it's local NEIGHBOR statement. For CLIENT side it is not necessary.

Lets try to verify if this is true:

R1config)#no router bgp 1 

R1(config)#router bgp 1 

R1(config-router)#no au

R1(config-router)#no sync

R1(config-router)#nei 112.112.112.2 remote 2

R1(config-router)#nei 112.112.112.2 update s0/0

R1(config-router)#net 11.11.11.11 mask 255.255.255.255

R1(config-router)#exit

R2(config)#no router bgp 2

R2(config)#router bgp 2

R2(config-router)#nei 12.12.12.1 remote 1

R2(config-router)#no au

R2(config-router)#no sync

R2(config-router)#net 22.22.22.22 mask 255.255.255.255

R2(config-router)#exit

So though local neighbor statement has been changed, but R2 (Server) still sees the BGP communication coming out from valid source IP of 12.12.12.2 which is same as mentioned in it's local BGP communication. But that's not the case for R1 which has neighbor statement for 

112.112.112.112 though the BGP connection it sees is coming from 12.12.12.1 with update source address not modified over R2 for it.

*Mar  1 02:07:14.203: %BGP-5-ADJCHANGE: neighbor 12.12.12.1 Up 

R1#sh tcp brief

TCB                 Local Address           Foreign Address        (state)

64B379E4      12.12.12.1.58558        112.112.112.2.179      ESTAB

R1#sh ip bgp summ | b N

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd

112.112.112.2   4     2       6       6        3    0    0 00:02:23                              1

R1#sh ip bgp | b N

   Network          Next Hop            Metric LocPrf Weight   Path

*> 11.11.11.11/32   0.0.0.0                  0              32768     i

*> 22.22.22.22/32   112.112.112.2            0             0      2 i

R1#ping 22.22.22.22 so lo0

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 22.22.22.22, timeout is 2 seconds:

Packet sent with a source address of 11.11.11.11 

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 4/8/16 ms

HTH...
Deepak Arora
CCIE - 0::0/0 Null0