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:Rodney Dunn (rod@cisco.com)
Date:Jan 20, 2005 11:26:12 am
List:net.nether.puck.cisco-nsp

<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