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.
Thanks
Adel
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
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.
I'm up against the same issue. I'm having a hard time understanding what
partial routes will accomplish in the following scenario.
Let's say we were BGP multi homed and accepting partial tables from two
top level ISPs (like Sprint, Cogent, Telia, AT&T whatever). Let's say
they get into a peering spat with another top level ISP. This results in
one of your upstreams not routing packets to one or more ASs.
In this situation, as far as I can tell, you'd want a full routing
tables from your upstreams. Without a full routing table how would your
router know that certain ASs are reachable through one upstream, but not
the other?
In this day of and age of wild-west, cowboy attitudes between some of
the biggest players on the Internet, does protecting against these
problems require a routing device that can handle multiple full routing
tables? It would seem so...
Cheers,
Stef
Stef Walter wrote:
In this day of and age of wild-west, cowboy attitudes between some of
the biggest players on the Internet, does protecting against these
problems require a routing device that can handle multiple full routing
tables? It would seem so...
It has been routinely observed in nanog presentations that settlement
free providers by their nature miss a few prefixes that well connected
transit purchasing ISPs carry.
If business requirements for reachability necessitate multi-homing then
carrying the tables if probably also a requirement.
joel
It has been routinely observed in nanog presentations that settlement
free providers by their nature miss a few prefixes that well connected
transit purchasing ISPs carry.
just trying to understand what you mean,
o no transit-free provider actually has all (covering) prefixes needed
to cover the active space, but
o one or more reasonably small subsets of the set of transit-free
providers do cover the whole active space.
randy
Randy Bush wrote:
It has been routinely observed in nanog presentations that settlement
free providers by their nature miss a few prefixes that well connected
transit purchasing ISPs carry.just trying to understand what you mean,
o no transit-free provider actually has all (covering) prefixes needed
to cover the active space, buto one or more reasonably small subsets of the set of transit-free
providers do cover the whole active space.
If your goal is near-complete coverage, under normal circumstances you
need more than one (your subset). Settlement-free provider peering spats
are a degenerate condition of the normal state of affairs. The
non-settlement-free provider has some subset already.
Pointing default into a settlement-free provider, that is deliberately
not speaking to another is obviously a recipe to lose data, which speaks
to the question of whether one should as for a full table from
settlement free upstreams.
My somewhat obtuse point was that this isn't some wild west frontier
justice sort of affair, but rather, the normal state of affairs.