EdgeOS was forked and employees were poached from Vyatta before it was purchased by Broadcom, when it was open source. I think a few things came down from VyOS after that, but not many.
On Mon, Jul 3, 2017 at 9:28 PM, Hugo Slabbert <h...@slabnet.com> wrote: > > On Mon 2017-Jul-03 19:26:17 -0500, Josh Reynolds <j...@kyneticwifi.com> > wrote: > >> On Jul 3, 2017 7:23 PM, "Josh Reynolds" <j...@kyneticwifi.com> wrote: >> >>> Specs... >>> >>> >>> - MIPS64 16 Core 1.8 GHz >>> - 16 GB DDR4 RAM >>> - 8 MB NOR Flash 4 GB eMMC NAND Flash >>> - Data Ports: (1) RJ45 Serial Port, (8) SFP+ Ports (1) RJ45 Gigabit >>> Ethernet Port >>> - 2 hotswap power supplies >>> >>> >>> No LACP. ECMP is currently broken. MPLS/VPLS is currently broken and not >>> done in hardware - this may eventually change. As far as the other stuff, >>> "telemetry" etc - no. >>> >>> As far as BGP crunching, plenty of routes, etc - it would easily and >>> happily be fine with that. >>> >>> As far as automation, it's a JunOS-like CLI originally based on vyatta, >>> which AT&T now owns - and one of the main reasons is it's scriptability, >>> use of Ansible and other tools right on the device, python, etc. > > > Technically I believe it's based on VyOS rather than Vyatta. Same base, but > just delineating that VyOS is open source and I don't believe AT&T wields > any control over it. > >>> >>> - Josh >>> > > -- > Hugo Slabbert | email, xmpp/jabber: h...@slabnet.com > pgp key: B178313E | also on Signal > > >>> On Jul 3, 2017 2:09 PM, "Job Snijders" <j...@instituut.net> wrote: >>> >>>> Dear NANOG, >>>> >>>> Some friends of mine are operating a nonprofit (on shoe string) and >>>> looking >>>> to connect some CDN caches to an IX fabric. A BGP speaking device is >>>> needed >>>> between the caches and the BGP peers connected to the fabric. The BGP >>>> speaker is needed to present the peers on the IX with a unified view of >>>> the >>>> assemblage of CDN nodes. >>>> >>>> I was wondering whether anyone was experience with the "EdgeRouter >>>> Infinity >>>> XG" device, specifically in the role of a simple peering router for a >>>> couple of tens of thousands of routes. (I'd point default to the left >>>> and >>>> take just the on-net routes on the right to reduce the table size >>>> requirement). >>>> >>>> I hope the device can do at least 2xLACP trunks, has a sizable FIB, is >>>> automatable (supports idempotency), can forward IMIX at line-rate, >>>> *flow, >>>> and exposes some telemetry via SNMP. >>>> >>>> Any note sharing would be appreciated! >>>> >>>> Kind regards, >>>> >>>> Job >>>> >>> >