At 8:57 PM +0000 10/1/02, Don wrote:
>I think it should be pointed out here that the land mine isn't even
>linking the customers IGP to the ISP's IGP. The land mine is linking the
>IGP's of the customers to each other. Consider having 1000 customers, all
>advertising their nets to this IGP, then consider what happens when one of
>them decides to makes a net entry that is flat out wrong. For instance,
>customer A decides he now wants to add network B and starts advertising it
>in the IGP to the ISP. Customer B and the ISP suddenly have major problems.
>The only way to prevent this to is install route filters for all 1000
>customers. And fixing it after it happens is a major nightmare. And do you
>really think every one of those 1000 customers will advertise their networks
>correctly?
> Personally, I find it much easier and safer to do 1000 static routes.
>The solution below only works if the ISP has sole control of each of the
>1000 customers edge routers. And again, 1000 static routes is more
>reasonable than adding the burden of managing 1000+ more routers. Imagine
>the password nightmare (or did you really expect to put the same password on
>the routers of two different customers?). So now we add a RADIUS server.
> Don
Excellent points. I think many people assume static routes are
unmanageable because they think they have to configure them manually.
Not so.
I don't know of an ISP that doesn't use some automated tool, even a
spreadsheet, to manage address space it assigns to customers. These
things can print reports, which can become files! Assume all your
customers get /24 blocks in 10.1.0.0, and you assign a /30 from
10.0.0.0/23 to their link to you.
Example:
LAN WAN
10.1.0.0/24 10.0.0.0/30
10.1.1.0/24 10.0.0.4/30
10.1.2.0/24 10.0.0.8/30
Create a couple of conventions:
-- the LAN router interface is the highest address in the subnet, in this
case .254.
-- the customer end of the WAN link is .1
-- the ISP end of the WAN link is .2
Now, as you check off the address assignment, generate the statement:
ip route 255.255.255.0
and put it in a configuration library for the distribution router
You can get this information into the distribution router without
rebooting using a telnet script or various copy/merge operations into
RAM or NVRAM.
In like manner, you can generate the default route for the remote
router, and DNS RR records for everything.
>""Mike Bernico"" wrote in message
>[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
>> I'm not sure I'm in complete agreement. The network I work for has
>several
>> distribution routers that contain around 1000 T1 speed customers. If we
>> were to static route each of their networks it would add about 1000 to
>1500
>> lines of router configuration to the router. That would definately add
to
>> our maintenance and provisioning work and make troubleshooting harder on
>our
>> techs. While I agree statics are probably the most stable way, I'm not
>> sure it's necessarily the best way to aggrigate high volumes of
customers.
>> We currently use EIGRP at the edge with the stub command, OSPF or IS-IS
>> would work just as well. Regardless, we would never let our IGP, that
>> extends to the CE router, touch their IGP. About 98% of our customers
are
>> not BGP customers though.
>>
>> YMMV
>> Mike
>>
>> -------------------
>> Mike Bernico [EMAIL PROTECTED]
>> Illinois Century Network http://www.illinois.net
>> (217) 557-6555
>>
>>
>> > -----Original Message-----
>> > From: Howard C. Berkowitz [mailto:[EMAIL PROTECTED]]
>> > Sent: Monday, September 30, 2002 11:37 AM
>> > To: [EMAIL PROTECTED]
>> > Subject: Re: OSPF for ISPs [7:54540]
>> >
>> >
>> > At 2:58 PM +0000 9/30/02, Don wrote:
>> > >Rather than run OSPF to customers, it is generally much
>> > better to have
>> > >them use a default route to the ISP and for the ISP to run
>> > static routes to
>> > >the customer. OSPF to the customer is a huge land mine for
> > > the ISP and
>> > >should be avoided in almost every case.
>> > > Don
>> >
>> > I agree completely with Don that an ISP _never_ should link its IGP
>> > to that of the customer. Don't fall into the trap of assuming that
>> > BGP needs a full routing table or will consume excessive resources.
>> >
>> > I remain confused why a default route wouldn't serve, unless there
>> > are multiple connections between the ISP and customer. By "send the
>> > block to the customer," do you mean the block is in the customer's
>> > space? You could certainly use a second static route, which can be
>> > generated automatically as part of your address assignment (see my
>> > NANOG presentation,
>> > http://www.nanog.org/mtg-9811/ppt/berk/index.htm).
>> >
>> > If that's not appropriate, have the customer announce his two blocks
>> > to you with BGP and receive default from your BGP.
>> >
>> > >
>> > >
>> > >""Chris Headings"" wrote in message
>> > >[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
>> > >> Good morning all. I was wondering if someone could lend
>> > me a little help
>> > >> about engineering OSPF in the backbone for an ISP
>> > network. I just had a
>> > >> couple of questions and hopefully someone can give me
>> > some guidance.or
>> > >even
>> > >> some CCO links with some specific examples or better yet
>> > any material
>> > >> anywhere.
>> > >>
>> > >> Say, for example, that a customer has a small block of IP's and a
>> > >> distribution router knows where that block is, via a
>> > connected route,
>> > like
>> > >a
>> > >> /30 on a serial link. But later down the line the
>> > customer requests an
>> > >> additional block of 64 IP addresses, what is the best way
>> > to send this
>> > >block
>> > >> to the customer? Do I need to run OSPF on the customer
>> > equipment? If
>> > the
>> > >> customer router is not running OSPF, how do the routers
>> > know how to get
>> > to
>> > >> this destination? I assume via static routing???
>> > >>
>> > >> Thanks as always.
>> > >>
>> > > > Chris
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=54677&t=54540
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
