Re: Route table growth and hardware limits...talk to the filter

On 9/21/07 7:18 AM, "Pekka Savola" <pekkasnetcore.fi> wrote:

> The way I see it, a network which is considering
"Juniper M7i or Cisco
> 7300 plus a couple of switches" as an option does
not _need_ 220K IPv4
> routes in its routing table.  Whether it has 150K, 40K
(Hi Simon!) or
> 5K shouldn't matter that much from the functionality
perspective.

There are a couple of reasons:

1.  The "captain obvious" suggestion of a default
means that now I'm paying
for multiple links but can only use one.  That's not cost
effective and will
provide lower performance for some destinations.  I have
done defaults in
the past where appropriate but it's not appropriate in this
application.

2.  The idea of a complex filtering strategy is, from my
perspective, an
even worse idea.  You get all of the downsides of a default
with increased
operational complexity that may not scale across multiple
sites depending on
the size of your ops team.  Oh, and don't forget, for
testing and validation
you'd need to buy a router that can take these multiple
feeds to test the
results of the filtering policy.

Both of those options are viable (#1 obviously over #2) if
just basic
connectivity is required.  However I find myself not really
wanting to have
to continually support solutions with such limitations when
there are other
options.    


--  
                                John A. Kilpatrick
johnhypergeek.net                Email|     http://www.hypergeek.net/
john-pagehypergeek.net      Text pages|          ICQ:
19147504
                  remember:  no obstacles/only challenges

On Fri, 21 Sep 2007, John A. Kilpatrick wrote:
> 1.  The "captain obvious" suggestion of a
default means that now I'm paying
> for multiple links but can only use one.  That's not
cost effective and will
> provide lower performance for some destinations.  I
have done defaults in
> the past where appropriate but it's not appropriate in
this application.

That's not the case at all.  If you use only defaults, you
could do 
load balancing but in a very crude fashion.  If you use a
default 
route and filtered version of BGP feed (e.g., accept
everything up to 
/21) probably up to 90-95% of traffic would go over that
link, or 
multiple ones if you have multiple BGP sessions.

If you want more control than _only_ a default route or two
(and many 
do), the default route would in principle be just a
safeguard for more 
specifics (or other routes, based on a metric of your
choosing) you 
filter out.

> 2.  The idea of a complex filtering strategy is, from
my perspective, an
> even worse idea.  You get all of the downsides of a
default with increased
> operational complexity that may not scale across
multiple sites depending on
> the size of your ops team.

I'd probably agree if you used complex filtering without a
default 
route.  Having a default route, as long as it points to a
sufficiently 
good (non-tier1, not cogent) upstream allows you not to care
so much 
about how you filter the BGP feed.

But as should be obvious, you don't need to worry about this
problem 
if you're willing to put money into router upgrades. 
However, I'm 
just suggesting there is an alternative to router upgrades
if you're 
comfortable with the somewhat different tradeoffs that will
bring with 
it.

-- 
Pekka Savola                 "You each name yourselves
king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash
of Kings

On Sep 21, 2007, at 2:22 PM, Pekka Savola wrote:

>
> On Fri, 21 Sep 2007, John A. Kilpatrick wrote:
>> 1.  The "captain obvious" suggestion of a
default means that now  
>> I'm paying
>> for multiple links but can only use one.  That's
not cost  
>> effective and will
>> provide lower performance for some destinations.  I
have done  
>> defaults in
>> the past where appropriate but it's not appropriate
in this  
>> application.
>
> That's not the case at all.  If you use only defaults,
you could do  
> load balancing but in a very crude fashion.
> If you use a default route and filtered version of BGP
feed (e.g.,  
> accept everything up to /21) probably up to 90-95% of
traffic would  
> go over that link, or multiple ones if you have
multiple BGP sessions.

Sure, but you do still run the (not insignificant) risk of
following  
the default to the "sufficiently good (non-tier1, not
cogent)  
upstream", only to discover that, for whatever reason,
it has no  
reachability to the prefix. If I have spent to time and
effort to get  
multiple providers, presumably I believe that my bits are
important  
enough to not trust to "this will probably work most of
the time..."

W



