[c-nsp] RIP offset lists

Thu Jan 20 15:29:45 EST 2005

Both joe and david have valid points.

the lan protocols or igps (ospf, rip, rip2, eigrp, igrp) mentioned
are only really needed to carry the lan routes to the egp for advertisement

a word of caution about implementing BGP - well, actually a lot of words...

it is correct to use BGP for cpe-to-isp protocol routing but
bear in mind a few of over-arching "pseudo-rules" for BGP 
implementation...

DON'T USE BGP IF---

*	connectivity is possible w/defaults and static routes.
	if you can ping it and bgp ain't running, dont start it up.

*	cpe routing is a subset or mimics the ISP's routing policy.

*	if network gear is underpowered as regards memory and cpu as BGP
	tables and updates can be large and resource-intensive.

*	your AS is a stub or reached via a tail-circuit off the ISP.
	(i.e. one way in & one way out.

*	if you cant afford IBgp redundancy....at least 2 ASx IBgp processes
	on diff rtrs, need to know the scope	of 	"meshing" for its own AS and its
	AS neighbors (i.e.--if rtrA in ASx announces a path to ASz and the at least 1
	other ASx rtr doesnt and rtrA of ASx goes down, then the route to 
	the net in ASz will not get announced even if the other IBgp speakers are up.

*	otherwise....rtrA will have to announce reachability info ALL nets ASx
	has paths too. (i.e. the full inet bgp table probably requires at least 128mb min)
	now we have a "SPOF" or "single point of failure"

*	more tcp sessions to manage thru firewall or security device as BGP uses port 179.
	so make sure it doesnt run afoul of mis-configured acls.

*	now one must be vigilant for leaks and managing filters for updates.

*	of course, if one wanted to rid himself of the chores and headacheds
	after its done...one could issue a 'clear ip bgp * w/out using the soft
	keyword and go clear out your desk.

~piranha

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net]On Behalf Of Joe Maimon
Sent: Thursday, January 20, 2005 11:15 AM
To: David Barak
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] RIP offset lists

David Barak wrote:

>--- Joe Maimon <jmaimon at ttec.com> wrote:
>
>  
>
>>David Barak wrote:
>>    
>>
><snip>
>No, no, and yes.  If I'm going to run a routing
>protocol with a customer, it's going to be BGP.
>
>  
>
Many people may wish to offer a 'smaller' option and not mix the two. 
Especialy in our case where such a protocol likely as not carries not 
Internet Visible prefixes.

><snip>
>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.  
>  
>
If you check the IETF radius attributes, they clearly did not have this 
layer objection to the various radius attributes that you seem to have.
Fact of the matter is the rip routing protocol wont even get turned on 
without AAA (letting alone the issue of another cisco ddts on the 
subject). So once I am there, it does not hurt me to add another attribute.

What are you proposing? That connections facilitated by AAA get a random 
IP address and maybe an access list? Anything else be done with BGP? 
That has merit, but happens not to be what we are doing in the majority 
of cases at this point.

That carries its own overhead issues, not to mention configuraion 
burdens and also places certain requirements on equipment. Which is 
where this conversation started.

><snip>
>
>
>They're fully appropriate for a home user, or for a
>not-so-business critical need (Internet access for a
>library kiosk, perhaps).  
>
>  
>
You and I may agree on that but that does not make the customer all the 
more eager to cut that check. Or for us to eat it.
Furthermore, whose to say that the home being connected does not have a 
critical need as well?

>Try a 8xx router (the 831 is my personal preference). 
>less than 1/3 the price of a 1721.
>  
>
The 831 is a fine little router, works everywhere there is ethernet, 
except I do not know how to use it to reliably handle two pppoe dsl 
lines, let alone a dsl line and a t1. It also is a fine RIP router (bugs 
not withstanding) and so there is no reason not to use that on it if one 
feels the wish for it.

The pppoe dialer would have to support being targeted at an offered 
pppoe concetrator name or mac address, and thats an ISP dependency I 
would rather not have, since most ISP's would feel that there is no 
reasonable expectation of those not changing. Or the 831 would have to 
start handling vlans and the pppoe dialer could (l)earn that feature as 
well.

The costs for that would either be two 831 routers or an 831 and a 1721 
in which case I would be better off with the 1721.

>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.
>  
>
At this point I would hardly call a RIP2 configured scheme exchanging a 
few routes with each of a few number of peers string.

>> <snip>
>>
>>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.
>  
>
Experience suggests to me that the number of customers who do this, 
perhaps a bit less automated, is higher than we would expect.
Because it actualy works.

>You're mixing a variety of technologies which aren't
>designed to work together, and hoping that it will
>work. 
>
In my experience they work fine. There is a hardly a less mature routing 
protocol and easily understandable routing protocol than RIP2. The 
example at hand is a CISCO bug, on not inexpensive hardware.

>
>[As an aside, the 8xx series supports HSRP, so
>resililiency is more easily obtained with them than
>multiple linksys devices.]
>  
>
Yes, and it deservedly cost more as well. But wait...expect a future 
linksys to include the more standard vrrp. Then what?

>  
>
>If you're selling a
>managed service, why not simply say "if you want this
>feature, you have to have CPE which supports X." 
>
Because someone has to pay for that CPE. Because often as not, somebody 
has already paid for CPE that is currently being used. Because often as 
not that means the difference in having it turned on now rather than 
maybe next month or not at all.

> 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.  
>
>
>  
>
That is the point we are at. Whether or not it is garbage is only 
relevant for future directions taken. Future directions mean more 
private asn BGP a ospf IGP as well.

>=====
>David Barak
>
>
>  
>
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/