From: Howard C. Berkowitz (hcb@gettcomm.com)
Date: Sat Apr 03 2004 - 20:52:53 GMT-3
At 6:28 PM -0500 4/3/04, Peter van Oene wrote:
>At 05:52 PM 4/2/2004, Peter van Oene wrote:
>>ATHIS IS WHAT I AM NOT UNDERSTANDING. CAN SOMEONE HELP CLARIFY> ARE THEY
>>>REFERRING TO ROUTEMAPS ON THE CLIENT OR THE RR. IF CLIENT, What
>>>if the client
>>>has an IBGP peer other than the RR. I know it is not a good
>>>design to do that but I have seen scenerios that ask for it, and
>>>we know the LAB is not a best practice lab.
>>
>>The below refers to the changing of BGP attributes on a Route
>>Reflector, not the server. Further, meshed RR clients are not
>>necessarily bad. Do you have a situation where you want to change
>>a BGP attribute within your IBGP mesh?
>
>That should say not the client ;-)
Do we even want to bring up the not-as-widely-used-in-production
these days, but still occasionally useful for special applications
and definitely for such things as Internet traffic research, the
route server? A route server does no forwarding whatsoever.
Typically, it's a UNIX box at an exchange point, running RSD
software. What can be a heavy processing load for a router control
plane can be pretty modest for a decent UNIX box with lots of memory.
Just as an aside, most exchange points had two route servers, running
the same routing code on different brands of processors and often
different UNIX variants (e.g., NetBSD vs. LINUX). The idea was to
minimize the impact of RSD platform hardware or software bugs.
Knowing about these, even in a historical context, helps understand
what RRs do. RRs are primarily means of scaling your iBGP by reducing
the number of peers per box inside (most likely) a POP. Best Current
Practice tends to be meshing inside the POP, in many but not all
cases.
When router processors were less powerful, they could bog down at
multilateral exchange points due to the number of eBGP peers. It was
the TCP and BGP processing that hurt them, not bandwidth. Route
Servers were an eBGP scalability technique, so if you had an exchange
point with 20 ISPs, each ISP peered BGP only with the primary and
backup route server. The route server understood where the real
routers were, so would set next hop for forwarding not to itself, but
to the real other-ISP router connected to the common L2 fabric.
This archive was generated by hypermail 2.1.4 : Mon May 03 2004 - 19:48:43 GMT-3