[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