[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