 | 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: |
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: | Joe Maimon (jmai...@ttec.com) | |
| Date: | Jan 20, 2005 2:16:01 pm | |
| List: | net.nether.puck.cisco-nsp | |
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