[c-nsp] RIP offset lists

[Joe Maimon]

Rodney Dunn wrote:

> <snip>
>
>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.
>  
>
That sounds nice.

><snip>
>DE-pend-workaround-provided.
>  
>
I think that is what I will request from hereon.

>
> <snip>
>
>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
>
>
>  
>
Even though in my case I had not gotten a usable workaround, that sure 
does sound nice as opposed to the ever more frequently "ok I filed the 
bug. Can I close the case now? If not, what else is it that you want me 
to do?"

In this case I have been monitoring it in CCO, for all the good it does me.

>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. 
>
That would be me, especialy in this case, as its a fairly trivial test.

><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?
If the packets gets process switched for any reason would it take more 
overhead than had it not been gre and process switched?

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

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

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

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