[c-nsp] RIP offset lists

[Rodney Dunn]

> ><snip>
> >  
> >
> >The overhead to switch a GRE packet in the CEF path is very small
> >compared to normal packet switching. 
> >
> Thats reassuring. But how about if there are features such as nat, cbac 
> or qos on the tunnel. Would the overhead still be as small?

Those features are more intense because more has to be done on a
per packet basis.  There are performance enhancements that move
the NAT translation creation in the CEF path for 12.3(4)T and
later which really helped.

CBAC I don't know much about.

QOS is in the CEF path and that all depends on the policy and
depth of the class-maps and set options you have.  I think there
is work being done to test/quantify QOS on a per-user basis in
a BBA scenario but I don't have any information on that...sorry.


> If the packets gets process switched for any reason would it take more 
> overhead than had it not been gre and process switched?

You never want packets process switched that are transit the box.
It will be more work becuase there are things in the process path
that are not in the interrupt switching path.

> ><snip>
> >
> >In my eperience not very.  Most ISP's I've seen, non MPLS-VPN,
> >either do statics to leased line customers or BGP.
> >  
> >
> Which is probably a strong contributing factor as to why SAA got all 
> that upgraded functionality. Used to be the only way you could reliably 
> determine if one of your upstreams was down was by using rip.

Absolutely why that was done.  It's exploded to solve a lot
of corner case issues we never thought of so that's been nice.

> 
> > <snip>
> >

> Might as well remove the last few words "for VA interfaces".
> 
> This is a nice summary on some handy functionality that I had been 
> working around by ensuring the remote end sets the metric, which is not 
> always possible and sometime undesirable.
> 
> >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
> >
> >  
> >
> Either would work but I think the latter fits how per user AAA 
> attributes are done better.
> For that matter, why not have it as an interface command always?


Let me ask because I can see how this is a valid request
although it's not one we hardly ever see so it will have
to be prioritized accordingly unfortunately.

> 
> >
> >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.
> >  
> >
> Lets say we give the customer a 7Mb/768 Adsl line and a full T1.
> 
> Or we give the customer the above to two sites that are linked by a 
> private p-to-p T1, which sometimes experiences lossage.
> 
> Or the ADSL is only 768/384 and clearly only wanted as a backup route 
> when the t1 router hangs.
> 
> Or you have more than two pppoe links to the same site.
> 
> Or the above and the remote ends is comprised of two linksys routers.
> 
> You would have to control the assymetricity by sending 0/0 with extra 
> offset down one and accepting customer route with higher offset from the 
> other.
> 
> Often in instances where a link quality degrades, you want to not tear 
> it out of the routing equation, just make it less preferred

I can see how having the ability to do this gives the user more
flexibility for a solution.

It's usually been that most ISP's I've seen don't like running
a dynamic protocol to a CPE other than BGP outside of a
VRF/VPN context.

Can you please open a TAC case where you request the ability
of (b) above and send me the case number?
I wan't it documented where a customer asked for this.
 
We'll take that request offline....


> 
> Since IOS does support rip offset lists on Dialer interfaces, if it 
> worked that is how you would handle most of the above..
> 
> >Rodney
> >
> >  
> >
> Joe