Exchange point networks

Bill Woodcock writes:

To expand upon that a little, while an exchange point itself is usually a
layer-2 entity (that's a good thing), the ISPs which are exchanging
traffic across it need to assign IP addresses to their router ports which
are connected to it, and it's good to use a single common block of
addresses for that purpose, and manage them in such a way that the in-addr
DNS for the block provides useful information about which ISP they're
associated with, and contact info, and so forth. IP addresses are
available for this purpose from Bill Manning, bmanning@ep.net, who also
provides a management infrastructure for registering the in-addr names and
contact information.

RIRs may also set aside addresses to be used for exchange points, and
you may want to check with your local RIR for this address space. It
is generally a good thing to establish a relationship with the local
RIR in any case.

    > the ix provider may also choose to provide services on the side...
    > Like other routed networks, if they are multi-homed, they tend to
    > have their own asn.

One of the services that some exchange points choose to provide is a
route-server or "looking glass" which is a router which all or most of the
others peer with, and which either forwards routes between the other peers
(aggregating the routes into single peering sessions) or allows
participants to log in and see what routes other participants are or
should be offering. As a BGP peer, this obviously needs an AS of its own.
Packet Clearing House, a research organization that I coordinate, offers
free route-servers to exchange points, and we also provide the AS number
for the route-servers.

There are actually several different services here, and I think it
would be useful if we had an agreed set of terms for those services.
Below I've put the terms I've heard most often and my sense of their
meaning; if there are other accepted terms or meanings, I would be
happy to hear of them and try to come up with a generic vocabulary.

One is a "route collector", with which exchanges participants peer in
order to give the exchange operator a view into what is going on at
layer 3 within the exchange; the primary use of this is to allow the
exchange operator to correlate layer 2 behavior with layer 3 behavior
when trouble shooting.

Another is a "looking glass" which allows some group (ranging from
participants to the general public) to see layer 3 adjacencies and
some statistics for the exchange; this can be derived from data seen
by a participant at an exchange or from a route collector.

The third is a route server, whose function was originally developed
as part of the routing arbiter project. The route servers allow
exchange participant to outsource the routing task (but not the
forwarding of packets) to a specialized host within the exchange.

        regards,
          Ted Hardie

Yes, when I said "route-server or looking glass" I meant one or the other
or both, not that they were interchangeable terms. My apologies for any
confusion I may have caused.

    > I think it would be useful if we had an agreed set of terms for
    > those services.
    >
    > One is a "route collector", with which exchanges participants peer in
    > order to give the exchange operator a view into what is going on
    >
    > Another is a "looking glass" which allows some group (ranging from
    > participants to the general public) to see layer 3 adjacencies

Hmmm... These would seem to me to be the same thing, just a difference of
who's allowed to log in. I'd call both of these a looking glass.

    > The third is a route server. The route servers allow
    > exchange participant to outsource the routing task (but not the
    > forwarding of packets) to a specialized host within the exchange.

I've also heard some symantic confusion between route-servers and route
reflectors. In conversation, I usually assume that distinction to be
between functionally equivalent boxes operating in the plenum between a
number of administrative domains (a route-server) or as glue between
regions or ASes within one administrative domain (a route reflector).
I don't know how common that understanding would be, though. Anyone have
any better thoughts on the difference between a route-server and a route
reflector?

                                -Bill

One difference is that Route Servers, like the ones run by Merit RSNG team, are based on the Internet Routing Registry, whereas route reflectors are not. Route Server routes are re-announced based upon configured IRR policy.

I also think of Route Reflectors as being both internal AS (IGP) and external AS (BGP) re-announcers whereas Route Servers are strictly inter-AS (BGP).

Bill

I like to think of a route server, when used for actual routing exchange rather than statistics collection alone, as a means of scaling eBGP by reducing the number of peers. That complements a route reflector, which is a means of scaling iBGP.

Bay RS, at one point, made a distinction between a route reflector and a route reflector server, both for iBGP scalability. I'd have to do some digging to find out if the latter was more than a marketing distinction.

One difference is that Route Servers, like the ones run by Merit RSNG team,
are based on the Internet Routing Registry, whereas route reflectors are
not. Route Server routes are re-announced based upon configured IRR policy.

Actually, a key difference is that Merit Route Servers allow for
*multiple* views, whereas route reflectors and (most router-based) route
servers provide only *one* view of routes.

-abha :wink:

    > The third is a route server. The route servers allow
    > exchange participant to outsource the routing task (but not the
    > forwarding of packets) to a specialized host within the exchange.

I've also heard some semantic confusion between route-servers and route
reflectors. In conversation, I usually assume that distinction to be
between functionally equivalent boxes operating in the plenum between a
number of administrative domains (a route-server) or as glue between
regions or ASes within one administrative domain (a route reflector).
I don't know how common that understanding would be, though. Anyone have
any better thoughts on the difference between a route-server and a route
reflector?

I've attempted to write that up in a whitepaper I'm doing for several IXP
projects in Africa (see http://www.cisco.com/public/cons/isp/ixp/ - just
remember it is a draft and focused for non-US/Europe IXPs).

One key difference between a Router Server and Route Reflector is that a
Router Server allows for bi-lateral agreements. A Router Reflector forces
Multi-lateral on the whole IXP (see the history with HKIX.

Barry

Another difference is cost:

+ Router Server - cost is workstation, software, and training. You need to
buy the RS software. $120,000 (Merit's price) is a lot of money to collect
for an IXP project in places like Kenya, Sri Lanka, Uganda, Philippines,
etc.).

+ Router Reflector - cost is a router (or a unix box with gated) and
training. (3620 works fine for a IXP with +60 ISPs).

Barry

Actually, that isn't completely true.

+ Router Server - cost is workstation, software, and training. You need to
buy the RS software. $120,000 (Merit's price) is a lot of money to collect
for an IXP project in places like Kenya, Sri Lanka, Uganda, Philippines,
etc.).

If you want to get the fully supported Merit does everything version, then
sure, it is going to cost some money. Mind you that price tag also
includes 24x7 NOC coverage and helping peers out with their policies, etc.
The service you get is worth the price.

If you want a cheap Route Server, download the code (free) and install it
on a cheap PC running FreeBSD or something (close to free). This can
support many many peers just fine.

+ Router Reflector - cost is a router (or a unix box with gated) and
training. (3620 works fine for a IXP with +60 ISPs).

About the same price as a cheap Route Server. Folks often prefer using
routers over a unix box "Route Server" because the interface is familiar.
So, it is understandable why this is a common choice, however, once you
spend the time getting the hang of RSd, there is a lot you can do...

Just my thoughts....

-abha :wink:

Another difference is cost:

+ Router Server - cost is workstation, software, and training. You need to
buy the RS software. $120,000 (Merit's price) is a lot of money to collect
for an IXP project in places like Kenya, Sri Lanka, Uganda, Philippines,
etc.).

+ Router Reflector - cost is a router (or a unix box with gated) and
training. (3620 works fine for a IXP with +60 ISPs).

switch - cost $200-500

randy

Not getting e-mail for every new prefix being announced: priceless

switch - cost $200-500

Not getting e-mail for every new prefix being announced: priceless

rofl!

but folk not at linx will not understand this 'joke'. they're lucky.

and, from an american commercial point of view, this week's wonderful
linx-ism, linx admin publicly announcing that a peer's bill is overdue,
and giving their name etc., was absolutely over the top.

randy

>> switch - cost $200-500

Not getting e-mail for every new prefix being announced: priceless

rofl!

but folk not at linx will not understand this 'joke'. they're lucky.

and, from an american commercial point of view, this week's wonderful
linx-ism, linx admin publicly announcing that a peer's bill is overdue,
and giving their name etc., was absolutely over the top.

randy

A peer's bill is overdue? But I thought the Lords were becoming even more irrelevant?

The LINX is in effect a partnership. It's owned by all of its
members. How would you propose that it deal with someone who hasn't
paid their bill?

The late payer's name was not announced publicly. It was announced
to the other owner/members on a private list.

This is not a question of differences in practice between Europe and
America, nor is it a commercial vs non-commercial issue.

If the LINX were, for example, a American law firm, and one of the
partners wasn't paying his or her fees, I don't believe that anyone
would consider it at all strange if the other partners were informed.
On the contrary: partners would be outraged if they found that
office staff were concealing from them the fact that another partner
was not paying up.