[c-nsp] Question about routing table size on the route reflector
Mark Tinka
mtinka at globaltransit.net
Mon Feb 22 11:53:45 EST 2010
On Saturday 20 February 2010 11:34:23 pm Burak Dikici wrote:
> I am trying to understand the requirements of the route
> reflector's routing table size. Here is the scenario ;
>
> - internet router is doing multihoming with three
> different ISPs. It is getting full internet routes from
> all of them.
Well, the number of peers your peering routers have is not
relevant to the number of routes your route reflectors will
see from this peering router.
The route reflector will only "see" the best paths chosen by
your peering router (for better or worse, but those are the
rules). So assuming today's full table of some 309,000 IPv4
entries, if your peering router has 3x 309,000 views, the
route reflector will see only 1x 309,000 views from this
peering router.
In this case, you likely need to be more worried about
sizing your peering routers with the right memory compliment
(both software and hardware) so they don't overflow, than
your route reflector... but I digress :-).
> - There are 25 PE routers in the topology.
How many routes are being announced by each, to the route
reflector? L3VPN's are real routing slot hoggers.
> How can i define the requirement of route reflector's
> IPv4 and VPNv4 routing table size ? 1 million , 2
> million or whatelse ???
>
> Could you help me to understand the logic of this
> requirement? Kind Regards...
The reason I choose software-based routers as route
reflectors, first, is because:
- If you run dedicated route reflectors, they aren't in the
forwarding path.
- DRAM is cheaper than TCAM/SSRAM/RLDRAM, e.t.c.
The only reason I'd consider using a hardware-based platform
to handle route reflection is because that's all we have
today. Cisco's ASR1004 and ASR1006 platforms, for instance,
have a new RP (Route Processor), capable of 16GB DRAM. It's
a bit of waste as a dedicated route reflector, but what
you're after is memory. Then again, I know of a situation
where a customer bought a certain vendor's router purely for
route reflection because it was the only one that had 4GB of
DRAM in the control plane at the time. I guess Quagga +
Super Micro lost out there :-).
On the other hand, we're still very happy with the Cisco
7201 as a route reflector. With 2GB of DRAM and ~1.8GB
available after loading IOS 12.2(33)SRC5, we can't really
complain.
If you're sizing a route reflector, unless you suspect it'll
be in the forwarding path, look at tons and tons of DRAM
memory and great CPU performance.
aside: I have seen some platforms from vendors that claim to
have installed a route in the forwarding engine
(hardware-based platform), but actually didn't. Makes
for interesting conditions :-).
Cheers,
Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20100223/4485c235/attachment.bin>
More information about the cisco-nsp
mailing list