[c-nsp] RIP offset lists

[Rodney Dunn]

On Thu, Jan 20, 2005 at 07:05:20AM -0500, Joe Maimon wrote:
> 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.

A couple comments from my side...

> 
> My questions to all of you are:
> 
> 1)
> Do you close TAC cases once a DDTS has been filed?

That is something that you have the ability to decide
becuase you are the case owner.  The reason we don't have
a hard line on that topic is becuase a lot of customers 
want the case closed especially if a workaround is in place.
They put the bug on their watch list and upgrade when the
fix comes.  There are things in the works to make it easier
for the customer to monitor say a specific train and be
notified when that bug is integrated there.

We have other customers that say please keep the case open
until a fix is delivered in a CCO released version of code
/*plug: that is the way I like customers to handle it
        because that makes the case an accurate representation
        of how we do solving a customers problem fully*/

As you know there are different states a case can be in
and one of them is DE-pending and that's when all the work
has been done on the case and it's waiting on DE to fix the
bug which is what your case should be in.
DE-pend-workaround-provided.

 Or do you keep them 
> open until the issue becomes a distant memory to you, in order to keep 
> the pressure on?

I personally don't like thinking about it from "keep the pressure on".
Although I realize sometimes a little pressure is needed hopefully
if the TAC engineer understands the importance they can do that
on your behalf as part of service to the customer.  You should
not be required to do that.  
 

> 
> 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.

Just ask for the case to be put in a DE-end-workaround-provided
state until you have a CCO image that fixes your bug. Until then
the case is not resolved if that's what *you* as the customer
determines to be closure for the case /*which is the way I would
view it as a customer*/.  However, we also have to handle the
customer that wants the case closed because just like you said
they have a workaround and don't want to worry about it anymore.
Some want it that way for some reason.

I think the answer from the TAC engineer should be:

Mr. Customer,

Thanks for working with us to find this bug.  Fortunately
we have found a workaround that appears to be acceptable
to you in the short term while we fix our bug.
In the meantime, would you prefer to leave the case open
and in a DE-pending status or would you rather I close
it and you can monitor the state of the bug through the
BugToolkit on CCO?

Thanks,
TAC Engineer


We even have customers that sometimes are willing to verify
the fix for us depending on what their network setup and
IOS code change procedures are.  Some can't due to policy.
Some want to because they want to know if it's a problem
they can reproduce also that it's the same problem and
when the fix is delivered on CCO it will fix the problem
they see.  It's a customer decision.

> 
> 
> 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.

It's actually still pretty common and used between PE-CE links of
some MPLS/VPN providers.  Mostly I think because it seems to be
the most simple to operate /*from a configuration point of view*/.

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

Depends exactly what you are doing.

> 
> 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.

The overhead to switch a GRE packet in the CEF path is very small
compared to normal packet switching.  If you are talking about the
additional GRE header size taking up bandwidth on the links which
comes more significant when running small packets then yes that
can be an issue.  GREoIPSEC is very common through the internet
today for VPN topologies.

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

In my eperience not very.  Most ISP's I've seen, non MPLS-VPN,
either do statics to leased line customers or BGP.

RIP is driven more as a requirement for some customers in the
MPLS VPN context because that may be what the customer request.

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

Others can comment here.  It's functionality that's built in
IOS and it should work..always.

> 
> 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 ?

I can't think of a way to do this and I've never seen a customer
request.  If you can make sure I understand what you are asking
for I'll run it by the coders and see if it's functionality we
could add.

What you want is the ability to specify on a per interface
basis the offset that gets added to a RIP route for VA interfaces.

There are two approaches I see:

a) make it where the offset-list command under router rip will
   accept a VA interface and then if possible have a per-user
   AAA command get loaded for each user to add the command
   under router rip

b) make it where under the VA interface you could apply the
   offset list command there and have it loaded from AAA on
   a per user basis



What is your deployment scenario that you are running RIP
to customers?  Usually I see it done as per user static
routes because the provider doesn't want to add the
complexity of a dynamic routing protocol to the user
for various reasons.

Rodney


> 
> 
> Thanks in advance,
> 
> Joe
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/