[nznog] [Fwd: IOS and Growing BGP tables]

2 Dec 2004

      I've not seen this discussed on nznog.

---------- Forwarded message ----------
Date: Thu, 2 Dec 2004 14:39:01 +1000
From: David J. Hughes 
To: Oz-ISP Mailing list ,
      isp-australia(a)isp-australia.com
Subject: [Oz-ISP] IOS and Growing BGP tables

Hi,

I'm posting this in an attempt to raise a bit of support.  I've been
arguing for a feature enhancement for IOS that will prolong the life of
most Cisco routers that take a full BGP table.  The growth of the table
is causing concern for many major providers who can see the RAM on
their lower end 7200's running out in the near future.  Their default
solution is not to upgrade the boxes, but to filter out the /24
advertisements.

However, for many years in Australia, a /24 was the normal allocation.
If they blindly filter out all the /24's then lots of networks in
Australia (and other countries) will become unreachable.  The proposed
features allows you to filter a prefix if there is a less specific
prefix already in your table (with various tuneable knobs with respect
to next hop etc).

Some guys at Cisco have taken this on and filed a bug / feature request
for this.  The more people that open a TAC case and have it linked to
this bug ID the higher the priority of this request will become.  It's
being supported on the Cisco-NSP mailing list but I thought it worth
"rattling the cage" on these lists as well.  The more voices the
better.

The Cisco Bug ID is "CSCsa45474 : Ability to block overlapping BGP
prefixes from being installed in RIB".  Some history of the discussions
is included below.  If you have a TAC account and are so inclined,
please open a new case and ask the engineer to link it to this bug ID.

Thanks

Bambi
...

Begin forwarded message:
...
From: David J. Hughes 
Date: 1 December 2004 10:26:18 AM
To: 'cisco-nsp' 
Subject: Re: [c-nsp] Growing BGP tables
I hope that most people on this list would open a case to try to get a
feature like this included in upcoming IOS releases.  It's about the 
only thing that will extend the life of your "RAM limited" routers 
without breaking connectivity to historically legitimate /24 
allocations.
David
...
On 01/12/2004, at 9:40 AM, Rodney Dunn wrote:
...
For those that have the ability to open a TAC case and they think 
this is something they could use, open a case and have the TAC 
engineer attach the case to this bug:
CSCsa45474
Externally found enhancement defect: New (N)
Ability to block overlapping BGP prefixes from being installed in RIB
------

Begin forwarded message:

Anything that reduces the consumption of RIB and
FIB resources as a result of de-aggregation etc
would be a very welcome step in the right
direction.  Thanks for looking into this
Rodney.

David
...

On 24/11/2004, at 3:33 AM, Rodney Dunn wrote:
...
My point was that you can't do it with BGP
because you don't have a way to request a
re-advertisement from a peer when the
less specific goes away.
There is a possiblity we could keep the
more specifics out of the RIB which would
save memory there and in the FIB.
That being said the best that can
be done currently appears to block
the routes from going in the RIB.
We are looking to see how complex that
would be to do.
Rodney
On Tue, Nov 23, 2004 at 11:11:52AM -0600, Brian Feeny wrote:
...
I like this, basically all your doing is getting rid of the redundant 
information which serves no purpose other than taking up space in the 
RIB/FIB anyways.  And if someone should further deaggregate or make a 
change, then the new update is going to run its algorithm against the 
current RIB all over again.
On Nov 22, 2004, at 4:16 PM, David J. Hughes wrote:
...
Hey Rodney,
How about ...
for each prefix received in update
  for each more specific prefix in RIB
    if RIB prefix ge /24 and same next hop as update prefix
      drop RIB prefix
  if update prefix ge /24
    for each less specific prefix in RIB
      if RIB next hop same as update next hop
        drop update prefix
something like that would filter during the update and wouldn't 
require another full copy of the table to be held.  I'm sure you 
guys could come up with something more efficient but the basic idea 
would work wouldn't it?
David
...
----
email "unsubscribe aussie-isp" to majordomo(a)aussie.net to be removed.

[nznog] [Fwd: IOS and Growing BGP tables]

Andy Linton