Re: BGP failure analysis and recommendations

2013-11-04 Thread Rajiv Asati (rajiva)
: nanog@nanog.org nanog@nanog.org Subject: Re: BGP failure analysis and recommendations As a member of the support team for a vendor, I'll say this problem isn't entirely unheard of. The CPU is in charge of local traffic and the BGP session and some sort of hardware chip or ASIC is in charge of moving

Re: BGP failure analysis and recommendations

2013-10-25 Thread Pete Lumbis
As a member of the support team for a vendor, I'll say this problem isn't entirely unheard of. The CPU is in charge of local traffic and the BGP session and some sort of hardware chip or ASIC is in charge of moving packets through the device. If the hardware is misprogrammed it won't properly

Re: BGP failure analysis and recommendations

2013-10-24 Thread Brandon Ross
On Wed, 23 Oct 2013, Christopher Morrow wrote: On Wed, Oct 23, 2013 at 10:40 PM, JRC NOC nospam-na...@jensenresearch.com wrote: Have we/they lost something important in the changeover to converged mutiprotocol networks? Is there a better way for us edge networks to achieve IP resiliency in

RE: BGP failure analysis and recommendations

2013-10-24 Thread Sam Roche
[mailto:morrowc.li...@gmail.com] Sent: October-23-13 11:06 PM To: JRC NOC Cc: nanog list Subject: Re: BGP failure analysis and recommendations On Wed, Oct 23, 2013 at 10:40 PM, JRC NOC nospam-na...@jensenresearch.com wrote: Is this just an unavoidable issue with scaling large networks? nope... sounds like

Re: BGP failure analysis and recommendations

2013-10-24 Thread Christopher Morrow
On Thu, Oct 24, 2013 at 3:07 AM, Brandon Ross br...@pobox.com wrote: On Wed, 23 Oct 2013, Christopher Morrow wrote: On Wed, Oct 23, 2013 at 10:40 PM, JRC NOC nospam-na...@jensenresearch.com wrote: Have we/they lost something important in the changeover to converged mutiprotocol networks?

Re: BGP failure analysis and recommendations

2013-10-24 Thread Brandon Ross
On Thu, 24 Oct 2013, Christopher Morrow wrote: Um, how about, don't buy services from network providers that fail in this way? I suppose the question is: how would you know that any particular network had this failure mode? Ask detailed questions about how their network is architected. Do

Re: BGP failure analysis and recommendations

2013-10-24 Thread Courtney Smith
On Oct 24, 2013, at 2:13 AM, nanog-requ...@nanog.org wrote: Message: 7 Date: Wed, 23 Oct 2013 22:40:34 -0400 From: JRC NOC nospam-na...@jensenresearch.com To: nanog@nanog.org Subject: BGP failure analysis and recommendations Message-ID:

Re: BGP failure analysis and recommendations

2013-10-24 Thread Scott Weeks
--- courtneysm...@comcast.net wrote: From: Courtney Smith courtneysm...@comcast.net From: JRC NOC nospam-na...@jensenresearch.com Regrettably, during the outage our BGP session remained active and we continued receiving full routes from the affected AS. And our prefixes continued to be

Re: BGP failure analysis and recommendations

2013-10-23 Thread Christopher Morrow
On Wed, Oct 23, 2013 at 10:40 PM, JRC NOC nospam-na...@jensenresearch.com wrote: Is this just an unavoidable issue with scaling large networks? nope... sounds like (to me at least) the forwarding plane and control plane are non-congruent in your provider's network :( so as you said, if the