Re: BGP peering strategies for smaller routers

2016-05-04 Thread Blake Hudson
Chuck Church wrote on 5/4/2016 12:14 PM: -- Hi Nick, You missed the point. Sloppy memory management is a "canary in a coal mine." It's a user-visible symptom that reflects poor

RE: BGP peering strategies for smaller routers

2016-05-04 Thread Chuck Church
-- Hi Nick, >You missed the point. Sloppy memory management is a "canary in a coal mine." >It's a user-visible symptom that reflects poor code quality underneath. >Programmers who

Re: BGP peering strategies for smaller routers

2016-05-03 Thread Blake Hudson
I turned up a full ip4 feed on an RP1 today. Took approximately 5 minutes to fill the rib and probably another 5 minutes to push to the fib. The CLI responsiveness was noticeably slowed during this process, but the router didn't drop traffic. I'm guessing a second feed would involve fewer rib

Re: BGP peering strategies for smaller routers

2016-05-03 Thread William Herrin
On Tue, May 3, 2016 at 6:18 PM, Nick Hilliard wrote: > William Herrin wrote: >> And it is poor code quality. Even slicing and dicing the ram in odd >> ways, there's just no excuse for an order-of-magnitude increase in ram >> required to run the same algorithms on the same data. >

Re: BGP peering strategies for smaller routers

2016-05-03 Thread Łukasz Bromirski
Blake, > On 04 May 2016, at 00:23, Blake Hudson wrote: > > Łukasz Bromirski wrote on 5/3/2016 4:13 PM: >>> On 03 May 2016, at 22:31, William Herrin wrote: >>> >>> On Tue, May 3, 2016 at 3:50 PM, Gustav Ulander >>> wrote:

Re: BGP peering strategies for smaller routers

2016-05-03 Thread Carlos Alcantar
, CA. 94010 Phone: +1 415 376 3314 / car...@race.com / http://www.race.com From: NANOG <nanog-boun...@nanog.org> on behalf of Blake Hudson <bl...@ispn.net> Sent: Tuesday, May 3, 2016 3:23:42 PM To: nanog@nanog.org Subject: Re: BGP peerin

Re: BGP peering strategies for smaller routers

2016-05-03 Thread Blake Hudson
Łukasz Bromirski wrote on 5/3/2016 4:13 PM: On 03 May 2016, at 22:31, William Herrin wrote: On Tue, May 3, 2016 at 3:50 PM, Gustav Ulander wrote: Yes I can confirm that we also had the issue with the asr1001s. For us the router was fine

Re: BGP peering strategies for smaller routers

2016-05-03 Thread Nick Hilliard
William Herrin wrote: > I respectfully disagree. Sourcing more ram won't fix the next bit of > sloppiness with the software. Or the one after that. Once the manager > of that team starts to accept poor code quality, the only thing with a > chance of fixing it is strong customer push-back. You

Re: BGP peering strategies for smaller routers

2016-05-03 Thread William Herrin
On Tue, May 3, 2016 at 5:13 PM, Łukasz Bromirski wrote: > On 03 May 2016, at 22:31, William Herrin wrote: >> IMO, you should not accept that answer from the TAC. An IOS release >> that crashes with two 600k BGP feeds in 4 gigs of RAM is badly >> defective. >

Re: BGP peering strategies for smaller routers

2016-05-03 Thread Łukasz Bromirski
> On 03 May 2016, at 22:31, William Herrin wrote: > > On Tue, May 3, 2016 at 3:50 PM, Gustav Ulander > wrote: >> Yes I can confirm that we also had the issue with the asr1001s. >> For us the router was fine until we upgraded it. When >> we

Re: BGP peering strategies for smaller routers

2016-05-03 Thread Nick Hilliard
William Herrin wrote: > IMO, you should not accept that answer from the TAC. An IOS release > that crashes with two 600k BGP feeds in 4 gigs of RAM is badly > defective. I suspect the time the OP would spend raging down the phone would be better spent sourcing a third party memory upgrade to 8G

Re: BGP peering strategies for smaller routers

2016-05-03 Thread William Herrin
On Tue, May 3, 2016 at 3:50 PM, Gustav Ulander wrote: > Yes I can confirm that we also had the issue with the asr1001s. > For us the router was fine until we upgraded it. When > we rebooted it after the upgrade it ran out of memory > when populating 2 full feeds.

Re: BGP peering strategies for smaller routers

2016-05-03 Thread William Herrin
On Mon, May 2, 2016 at 10:35 PM, Eric Sabotta wrote: > I just did this with a ASR1001. I had to upgrade it to 8gb of ram > (I got the real Cisco stuff for ~ $500). Before the router would > crash when loading the tables. Hi Eric, Something very fishy there because: >

RE: BGP peering strategies for smaller routers

2016-05-03 Thread Eric Sabotta
Mike, I just did this with a ASR1001. I had to upgrade it to 8gb of ram (I got the real Cisco stuff for ~ $500). Before the router would crash when loading the tables. Right now, I have full tables from two providers: router1#show ip bgp summary BGP router identifier 192.55.82.2, local AS

