[c-nsp] RIP offset lists - David Barak - net.nether.puck.cisco-nsp

10 messages in net.nether.puck.cisco-nsp[c-nsp] RIP offset lists

From	Sent On	Attachments
Joe Maimon	Jan 20, 2005 7:05 am
Rodney Dunn	Jan 20, 2005 9:21 am
David Barak	Jan 20, 2005 10:22 am
Joe Maimon	Jan 20, 2005 10:58 am
Joe Maimon	Jan 20, 2005 11:01 am
Rodney Dunn	Jan 20, 2005 11:26 am
David Barak	Jan 20, 2005 11:46 am
Joe Maimon	Jan 20, 2005 2:16 pm
Joe Maimon	Jan 20, 2005 2:21 pm
Hudson Delbert J Contr 61 CS/SCBN	Jan 20, 2005 3:29 pm

	Permalink for this message Paste this link in email or IM:
	Permalink for this thread Paste this link in email or IM:
	Atom feed for this thread Paste this URL into your reader:

Subject:	[c-nsp] RIP offset lists	Actions...
From:	David Barak (theg...@yahoo.com)
Date:	Jan 20, 2005 11:46:42 am
List:	net.nether.puck.cisco-nsp

--- Joe Maimon <jmaimon at ttec.com> wrote:

David Barak wrote:

--- Joe Maimon <jmaimon at ttec.com> wrote:

My primary question before delving into solving the mysteries is this: are you running RIP between your provider network and the customer network, and if so, why?

Often. Because thats what the customer's gear supports and it happens to be trivial to manage for those cases. What would you run? OSPF? Cisco proprietary EIGRP? BGP?

No, no, and yes. If I'm going to run a routing protocol with a customer, it's going to be BGP.

What routing protocols can you run on a pppoe l2tp VA link that can be managed from AAA attrs?

This goes to the heart of the matter: why do you want to manage your ROUTING PROTOCOL with your AAA? That's mixing layer-7 (AAA) with Layer 3/4 (routing). Once you've had the initial handshake/authentication, just let the routing protocol do its thing.

Assertions: If a customer is multihomed, the $40 linksys is no longer the appropriate CPE device (clearly multihoming is for resiliency, and the linksys is not exactly what we'd call "high-availability" ;)

Yes but the customer now believes that 2 $40 linksys routers are perfectly appropriate. After all, they can reboot them themselves.

They're fully appropriate for a home user, or for a not-so-business critical need (Internet access for a library kiosk, perhaps).

Sure I would like to sell them the 1721 but that often as not does not happen. If you dont want those customers and I dont want those customers, that makes no never mind to management. Its always "can it work? Yes? So what if its not the right way? Do it anyways! Its a recurring revenue stream!"

Try a 8xx router (the 831 is my personal preference). less than 1/3 the price of a 1721.

The first question a customer asks after hearing what a 1721 with a WIC-1E and a WIC-T1 costs (with upgrades to run new IOS with features such as firewalling) are "can you do it cheaper with x or y, and if not explain it in writing?"

8xx comes with some limited firewall/vpn features - certainly more than the linksys does (and the 8xx has working SNMP, which is iffy on the linksys).

You're basically comparing apples and oranges here - I can make a working telephone out of two cans and a string, but I'll be darned if I'm going to support a mission-critical or complicated application on it.

If a customer is singly-homed, why not statically route them? Let the routing protocol they run be exclusive to their network.

Mostly this is what we do. Sometimes we even do that with two links to the same router, but then again thats a cisco thing that makes that work.

If they're trying to do some kind of load-balancing or failover mechanism, get them to use something other than Layer-3 resiliency (perhaps layer-7 resiliency?)

Back to the $$ again. Such as a 1721/2620XM with 12.3(8)T or higher. Maybe they could just run a script on every computer that pings google and on failure changes their default gateway to their other NAT box, but I sure as heck dont want to support that.

That wasn't what I meant. An example of Layer-7 resiliency is DNS, which uses multiple servers in order - if one is unreachable, no problem, go to the next one.

You're mixing a variety of technologies which aren't designed to work together, and hoping that it will work. Once you start going down the lowest-common-denominator (i.e. $40 for CPE) path, don't be surprised that features like multihoming don't work effectively anymore. Pushing the features from where they belong (the customer's network) into your network will only make scaling harder and increase your chances of having a catastrophic meltdown.

[As an aside, the 8xx series supports HSRP, so resililiency is more easily obtained with them than multiple linksys devices.]

So, while the problems Cisco has with RIPv2 are non-trivial, why are they impacting a production network?

Because of the gear thats in use, mostly the Customers gear which has a different budget approval process than mine.

If you're selling a product, just define the features you'll offer, and offer them. If you're selling a managed service, why not simply say "if you want this feature, you have to have CPE which supports X." The two-cans-and-a-string approach works fine for one customer, but letting this garbage onto your network means that you'll be stuck supporting services which "kind of work"(tm) indefintely.

	Start a set with this search
	Include this search in one of my sets
	Exclude this search from one of my sets
	Permalink to these results Paste this link in email or IM:
	Atom feed for tracking future search results Paste this URL into your reader: