""Howard C. Berkowitz"" <[EMAIL PROTECTED]> wrote in message
news:p05001902b6d33bdfc13c@[63.216.127.100]...

I think that many ISP routers can be "core", not as in the core layer --
but an ISP router at any layer could be one of those described in the
http://lightreading.com/testing Internet Core Router Test.

I mean, first you have to define ISP.... and don't even think about
saying "Tier 1" ISP because we've been through that one enough.

Many ... "ISPs" ... use GSR 12000's for all their routing in a transit-AS
(even Hotmail and Ebay).  These are clearly peering or border routers.
Juniper routers (from M5 to M160) will do great BGP and aggregate
a lot of IP routes and a lot of interfaces (especially packet SONET),
making it another great choice for ISP connectivity and peering.

> It's misleading to think that all ISP routers need to be "core."
> Arguably, the highest-bandwidth "core" routers inside an ISP may not
> need to run full BGP, but have more stringent demands on OSPF, ISIS,
> and/or MPLS.  Think of RFC 2547 "P" routers.

IBGP runs in the core with full routes.  Are you talking about MP-BGP?
MPLS-TE doesn't bother with IBGP information directly (i.e. the constraint-
based routing is for SPF calculations and doesn't factor into the BGP
decision process or convergence).  MPLS-TE and MPLS-VPN are pretty
separate topics.  Yes, you don't have to do MP-BGP in the core, but I am
sure that since most ISP's use IBGP in the core, it's also MP-BGP (no bgp
default ipv4-unicast).

This is a the primary place for "core" routers from what I have seen.
I mean, it is called the "core layer".

> An ISP POP access router might have the greatest number of BGP routes
> and paths, but not as much bandwidth requirements.  If the POP router
> primarily deals with customers, it will advertise only default and
> partial routes to many of them.  Only a small proportion of customers
> want full routes. A POP router will also generally accept only a
> small number of routes from customers.

It sounds like you are describing the access layer, which may or may not
have BGP at all.  IP and circuit aggregation is more important here than
transit or anything else IMO.

"core" routers can also be placed at this layer, although they would
be called "border" or "access" instead.  Most of the "core" routers
described in the test don't have enough integrated access and different
types of interfaces to shine in the access layer.  Technically, this should
all be transport (Cable, DSL, ATM, Optical) for best use of resources
and superior aggregation (PPPoE, PPPoA, PVC/PVP, VCI/VPI, and
especially DWDM).  The days of a separate router with a separate
CSU/DSU with a separate circuit for each separate customer for access
are hopefully long and gone.

> Interprovider routers at tier 1 are unlikely to need to exchange full
> routes  Such routers are bandwidth-intense, but the definition of a
> tier 1 is that you exchange only customer routes (perhaps
> oversimplifying, but that's close) with other tier 1 providers.

This is the peering situation I mentioned above.  "core" routers definitely
have a place here, but they would be called something else (e.g. "border").

I think there is even more places an ISP could find uses for a "core"
router.  For example, in the distribution layer, a "core" router could be
used for IP aggregation, separation of IGP areas, route filtering, route
dampening, etc ... to provide more flexible routing stability and control.

So while the Foundry NetIron does not currently fit the bill for MP-BGP
and MPLS-VPNs (or any MPLS for that matter), it could still easily do
simple peering, simple distribution/control, etc.  It also *could* do ISP
core routing, but (as shown in the tests) Juniper and Cisco would make
better choices.

As you can see, I definitely agree there is no *best* "core" Internet
router,
because each has its own limitations and areas of excellence.

-dre


_________________________________
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

Reply via email to