Well said Howard, I always believe reading Halabi's book only makes
understand BGP and know how to configure it on Cisco. But there is no way
you can play a peer router in a NAP just based on that knowledge. You will
mostly screw it up.
As you said, most of things are not documented, it is really hard to find
good reference on how to setup an ISP from scratch.
Looking forward to your book. I would suggest that if you could put more
real cases/examples of setup peer routers, verify/update peer policy and
trouble-shooting routing problems. Also it would be great if you could,
based on your wide contact in the industry, give us something like this, for
example:
This is how UUnet updates their peer policy everyday, they use a Perl script
to grap daily updates from whois.radb.net database, and automatically update
their peer routers. The script looks like this:xxxx. Other ISPs do it other
ways like xxxx uses xxx and xxx uses xxx.
I bet most of people, especially who works for ISPs but not at the top
level, would pay their money for.
Just my 2 cents.
KY
""Howard C. Berkowitz"" <[EMAIL PROTECTED]> wrote in message
news:p05001902b6ea44b7d429@[63.216.127.100]...
> Believe me, I sympathize. My first attempt to connect to the Internet
> failed due to not considering publishing my policy in a routing
> registry (e.g., RADB). See http://www.radb.net, or the routing
> registry areas at http://www.arin.net and http://www.ripe.net.
>
> One of my concerns with the way that Internet routing is taught is
> that most presentations are about the configuration of a router or
> two, when it is essential first to understand how the routers fit
> into the global routing system. Playing in the global routing system
> involves a lot more than BGP announcements. As you have observed, it
> involves address assignment, AS number assignment, and registering a
> routing policy at the very least. Reverse DNS, swip/rwhois,
> filtering, and many other factors will enter into real-world
> operations.
>
> It's also often unclear what people are trying to do when they want
> anything beyond single-link, default-routed connectivity to an ISP.
> Have you ever been to a convention where officious people push you
> around with no explanation other than muttering "security?" I'm
> afraid I often hear "load-sharing" muttered in the same way with
> respect to Internet connectivity. There is no single thing that is
> defined as load sharing, and there are different reasons to want or
> not want different load sharing options.
>
> In my BGP tutorials at CertificationZone (member area), I've tried to
> emphasize "define policy first, then think about configuration."
> You'll also see this philosophy in my tutorials at NANOG, and in my
> upcoming book (end of the year) on building service provider networks.
>
> The message remains, whenever someone thinks they are ready to
> configure BGP on a live router to an ISP, if that is all they think
> they need to do to get connected, they are not ready. Since a lot of
> this isn't written down, it's very wise to find a knowledgeable ISP
> and work with their presales people very closely.
>
> Finding the clueful people can be a crapshoot, I will admit. I can
> think of one national carrier with whom I've dealt in different
> cities. For the account in Washington DC, which literally did have
> Presidential priority, the particular carrier was slow and
> inflexible. For a different account with the same provider in
> Nashville, the account team couldn't have been more responsive, both
> at sales and engineering levels.
>
>
> >I know that in our case, trying to use BGP for failover between two
> >providers, we
> >(a) were required to have a /24 <UUnet> ... no problem
> >(b) were required to have an AS# ... no
> >problem
> >(c) PSI *required* us to 'take posssession' of the maintainer object for
our
> >/24 ... still working on that part
> >a. <<very few people appear to have ever heard of RADB ... very
> >frustrating>>
> >(d) once we finish (c) we *should* be all set .. unless PSInet finds
another
> >way to delay us.
>
>
> Unless, of course, PSInet simply goes into bankruptcy. I wish them
> well, but the financial press does seem to suggest that the vultures
> are getting very close.
>
> >
> >I only send this because the "RADB/ Maintainer Object" part has been a
> >really painful delay .. but, that should be resolved today :).
> >
> >
> >Thanks!
> >TJ
> >
> > -----Original Message-----
> >From: John Neiberger [mailto:[EMAIL PROTECTED]]
> >Sent: Thursday, March 29, 2001 17:08
> >To: [EMAIL PROTECTED]
> >Cc: [EMAIL PROTECTED]
> >Subject: Re: BGP over two ISP links
> >
> >At a minimum you're going to need a single /24, not two. You would
> >announce this prefix on both connections. You're also going to need to
> >apply for an autonomous system number from ARIN. Details can be found
> >at www.arin.net.
> >
> >I'm wondering what you're really trying to accomplish. If this extra
> >link isn't for redundancy, just load sharing, then why not have two
> >connections to the same provider? This is FAR easier to implement, does
> >not require a public AS number, and does not require using up an entire
> >/24 prefix unnecessarily.
> >
> >Even if the link is for redundancy, you could multihome to different
> >POPs of the same provider. Again, this is easier to implement, doesn't
> >require the AS number, and doesn't burn up so many addresses. If you
> >have a good provider this is an excellent solution.
> >
> >I'd seriously consider these other options before you make a decision.
> >
> >Regards,
> >John
> >
> >>>> "Ruihai An" <[EMAIL PROTECTED]> 3/29/01 2:11:17 PM >>>
> >Hi, All,
> >
> >Here is a quick question:
> >We are planning to run BGP over two ISP links to provide loading
> >balance.
> >But we were told that we will run into major problems if we do not have
> >full
> >class Cs on both ends.
> >
> >Could somebody make comment on this?
> >
> >Thanks
> >
> >Ruihai
>
> _________________________________
> FAQ, list archives, and subscription info:
http://www.groupstudy.com/list/cisco.html
> Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
>
_________________________________
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
