Re: OT: Full BGP route table doing go slow down a router by

From: William McCall <william.mccall_at_gmail.com>
Date: Mon, 6 Dec 2010 21:42:31 -0600

You'll have malloc failures and interesting problems that will most
likely cause this packet forwarding device to cease performing its
primary function.

On 12/6/10, Rob Clav <robclav_at_gmail.com> wrote:
> Hi,
>
> I had doubts about how to troubleshooting the following scenario.
> "A company is dual homed using a couple of 10Mbps connections, but they are
> complaining about a slow connection."
> Well the scenario is two routers speaking iBGP with just one eBGP each. They
> are using VRRP in order to be used as a default gateway by the internal
> networks.
>
> Clue A: They have (almost) the global full BGP route, they are not learning
> them for the IGP ("no sync").
> Clue B: They are announcing only self generated prefixes(itself AS) and
> receiving only from their peers(4 hops away using ebgp multihop).
> Clue C: The service provider ensure there's no congestions on the lines and
> the customer is using the 60% of the lines.
> Clue D: No QoS in place
> Clue E: There's several logs associated to incomming ACLs.
> Last Clue: There's 15Mb free RAM allocable.
>
> The amount of the Ram at both routers are 256 Mb, the Cisco minimum RAM
> amount, is 512Mb for full BGP table.
>
> Obviously the amount of RAM is an issue but, if the Ram is running out, then
> the connection will go slow down or stop?
>
> Any comment will be appreciated,
> Robclav
>
>
>
> --
> Robert Clavero
> CCIE RS/wr, CCNP, CCSP, CCSE NGX, SCSA 9, WLFES, BNP y JNCIA WX
> blog:http://robclavbcn.blogspot.com
>
> web:http://www.kubsolutions.com
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
>
>
>
>

-- 
Sent from my mobile device
William McCall, CCIE #25044
Blogs and organic groups at http://www.ccie.net
Received on Mon Dec 06 2010 - 21:42:31 ART

This archive was generated by hypermail 2.2.0 : Sat Jan 01 2011 - 09:37:49 ART