adel@baklawasecrets.com wrote:
Actually thinking about this, I still need to understand the implications of not taking a full routing table to my setup. So what is the likely impact going to be if I take partial instead of full routing table. Would appreciate any feedback on this. My organisation is only looking at using BGP as a means of failover between two separate upstream ISPs. We are not an ISP.
Some Cisco L3 switches should support this fine. A 3560 or 3750 can speak BGP and route at line rate as long as your total number of routes will fit in its TCAM space. Ask your upstreams how big a partial feed from them is. "desktop routing" template: The selected template optimizes the resources in the switch to support this level of features for 8 routed interfaces and 1024 VLANs. number of unicast mac addresses: 3K number of IPv4 IGMP groups + multicast routes: 1K number of IPv4 unicast routes: 11K number of directly-connected IPv4 hosts: 3K number of indirect IPv4 routes: 8K number of IPv4 policy based routing aces: 0.5K number of IPv4/MAC qos aces: 0.5K number of IPv4/MAC security aces: 1K If you ever need IPv6 it gets smaller: number of unicast mac addresses: 2K number of IPv4 IGMP groups + multicast routes: 1K number of IPv4 unicast routes: 3K number of directly-connected IPv4 hosts: 2K number of indirect IPv4 routes: 1K number of IPv6 multicast groups: 1.125k number of directly-connected IPv6 addresses: 2K number of indirect IPv6 unicast routes: 1K number of IPv4 policy based routing aces: 0 number of IPv4/MAC qos aces: 0.5K number of IPv4/MAC security aces: 1K number of IPv6 policy based routing aces: 0 number of IPv6 qos aces: 0.625k number of IPv6 security aces: 0.5K Anything in Cisco land that can hold two full tables in hardware and can do line rate is going to be hideously expensive. ~Seth