On Monday, January 06, 2014 08:24:22 PM Nick Hilliard wrote:

except qos (which needs switch port buffer space). There are no cheap 10G boxes on the market at the moment which have reasonable numbers of 10G ports and reasonable sized. Plenty which have 2-4 10G ports with reasonable buffers and lots more which have plenty of 10G ports with hardly any buffer space.

FIB space requirements in a switch are also going to limit your options. Also, many "non-service provider" switches don't do egress policing (they might do shaping, but then if the buffers are small...). Mark.

A little bit overkill in term of number of ports but you can consider the new Trident 2 switches Juniper EX-5100, Cisco Nexus 3100 ..... They have unified TCAM that can store 128K v4 routes

the nice thing about buying bgp devices that can not hold a full table is that you can expense them in the year of purchase as opposed to amortizing them over 5 years or so. randy

On 06/01/2014 19:43, Mark Tinka wrote:

FIB space requirements in a switch are also going to limit your options.

it's the merchant silicon boxes which are driving high density 10g prices down, but most of these boxes tends to come with small fibs and tiny buffers which limits their deployment usefulness. Still, if they work for your requirements, they are completely awesome. Nick

On Wednesday, January 08, 2014 09:45:50 PM excelsio@gmx.com wrote:

That´s actually a topic, I was thinking ago some time ago. Why not take a current TOR switch with 1. BGP support and 2. high buffer. Like mentioned above we have Trident 2 bases switches. HP (no recommendation) has its HP 5930 series but tells "Routing table size 16000 entries (IPv4), 8000 entries (IPv6)", but this one has 4GB RAM, so plenty of space for full tables. I haven´t tried it out myself, perhaps someone tried on any other device: What will happen, if I give the switch a full table? Is there a software limit by the vendor, which will simply cut everything above? Or would it simply work?

The 4GB RAM is control plane memory. The problem is FIB memory, since switches generally forward Layer 2 and Layer 3 traffic in hardware, and this relies on forwarding entries being recorded into the FIB. The 16,000 IPv4 entries or 8,000 IPv6 entries is because of limited FIB memory. It's, typically, a switch limitation. Mark.

On Wednesday, January 08, 2014 10:33:55 PM joel jaeggli wrote:

There are various reasons why one might take a full table on a switch with not not enough FIB, the important part of course being the part where you don't install them all.

In Metro-E deployments, this is a good use-case when the box is providing both IP and Ethernet services to the same or different customers out of the same chassis. It avoids having to run 2x eBGP sessions for the IP services (the first being point-to-point eBGP between the switch and the customer to get their routes into the network, and the second being an eBGP Multi-Hop between the customer and a "bigger" box in your core to send them the full BGP table). If a switch allows you to keep the routes in control plane RAM without downloading them into the FIB, you can maintain a single point-to-point eBGP session to the customer, including sending them the full table, provided you have a default route in the switch's FIB to handle actual data plane traffic flow from the customer upstream. Mark.