[c-nsp] RIP offset lists

Joe Maimon jmaimon at ttec.com
Thu Jan 20 07:05:20 EST 2005


Hello All,

Since shortly after 12.3(5), offset-lists for RIP on the out direction 
have been broken for me. Cisco DDTS CSCef47023. Filed five months ago.

My TAC engineer wanted me to close the case after that. He had been very 
helpfull, trying to find me a workaround (setting a metric on 
redistribute connected routes with a route-map, but I need this per 
interface), getting the ddts filed and ensuring I had access to it, so I 
did.

I recently emailed him asking him to check what was happening and to 
send me some interim builds, due to the lengthy delay. Its only been a 
day, so I am still waiting.

My questions to all of you are:

1)
Do you close TAC cases once a DDTS has been filed? Or do you keep them 
open until the issue becomes a distant memory to you, in order to keep 
the pressure on?

Seems like sometimes the engineer end goal is orientated heavily towards 
keeping the tally of open cases as low as possible, even ones that may 
be release pending.


2)
Since RIP2 is the lowest common denominator working routing protocol 
(the only one in the $40 linksys class of CPE) how many still run it?
With adjustments of timers and prefix-lists and not using it for a full 
mesh and along with another IGP, it should still be quite usable in very 
many organizations.

Or do you prefer to build GRE tunnels over this class of equipment?

We have seen GRE tunnels drop far more packets under stress than their 
physical links, which is to be expected, and that tax our routers CPU, 
so we tend to try to avoid that where possible.

2a)

How common is it for an ISP to rip a 0/0 out and accept the customer 
prefix in?

3)
Those who run RIP2, how important is it to manipulate metrics on 
advertised routes?

As a workaround, we often can change the manipulation to incoming on the 
other routers. This has several disadvantages

A: On broadcast media where there may be several routers whose incoming 
metrics need to be manipulated
B: The above except you only want to manipulate the metric for a subset 
of the routers on the broadcast domain
C: Certain interfaces are impossible (afaik) to specify, such as 
virtual-access interfaces for l2tp and pppoe connections without 
applying it to the virtual-template which is not very granular.

4)

Can anyone think of a way to workaround these problems, especialy the 
above C ?


Thanks in advance,

Joe


More information about the cisco-nsp mailing list