Well I would say your answer is more accurate but the answer in the book is
still OK.

 

As Cisco will hold the route in the table until it confirms the other route
is stable and more preferred what you are seeing is the expected behavior.
You are not getting another route to replace it or it would remove it on the
second update and only hold the old one in the RIP database until it
expires.

 

Regards,

 

Tyson Scott - CCIE #13513 R&S, Security, and SP

Managing Partner / Sr. Instructor - IPexpert, Inc.

Mailto:  <mailto:[email protected]> [email protected]

Telephone: +1.810.326.1444, ext. 208

Live Assistance, Please visit:  <http://www.ipexpert.com/chat>
www.ipexpert.com/chat

eFax: +1.810.454.0130

 

IPexpert is a premier provider of Self-Study Workbooks, Video on Demand,
Audio Tools, Online Hardware Rental and Classroom Training for the Cisco
CCIE (R&S, Voice, Security & Service Provider) certification(s) with
training locations throughout the United States, Europe, South Asia and
Australia. Be sure to visit our online communities at
<http://www.ipexpert.com/communities> www.ipexpert.com/communities and our
public website at  <http://www.ipexpert.com/> www.ipexpert.com

 

From: [email protected]
[mailto:[email protected]] On Behalf Of Bojan Zivancevic
Sent: Monday, September 20, 2010 12:34 PM
To: 'CCIE_RS OnlineStudyList'
Subject: [OSL | CCIE_RS] vol.1 task 8.13 problem (route poisoning)

 

First, I think there is an error in DSG. Second, I stumbled into an
interesting behavior of the "distance" command.

 

This is a task about RIP route poisoning. We can go for offset-list method
or distance one. The WB goes for distance, ok.

 

DSG says that we should enter "distance 255 150.100.12.2 255.255.255.255 1"
which IMHO is wrong. The context help and command reference agree that we
should enter wilcard there, and not the subnet mask. So, it should be
"150.100.12.2 0.0.0.0". 

 

That can be confirmed with "sh run | i distance" which then show that the
router automatically converted the distance command into "distance 255
0.0.0.0 255.255.255.255 1" because of the "ANY" wildcard used.

 

So, I think it is definite that we should use wildcard. Anyway, I tried it
this way and it worked. But...

 

Now, about the second part of my email. I would really love somebody to
explain why is this happening.

 

When I corrected the "distance" command, I noticed that the update timer has
not been reset anymore. The route just slowly started to dissapear. That
confused me and I thought all this is not working. That is why I changed the
distance to "254" in order to be able to see the route in the table even
after the command. All other routes behaved normal, just this one. So, i
chose to wait and saw that the distance command did have the effect, but
only after the flush timer has expired, the route got deleted from the
table, and another RIP update came after that. Only then the AD got changed
to 254... Why the router is not changing the distance immediately after the
next RIP update? Why the flush timer and all?

 

See for yourself:

 

R1(config-router)#do sho access-l 1

Standard IP access list 1

    10 permit 200.0.0.9 (75 matches)

R1(config-router)#do sh run | i dista

 distance 254 150.100.12.2 0.0.0.0 1

 

.... and we still have the old "120" distance...

R1(config-router)#do sro 200.0.0.9

Routing entry for 200.0.0.9/32

  Known via "rip", distance 120, metric 3

  Redistributing via rip

  Last update from 150.100.12.2 on FastEthernet0/0, 00:00:28 ago

..... time is passing...

R1(config-router)#do sro 200.0.0.9

Routing entry for 200.0.0.9/32

  Known via "rip", distance 120, metric 3

  Redistributing via rip

  Last update from 150.100.12.2 on FastEthernet0/0, 00:02:54 ago

... some more...

R1(config-router)#do sro 200.0.0.9

Routing entry for 200.0.0.9/32

  Known via "rip", distance 120, metric 4294967295 (inaccessible)

  Redistributing via rip

  Last update from 150.100.12.2 on FastEthernet0/0, 00:04:01 ago

.... and here it is, the new AD...

R1(config-router)#do sro 200.0.0.9

Routing entry for 200.0.0.9/32

  Known via "rip", distance 254, metric 3

  Redistributing via rip

  Last update from 150.100.12.2 on FastEthernet0/0, 00:00:20 ago

 

 

Best Regards,

 

Bojan Zivancevic

Network Engineer

_______________________________________________
For more information regarding industry leading CCIE Lab training, please visit 
www.ipexpert.com

Reply via email to