>
> If you want more control than _only_ a default route or
two (and  
> many do), the default route would in principle be just
a safeguard  
> for more specifics (or other routes, based on a metric
of your  
> choosing) you filter out.
>
>> 2.  The idea of a complex filtering strategy is,
from my  
>> perspective, an
>> even worse idea.  You get all of the downsides of a
default with  
>> increased
>> operational complexity that may not scale across
multiple sites  
>> depending on
>> the size of your ops team.
>
> I'd probably agree if you used complex filtering
without a default  
> route.  Having a default route, as long as it points to
a  
> sufficiently good (non-tier1, not cogent) upstream
allows you not  
> to care so much about how you filter the BGP feed.
>
> But as should be obvious, you don't need to worry about
this  
> problem if you're willing to put money into router
upgrades.   
> However, I'm just suggesting there is an alternative to
router  
> upgrades if you're comfortable with the somewhat
different  
> tradeoffs that will bring with it.
>
> -- 
> Pekka Savola                 "You each name
yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A
Clash of Kings
>

--
Hope is not a strategy.
       --  Ben Treynor, Google

On Fri, 21 Sep 2007, Pekka Savola wrote:

> But as should be obvious, you don't need to worry about
this problem if 
> you're willing to put money into router upgrades. 
However, I'm just 
> suggesting there is an alternative to router upgrades
if you're comfortable 
> with the somewhat different tradeoffs that will bring
with it.

Yes, I would agree this statement is true but some of the
tradeoffs seem 
pretty high.

My statement about routing platforms was more based on the
fact that what 
my Cisco rep said was true - the sup upgrade was gonna be
cheaper than 
7304s or "option J".  I mean yeah, I could buy
7206s but it still wouldn't 
save me that much.

What just chaps my hide is that there is no reason, in this
application, 
to need 40GB/slot performance.  Their refusal to sell a
cheaper card with 
improved TCAM suggests that the SUP720/RSP720 has really
high margins and 
they're making a killing on this issue...

-- 
                                John A. Kilpatrick
johnhypergeek.net                Email|     http://www.hypergeek.net/
john-pagehypergeek.net      Text pages|          ICQ:
19147504
                  remember:  no obstacles/only challenges

On Fri, 21 Sep 2007, Warren krishnai wrote:
> On Sep 21, 2007, at 2:22 PM, Pekka Savola wrote:
>> On Fri, 21 Sep 2007, John A. Kilpatrick wrote:
>> > 1.  The "captain obvious" suggestion
of a default means that now I'm 
>> > paying
>> > for multiple links but can only use one. 
That's not cost effective and 
>> > will
>> > provide lower performance for some
destinations.  I have done defaults in
>> > the past where appropriate but it's not
appropriate in this application.
>> 
>> That's not the case at all.  If you use only
defaults, you could do load 
>> balancing but in a very crude fashion.
>> If you use a default route and filtered version of
BGP feed (e.g., accept 
>> everything up to /21) probably up to 90-95% of
traffic would go over that 
>> link, or multiple ones if you have multiple BGP
sessions.
>
> Sure, but you do still run the (not insignificant) risk
of following the 
> default to the "sufficiently good (non-tier1, not
cogent) upstream", only to 
> discover that, for whatever reason, it has no
reachability to the prefix. If 
> I have spent to time and effort to get multiple
providers, presumably I 
> believe that my bits are important enough to not trust
to "this will probably 
> work most of the time..."

Our perceptions differ -- you seem to think that the having
full, 
unfiltered BGP feed protects from these problems.  That's
not the 
case.  E.g., in the TeliaSonera routing problem I sent on
the m-l on 
Sep 6, all prefixes were received fine through TSIC, but
certain 
traffic ended up being dropped for the duration of about 9
hours.

Unless you made an administrative action on the router, some
networks 
would have been blackholed for 9 hours regardless of the
fact whether 
you used unfiltered BGP or filtered BGP.

So, if you're uncomfortable with such major networks causing
problems 
in your connectivity, you'll need the ops staff to look
after the 
routing and change it if need be.  Ergo, if you need the ops
staff, 
you could just as easily as shutdown or depref of a badly
behaving 
transit switch the default or change the other priorities.

I guess the main point here is how prevalent "no
reachability, no 
prefix" scenario is compared to
"routing/forwarding broken, manual 
action required".  My take is that the the former is
rare with good 
upstreams and while the latter might not be as frequent as
the former, 
you'll need to prepare for it in any case so the difference
likely 
doesn't matter that much.

-- 
Pekka Savola                 "You each name yourselves
king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash
of Kings

On Sat, 22 Sep 2007, Pekka Savola wrote:

> Our perceptions differ -- you seem to think that the
having full, unfiltered 
> BGP feed protects from these problems.  That's not the
case.  E.g., in the 
> TeliaSonera routing problem I sent on the m-l on Sep 6,
all prefixes were 
> received fine through TSIC, but certain traffic ended
up being dropped for 
> the duration of about 9 hours.