Re: BGP peering strategies for smaller routers

2016-05-03 Thread William Herrin
On Mon, May 2, 2016 at 3:07 PM, Mike wrote: > I have an ASR1000 router with 4gb of ram. The specs say I can get '1 > million routes' on it, but as far as I have been advised, a full table of > internet routes numbers more than 530k by itself, so taking 2 full

Re: BGP peering strategies for smaller routers

2016-05-03 Thread Ken Chase
got a quagga router in my life where bgpd+zebra takes up 1gig for 4.5 full tables. Rest of the OS easily lives in 1 gig (could probably be much less.) big-vendor solutions always seem much bloatier - same deal on power usage. just a data point. /kc -- Ken Chase - m...@sizone.org Toronto

Re: BGP peering strategies for smaller routers

2016-05-03 Thread Blake Hudson
Mike wrote on 5/2/2016 9:43 PM: On 05/02/2016 07:35 PM, Eric Sabotta wrote: Mike, I just did this with a ASR1001. I had to upgrade it to 8gb of ram (I got the real Cisco stuff for ~ $500). Before the router would crash when loading the tables. Right now, I have full tables from two

Re: BGP peering strategies for smaller routers

2016-05-02 Thread Mark Tinka
On 2/May/16 22:32, Richard Hicks wrote: > Careful with the ASR1000 and full tables at 4GB. > > http://www.gossamer-threads.com/lists/cisco/nsp/180710 > > I recommend adding some third party RAM to get 16GB. It will be fine with 4GB of RAM provided the OP does not enable software redundancy.

Re: BGP peering strategies for smaller routers

2016-05-02 Thread Mike
On 05/02/2016 07:35 PM, Eric Sabotta wrote: Mike, I just did this with a ASR1001. I had to upgrade it to 8gb of ram (I got the real Cisco stuff for ~ $500). Before the router would crash when loading the tables. Right now, I have full tables from two providers: router1#show ip bgp summary

Re: BGP peering strategies for smaller routers

2016-05-02 Thread Richard Hicks
Careful with the ASR1000 and full tables at 4GB. http://www.gossamer-threads.com/lists/cisco/nsp/180710 I recommend adding some third party RAM to get 16GB. On Mon, May 2, 2016 at 12:07 PM, Mike wrote: > Hello, > > I have an ASR1000 router with 4gb of ram.

Re: BGP peering strategies for smaller routers

2016-05-02 Thread Bob Evans
Rib or Fib for the million - thats the question - but in any event the following will most likely work for you. BTW, full table is now over 600K in size. 1) Choose one Transit and take their full table. (pick whatever reasons cost savings, bigger pipe, coin flip, etc.) 2) With the second transit

RE: BGP peering strategies for smaller routers

2016-05-02 Thread Tony Wicks
AM To: Mike <mike-na...@tiedyenetworks.com>; NANOG list <nanog@nanog.org> Subject: RE: BGP peering strategies for smaller routers Hello. When we was in a similar situation we opted for one transit provider to provide a default to us then we filtered on AS-HOPS so prefixes that was

Re: BGP peering strategies for smaller routers

2016-05-02 Thread Blake Hudson
Mike, the ASR1k series has several ESP options (ESP5, 10, 20, 40, 100, 200). Each ESP comes with a fixed amount of forwarding tcam which holds the forwarding information base (FIB). The ESP5 has 5MB of tcam can hold ~500k routes. The ESP10 has 10MB of tcam, so theoretically should hold roughly

RE: BGP peering strategies for smaller routers

2016-05-02 Thread Gustav Ulander
Hello. When we was in a similar situation we opted for one transit provider to provide a default to us then we filtered on AS-HOPS so prefixes that was more than 3 hops away was denied. This way we got the ones that where closest to us and that where more likely to matter. Prefixes that’s

Re: BGP peering strategies for smaller routers

2016-05-02 Thread lincoln dale
> > You have to keep in mind there are two pools of memory on the router. There's actually three. 1. Prefix (path) via BGP: "show ip bgp ". BGP will select the 'best' BGP path (can be multiple if ECMP) and send that through to the RIB. 2. RIB. "show ip route ". routing table will show the

Re: BGP peering strategies for smaller routers

2016-05-02 Thread Mark Tinka
On 2/May/16 21:07, Mike wrote: > Hello, > > I have an ASR1000 router with 4gb of ram. The specs say I can get > '1 million routes' on it, but as far as I have been advised, a full > table of internet routes numbers more than 530k by itself, so taking 2 > full tables seems to be out of the

Re: BGP peering strategies for smaller routers

2016-05-02 Thread James Milko
On Mon, May 2, 2016 at 3:07 PM, Mike wrote: > Hello, > > I have an ASR1000 router with 4gb of ram. The specs say I can get '1 > million routes' on it, but as far as I have been advised, a full table of > internet routes numbers more than 530k by itself, so