Re: BGP Enabled transit in Chicago (River North) and equipment recommendation
Ubiquiti's EdgeRouter Lite is equipped with 512 MiB of DDR2 memory, of which after startup, roughly 491 MiB can be utilized. 119 MiB of the remaining memory are allocated by the base of the router already, which leaves you with a remainder of 372 MiB memory. Memory usage depends on the architecture for objects, for example there's a large difference between x86 and x86_64, since on x86_64, the compiler will generally use 64bit boundaries to be faster; the ERL runs on a MIPS64 architecture, which will have a similar trade-off. To get to the point, let's have a quick look at the components using memory: bgpd, zebra, kernel. Roughly 180 MiB of memory are required to keep a single full table in bgpd alone, leaving you with 192 MiB of free memory. Accounting further, zebra will eat at least another 100 MiB for exporting the BGP RIB to the Kernel (FIB), leaving you with 100 MiB. At this point, you have a mere 92 MiB left for fitting the routes into the kernel, and to leave room for RX buff ers on sockets. I don't see full tables happening from a memory perspective on the EdgeRouter Lite, you would want to look at something with at least 2 GiB of memory to keep the whole system running smoothly, and when using Quagga and Zebra, that's still aimed rather low. FRRouting at this point uses 2 GiB for 4 full tables on an x86 system, without any magic attached. Having kept it unmentioned, the EdgeRouter Lite has a dual-core with 500 MHz, and surely your BGP updates processing isn't offloaded, hence you will pretty quickly kill the whole router when you flood it with a full table, unless you set very low queue sizes, which isn't really reliable though since you generally want BGP to converge fast - not after a period of 15 minutes with the CPU sitting on 100%. You might want to install something like OpenWRT (which I don't know the possibility of on an ERL), and run BIRD if you're tied to a low memory footprint, however, in a base vendor-generic setup of the ERL, it's beyond my understanding why one would even suggest running a full table on it.
Looking for Cloudfront clue
Can someone with routing/BGP/peering clue in AWS's Cloudfront, please contact me offlist? Thanks, Hank
Re: Cat 5 hurricane -- How are the Bahamas doing?
On Mon, 2 Sep 2019, Sean Donelan wrote: It is too early for damage assessments. BTC, local Bahama telecommunications company, is reporting widespread power outages, and intermittent mobile and wireline telephone service. The Abaco Islands in northern Bahamas seem to be taking the worst of it. Folks asking for updates on Bahamas. The simple answer is I'm not hearing any information out of the Bahamas, which is concerning in itself. My big secret how I do network outage reports is people send me the information. Usually, I get lots of random emails from network people about problems all over the U.S. and other places in the world. But Bahamas has gone very quiet.
Re: Cat 5 hurricane -- How are the Bahamas doing?
Things are bad in some places, fine in others. I can provide a more thorough update this evening. On Wed, Sep 4, 2019, 15:27 Sean Donelan wrote: > On Mon, 2 Sep 2019, Sean Donelan wrote: > > It is too early for damage assessments. BTC, local Bahama > telecommunications > > company, is reporting widespread power outages, and intermittent mobile > and > > wireline telephone service. The Abaco Islands in northern Bahamas seem > to be > > taking the worst of it. > > Folks asking for updates on Bahamas. The simple answer is I'm not hearing > any information out of the Bahamas, which is concerning in itself. > > > My big secret how I do network outage reports is people send me the > information. Usually, I get lots of random emails from network people > about problems all over the U.S. and other places in the world. But > Bahamas has gone very quiet. > >
Re: BGP Enabled transit in Chicago (River North) and equipment recommendation
They are obviously not running full tables on their 3640. I'd imagine a raspberry pi would have more BGP capability and throughput than a 3640, though I don't recommend doing that even as a joke. But an ERR would be fine if they're expecting nothing more than a slightly faster 3640 with maybe some extra features. On 9/3/19 3:54 PM, Florian Brandstetter via NANOG wrote: Ubiquiti's EdgeRouter Lite is equipped with 512 MiB of DDR2 memory, of which after startup, roughly 491 MiB can be utilized. 119 MiB of the remaining memory are allocated by the base of the router already, which leaves you with a remainder of 372 MiB memory. Memory usage depends on the architecture for objects, for example there's a large difference between x86 and x86_64, since on x86_64, the compiler will generally use 64bit boundaries to be faster; the ERL runs on a MIPS64 architecture, which will have a similar trade-off. To get to the point, let's have a quick look at the components using memory: bgpd, zebra, kernel. Roughly 180 MiB of memory are required to keep a single full table in bgpd alone, leaving you with 192 MiB of free memory. Accounting further, zebra will eat at least another 100 MiB for exporting the BGP RIB to the Kernel (FIB), leaving you with 100 MiB. At this point, you have a mere 92 MiB left for fitting the routes into the kernel, and to leave room for RX buffers on sockets. I don't see full tables happening from a memory perspective on the EdgeRouter Lite, you would want to look at something with at least 2 GiB of memory to keep the whole system running smoothly, and when using Quagga and Zebra, that's still aimed rather low. FRRouting at this point uses 2 GiB for 4 full tables on an x86 system, without any magic attached. Having kept it unmentioned, the EdgeRouter Lite has a dual-core with 500 MHz, and surely your BGP updates processing isn't offloaded, hence you will pretty quickly kill the whole router when you flood it with a full table, unless you set very low queue sizes, which isn't really reliable though since you generally want BGP to converge fast - not after a period of 15 minutes with the CPU sitting on 100%. You might want to install something like OpenWRT (which I don't know the possibility of on an ERL), and run BIRD if you're tied to a low memory footprint, however, in a base vendor-generic setup of the ERL, it's beyond my understanding why one would even suggest running a full table on it. Sent from Mailspring
Re: Cat 5 hurricane -- How are the Bahamas doing?
Bahamas are essentially flattened as per recent reports. Or in other words BAAD -- J. Hellenthal The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume. > On Sep 4, 2019, at 14:26, Sean Donelan wrote: > > On Mon, 2 Sep 2019, Sean Donelan wrote: >> It is too early for damage assessments. BTC, local Bahama >> telecommunications company, is reporting widespread power outages, and >> intermittent mobile and wireline telephone service. The Abaco Islands in >> northern Bahamas seem to be taking the worst of it. > > Folks asking for updates on Bahamas. The simple answer is I'm not hearing > any information out of the Bahamas, which is concerning in itself. > > > My big secret how I do network outage reports is people send me the > information. Usually, I get lots of random emails from network people about > problems all over the U.S. and other places in the world. But Bahamas has > gone very quiet. >
Art and Tech is madness
In SPRING a time when segment and routing had no mismatch, a time when isis and ospf ate a forbidden encap, all they had to do was forward bgp like its hot, but crazy flapping doesnt leave any real LDP without some real FSM check, My dynamic unnumbered neighbor. Suddenly, Out of order, an AS is overridden, we see frames dropping, we sniff a bit and it turns out, sfps are burning, we are in a place right now where ping and pong are jittery, their latency is tested, they cant strengthen their icmp bond with a warm bfd message, how can they keep everyone in ACK, safe from teardown and dampening, with this kind of ixp relationship??! but oh admin, we know forwarding works in its own mysterious ways. We are left with two non rfc compliant scavengers, bastard 802.1ah fools in a leaky yet shaped, buffer display of some runts and nimbles, and a giant too. They start their life of a packet, leaving one interface to a neighbor, from an adjacency to a peer, an endless loop, its a prefix hijack, but as they move from one stack to another, finding their way through a tunnel of memory failures and RMAs, one hell of an LSP ride, through firewall horrors and MTU mismatches, leaving behind, a sea of syslog messages and snmp alarms. Anyway, Their ttl expired and one funny access list abruptly denies them life, sending them to Null0, where they can be peacefully discarded. Thats what tech does to yeh