Has everyone forgotten the "Tier 1 depeerings" of
several years ago?  i.e. 
If you were pointing default at C&W, PSINet, Cogent, or
Level3 when they 
each had or caused depeering issues, parts of the internet
ceased to be 
reachable.  In such cases, having full routes from multiple
providers was 
the only way to be automatically protected from such games.

------------------------------------------------------------
----------
  Jon Lewis                   |  I route
  Senior Network Engineer     |  therefore you are
  Atlantic Net                |
_________ http://www.lewis.org
/~jlewis/pgp for PGP public key_________

> 
> My statement about routing platforms was more based on
the fact that what
> my Cisco rep said was true - the sup upgrade was gonna
be cheaper than
> 7304s or "option J".  I mean yeah, I could
buy 7206s but it still wouldn't
> save me that much.
> 
> What just chaps my hide is that there is no reason, in
this application,
> to need 40GB/slot performance.  Their refusal to sell a
cheaper card with
> improved TCAM suggests that the SUP720/RSP720 has
really high margins and
> they're making a killing on this issue...

Actually, originally Cisco planned to release SUP32-XL or
similar variant
with higher FIB TCAM space.  But they scrapped that plan
near the end,
screwing many people in the process (I'm sure some cisco
account reps got
earful about this from many people who bought sup32's in the
past)-- I mean
hey, forcing customers to buy SUP720 plus may be new line
cards (depending
on situation) is more revenue right?  This whole 220k+ ipv4
routing issue is
an excellent opportunity    

On the other hand, if you have the guts, try popping in a
PFC3BXL card into
SUP32.  I wonder which IOS versions will actually recognize
this and show ~1
mil. entry capacity when doing 'sh mls cef max' 
(WARNING: this
completely violates warranty and irreparable damage may
occur)


james

On 9/22/07, James Jun <jamestowardex.com> wrote:
>
> >
> > My statement about routing platforms was more
based on the fact that what
> > my Cisco rep said was true - the sup upgrade was
gonna be cheaper than
> > 7304s or "option J".  I mean yeah, I
could buy 7206s but it still wouldn't
> > save me that much.
> >
> > What just chaps my hide is that there is no
reason, in this application,
> > to need 40GB/slot performance.  Their refusal to
sell a cheaper card with
> > improved TCAM suggests that the SUP720/RSP720 has
really high margins and
> > they're making a killing on this issue...
>
> Actually, originally Cisco planned to release SUP32-XL
or similar variant
> with higher FIB TCAM space.  But they scrapped that
plan near the end,
> screwing many people in the process (I'm sure some
cisco account reps got
> earful about this from many people who bought sup32's
in the past)-- I mean
> hey, forcing customers to buy SUP720 plus may be new
line cards (depending
> on situation) is more revenue right?  This whole 220k+
ipv4 routing issue is
> an excellent opportunity 
>
> On the other hand, if you have the guts, try popping in
a PFC3BXL card into
> SUP32.  I wonder which IOS versions will actually
recognize this and show ~1
> mil. entry capacity when doing 'sh mls cef max' 
(WARNING: this
> completely violates warranty and irreparable damage may
occur)
>
>
> james
>

James,
So it is the vendor's fault that you didn't properly
engineer your
network and size the right kit for the job?  Learn a little
engineering 101 to avoid these situations.

> 
> James,
> So it is the vendor's fault that you didn't properly
engineer your
> network and size the right kit for the job?  Learn a
little
> engineering 101 to avoid these situations.

Did I ever mention that *I* didn't properly engineer my
network (there are
no sup32's on my network as of date)? 

Consider your own arrogance before you make idiotic
statements that add no
value to discussion.

james

> Has everyone forgotten the "Tier 1
depeerings" of several 
> years ago?  i.e. 
> If you were pointing default at C&W, PSINet,
Cogent, or 
> Level3 when they each had or caused depeering issues,
parts 
> of the internet ceased to be reachable.  In such cases,

> having full routes from multiple providers was the only
way 
> to be automatically protected from such games.

Not so. Anyone who had sufficient transit was also protected
from
the games. Lots of so-called regionals and tier-2 networks
were 
shielded from this monkey-business. And, of course, they
shielded
their customers as well. A tier-1 network operator who
operates such
a fragile network becomes a single point of failure. And not
just
because of peering as the AT&T frame relay collapse
shows.

--Michael Dillon