10 messages in net.nether.puck.cisco-nsp[c-nsp] RIP offset lists
FromSent OnAttachments
Joe MaimonJan 20, 2005 7:05 am 
Rodney DunnJan 20, 2005 9:21 am 
David BarakJan 20, 2005 10:22 am 
Joe MaimonJan 20, 2005 10:58 am 
Joe MaimonJan 20, 2005 11:01 am 
Rodney DunnJan 20, 2005 11:26 am 
David BarakJan 20, 2005 11:46 am 
Joe MaimonJan 20, 2005 2:16 pm 
Joe MaimonJan 20, 2005 2:21 pm 
Hudson Delbert J Contr 61 CS/SCBNJan 20, 2005 3:29 pm 
Actions with this message:
Paste this link in email or IM:
Paste this link in email or IM:
Atom feed for this thread
Paste this URL into your reader:
Subject:[c-nsp] RIP offset listsActions...
From:Joe Maimon (jmai@ttec.com)
Date:Jan 20, 2005 11:01:53 am
List:net.nether.puck.cisco-nsp

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