Re: Weekly Routing Table Report
John Kristoff wrote: If you can't accept the following principle of the End to End argument: I think it is better to stick with what the paper refers to them e2e as, an argument. The e2e paper is by far one of the closest things we have to network canon and its reasoning is exceptionally simple and compelling. Yet, these are arguments, not laws. Proof of the argument seems to be easy, see slide 11 of http://www.ocw.titech.ac.jp/index.php?module=General=DownLoad=201904901-2662-0-35.pdf=cal=201904901 Even the original authors have revisited and questioned the original ideas. Extension of the argument to intermediate systems (to make the argument directly applicable to protocols used within a network such as routing protocols) and modern layering (the original paper is skeptical to layering stating "it is fashionable these days to talk about layered communication protocols" obviously because OSI layering popular at that time is terrible) should be useful. Note, I'm not agreeing or disagreeing with any particular position about multihoming in this thread, Can you agree that, by applying the argument to function of multihoming, we can get the following: multihoming can completely and correctly be implemented only with the knowledge and help of the application standing at the end points of the communication system. Therefore, providing multihoming as a feature of the communication system itself is not possible. then, the constructive question to ask is: with the knowledge and help of the application standing at the end points of the communication system, can multihoming completely and correctly be implemented? Once the question is asked, it is not very difficult to construct a multihoming architecture to show the answer is "yes". With such questions, the principle is very powerful tool to know the right direction to perform research. > just trying to argue that the e2e paper is a lot more nuanced than is often presented in debates especially since it has often been used to support opposing views. :-) The most serious problem with such debates is that people just do not read the original paper: http://groups.csail.mit.edu/ana/Publications/PubPDFs/End-to-End%20Arguments%20in%20System%20Design.pdf and have their own random definitions on the principle, which makes the debates completely meaningless. There are a lot of proofs saying the principle is invalid, using their own definitions of the principle. Masataka Ohta
Re: BGP Enabled transit in Chicago (River North) and equipment recommendation
On 9/3/2019 1:54 PM, Florian Brandstetter wrote: 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. I'm going based on actual tests done when the ERL came out in 2012. While its cores are anemic by today's standards, it handled multiple full tables fine back then. Since then, the ERs have stopped using Quagga/Zebra and now use ZebOS (which is also used in several other commercial products). It's a bit faster and smaller. In today's world, its tight, but it will still work. 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. As I pointed out, its the dirt cheap option. Better option is the ER4 and later which is better suited to the increased table size. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org/ http://www.ahbl.org
Re: BGP Enabled transit in Chicago (River North) and equipment recommendation
I will note that Comcast will do BGP on their enterprise fiber circuits. Comcast DIA (which they call EDI) comes in increments of 1M up to 10M, then 10M up to 100M, etc. So you could get 10M or 80M (not sure if "10MB/Sec" means 10Mbps or 80MBps) and do BGP over that, if it's available. RCN is likely similar but I'm not as familiar with their offerings. On Tue, Sep 3, 2019 at 3:35 PM Brielle wrote: > On 9/3/2019 12:19 PM, Matt Harris wrote: > > But even the higher-end Ubiquiti EdgeRouter series products can handle > > full tables if you understand and accept their limitations in doing so > > if budget is a huge concern but you still need to take full tables. > > As long as you stick with the 1.10.10 series of firmware, the EdgeRouter > series is pretty stable. I run an EdgeRouter Infinity (8 x 10G SFP+) at > home with both IPv4 and IPv6 BGP feeds on a CenturyLink Fiber+ connection. > > You can get the original EdgeRouter Lite for sub $100 and it will have > no problem taking a full feed for both v4 and v6... However, better > choice is the EdgeRouter 4, which is a bit newer and much faster. > > There's also the ER6P if you need something with more ports, or even the > ER12/12P if you want something with a built in network switch. Just > avoid the budget oriented ERX and ER10X which lack the RAM. > > All of the ERs are low power consumption and Linux based with a > Vyatta/VyOS/Juniper-like CLI, so pretty easy to work with. > > (I do Ubiquiti deployments, so can answer a lot of questions anyone > might have). > > -- > Brielle Bruns > The Summit Open Source Development Group > http://www.sosdg.org/ http://www.ahbl.org >
Re: BGP Enabled transit in Chicago (River North) and equipment recommendation
On 9/3/2019 12:19 PM, Matt Harris wrote: But even the higher-end Ubiquiti EdgeRouter series products can handle full tables if you understand and accept their limitations in doing so if budget is a huge concern but you still need to take full tables. As long as you stick with the 1.10.10 series of firmware, the EdgeRouter series is pretty stable. I run an EdgeRouter Infinity (8 x 10G SFP+) at home with both IPv4 and IPv6 BGP feeds on a CenturyLink Fiber+ connection. You can get the original EdgeRouter Lite for sub $100 and it will have no problem taking a full feed for both v4 and v6... However, better choice is the EdgeRouter 4, which is a bit newer and much faster. There's also the ER6P if you need something with more ports, or even the ER12/12P if you want something with a built in network switch. Just avoid the budget oriented ERX and ER10X which lack the RAM. All of the ERs are low power consumption and Linux based with a Vyatta/VyOS/Juniper-like CLI, so pretty easy to work with. (I do Ubiquiti deployments, so can answer a lot of questions anyone might have). -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org/ http://www.ahbl.org
Re: BGP Enabled transit in Chicago (River North) and equipment recommendation
I’ve had BGP from comcast business in River North before, not sure what their minimum bandwidth is for that. Tunnels may be simplest at that bandwidth level. > On Sep 3, 2019, at 12:52 PM, Florian Brandstetter via NANOG > wrote: > > Might be worth to consider running a software router on that scale with > perhaps some cheap quad-port GbE PCIe NICs. BIRD would be the BGP daemon to > go, or FRRouting if you want an integrated shell. Hardware routers for 100 > Mbit egress seem a bit overpowered, however, as scaleable you want to go, > some Ubiquiti routers might be a cheap option. > > As for transit, have you considered a redundant tunnel-based solution > instead? You can run that transparently on top of your RCN connection, with > negligible costs for your commit and no additional connection fees. > > On Sep. 3 2019, at 6:17 pm, ADNS NetBSD List Subscriber > wrote: > I have a need for a BGP enabled connection in the River North section of > Chicago. We have a small number of IP blocks that we want to use. Currently, > we have some equipment at 350 E. Cermak (Steadfast Networks) and are looking > at downsizing and bringing stuff > in-house. Our bandwidth requirements are miniscule (10MB/Sec is fine). > > I know RCN offers business cable-modem service but probably not BGP. > > Also, we’d like to ditch our 3640 router in favor of a smaller “desktop” size > router, but none of them seem to do BGP (not surprising). Any > recommendations on hardware would be welcome as well >
Re: BGP Enabled transit in Chicago (River North) and equipment recommendation
On Tue, Sep 3, 2019 at 12:44 PM ADNS NetBSD List Subscriber wrote: > > Also, we’d like to ditch our 3640 router in favor of a smaller “desktop” > size router, but none of them seem to do BGP (not surprising). Any > recommendations on hardware would be welcome as well > I can think of lots of smaller, even desktop sized routers that have no problem doing BGP assuming you're only taking a single transit circuit and only accepting a default route from your upstream provider. Ubiquiti's tiniest EdgeRouters which cost around $100 will do BGP just fine under those circumstances if you're not pushing tons of traffic or pps. If you want something a little nicer/fancier, you can get a Juniper SRX (probably a 300, 320, or 345 depending on how much bandwidth you're going to use). If you want to run multiple transits and take full tables, then at that point I'd recommend going a bit bigger: maybe a Juniper MX or a Cisco ASR. But even the higher-end Ubiquiti EdgeRouter series products can handle full tables if you understand and accept their limitations in doing so if budget is a huge concern but you still need to take full tables. Take care, Matt
Re: BGP Enabled transit in Chicago (River North) and equipment recommendation
Might be worth to consider running a software router on that scale with perhaps some cheap quad-port GbE PCIe NICs. BIRD would be the BGP daemon to go, or FRRouting if you want an integrated shell. Hardware routers for 100 Mbit egress seem a bit overpowered, however, as scaleable you want to go, some Ubiquiti routers might be a cheap option. As for transit, have you considered a redundant tunnel-based solution instead? You can run that transparently on top of your RCN connection, with negligible costs for your commit and no additional connection fees. On Sep. 3 2019, at 6:17 pm, ADNS NetBSD List Subscriber wrote: > I have a need for a BGP enabled connection in the River North section of > Chicago. We have a small number of IP blocks that we want to use. Currently, > we have some equipment at 350 E. Cermak (Steadfast Networks) and are looking > at downsizing and bringing stuff > in-house. Our bandwidth requirements are miniscule (10MB/Sec is fine). > > I know RCN offers business cable-modem service but probably not BGP. > > Also, we’d like to ditch our 3640 router in favor of a smaller “desktop” size > router, but none of them seem to do BGP (not surprising). Any recommendations > on hardware would be welcome as well > > >
BGP Enabled transit in Chicago (River North) and equipment recommendation
I have a need for a BGP enabled connection in the River North section of Chicago. We have a small number of IP blocks that we want to use. Currently, we have some equipment at 350 E. Cermak (Steadfast Networks) and are looking at downsizing and bringing stuff in-house. Our bandwidth requirements are miniscule (10MB/Sec is fine). I know RCN offers business cable-modem service but probably not BGP. Also, we’d like to ditch our 3640 router in favor of a smaller “desktop” size router, but none of them seem to do BGP (not surprising). Any recommendations on hardware would be welcome as well
Re: Weekly Routing Table Report
On Sat, 31 Aug 2019 10:35:39 + Masataka Ohta wrote: > If you can't accept the following principle of the End to End > argument: I think it is better to stick with what the paper refers to them e2e as, an argument. The e2e paper is by far one of the closest things we have to network canon and its reasoning is exceptionally simple and compelling. Yet, these are arguments, not laws. Even the original authors have revisited and questioned the original ideas. The paper also says something about needing a great deal of system implementation detail to intelligently make the choice of where to place functions. I like pointing that out, because it seems people often miss this part in the paper where the only form of the word intelligence is ever used in the paper. Note, I'm not agreeing or disagreeing with any particular position about multihoming in this thread, just trying to argue that the e2e paper is a lot more nuanced than is often presented in debates especially since it has often been used to support opposing views. :-) John
RE: Mx204 alternative
> From: Saku Ytti > Sent: Tuesday, September 3, 2019 1:38 PM > > On Tue, 3 Sep 2019 at 15:10, wrote: > > > Not true. > > This is the case only in fixed pipelines. > > Also true in say MX Trio and ASR9k EZchip, I can't immediately think of > platform where ACL or QoS costs pps. ASR9k is TCAM for ACL so O(1) and MX > Trio is just fast enough to not affect pps performance. QoS isn't expensive at > all in lookup terms, just expensive to have the memory. > I'm afraid I'd have to disagree. adam
Re: Mx204 alternative
On Tue, 3 Sep 2019 at 15:10, wrote: > Not true. > This is the case only in fixed pipelines. Also true in say MX Trio and ASR9k EZchip, I can't immediately think of platform where ACL or QoS costs pps. ASR9k is TCAM for ACL so O(1) and MX Trio is just fast enough to not affect pps performance. QoS isn't expensive at all in lookup terms, just expensive to have the memory. -- ++ytti
RE: The Curious Case of 143.95.0.0/16
Very interesting story great work Ronald
-Original Message-
From: NANOG On Behalf Of Ronald F. Guilmette
Sent: Wednesday, August 28, 2019 2:27 AM
To: nanog@nanog.org
Subject: The Curious Case of 143.95.0.0/16
Fair Warning: Those of you not enamored of my long-winded exposés of various
remarkable oddities of the IPv4 address space may wish to click on the tiny
little wastebasket icons on your mail clients at this point. For the rest of
you, please read on. I think you may find the following story intriguing. It
contains at least a few surprising twists.
+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_
++_
Our story today consists of three acts.
Act 1 - It is Born
--
In mid-February of 1990 a new venture-capital backed company was formed in
Sunnyvale, California. In some ways it was no different than the hundreds or
thousands of hopeful high-tech startups that had been formed in Silicon Valley,
both before and since. It started with a hopeful dream that, in the end, just
didn't work out.
The founders of this company settled initially on a temporary placeholder
company name, XYZ Corporation:
https://drive.google.com/file/d/1CkDNKq4M1DQKuTxBBhlYxUNAjU2cvDnY/view
The mission of the company was to design and manufacture so-called X-Windows
terminals. These would be diskless workstations, complete with CPUs, color
(CRT) displays, graphics, memory, and an ethernet interface. The basic idea
what that such a diskless workstation could run the free X-Windows client
software, and that the system would be cheaper than ordinary PeeCees due to it
not having any hard drives or optical drives.
By some odd twist of fate, I myself was working in the same geographic area as
a software engineer at around the same time, but I worked for a different
Silicon Valley startup, just down the road from XYZ Corporation. And by a
rather remarkable coincidence, the company I worked for had exactly the same
goal and mission as the XYZ Corporation. The name of this other X-Windows
workstation startup was Network Computing Devices, or just "NCD"
for short.
Quite obviously, both companies were inherently "network-centric" and thus,
both requested and were granted blocks of IPv4 addresses. That wasn't at all
within my area of responsibility at NCD, so I don't know who actually issued
those blocks. My guess, based on published historical accounts, was that it
was most probably Dr. Jon Postel who assigned the blocks. I'm sure that
someone will correct me if I'm wrong.
Months passed, and eventually the founders of XYZ Corporation settled on
something they would use as a permanent replacement for their temporary
placeholder corporate name. They decided to call the thing Athenix, Inc.
Once they had settled on that name, they filed papers to update their records
with the California Secretary of State's office:
https://drive.google.com/file/d/1dUjsvSkzzdzUsIbIZCS7RF0afsI3uU0l/view
At some point, they also and likewise updated the ARIN WHOIS record for the
/16 block which had been assigned to them, on or about 1990-09-06, as was
appropriate to reflect their new permanent corporate identity:
https://pastebin.com/raw/YbH6zYrR
More time passed and eventually it became clear that the entire world was not
in fact breathlessly waiting for -two- companies to bring to market diskless
X-Windows workstations. In fact, as history now shows, market demand would not
support even one such company over the long term.
Thus it came to pass in the year 1993 that an all-too-familiar end-of-life
ritual played out once again in Silicon Valley. At Athenix, Inc. HQ in
Sunnyvale, the people were all let go, including the founders. The desks, the
chairs, the phones, the computers, and the tools were all sold at auction, with
the proceeds going to the preferred shareholders, i.e. the poor fools who had
put up all of the money for this now-failed venture in the first place, the
venture capitalists. Foremost among those in this instance, was the venerable
Menlo Park venture capital firm Kleiner Perkins.
I've confirmed this historical account of the rise and fall of the original
1990-vintage Athenix, Inc. in multiple phone and email exchanges with both the
original CEO of the original Athenix, Mr. Robert ("Bob") Garrow. lately of Los
Altos, California, and also the original CTO of the company, Mr. John Garman,
lately of Reno, Nevada.
Act 2 - Rebirth - The Athenix Phoenix
-
Fast forward fifteen years. On April 22, 2008 a pair of gentlemen in the
Commonwealth of Massachusetts elected to establish a new corporate entity
within the commonwealth. It's name would be Athenic, Inc.[1]
https://drive.google.com/file/d/1jYUqtgYprI4iyJkTT91-yRBYJt0c2ufF/view
https://drive.google.com/file/d/1mlVML8z7vzp7aeGmOK-3cWBBJeNBuThn/view
As you can see in the documents above, a certain Mr. Ofer Inbar and
Re: Mx204 alternative
On Mon, 2 Sep 2019, Hank Nussbacher wrote: What about handling LAG on 1Gb/sec links? That is a major showstopper if indeed it is missing: It works, but only about as well as anything else to do with 1G interfaces works on the MX204, and only then when you're running at least 18.1R3... show version |match "(model|junos):" Model: mx204 Junos: 18.1R3-S4.2 show interfaces ae0 |match speed Link-level type: Flexible-Ethernet, MTU: 1522, Speed: 40Gbps, show lacp interfaces ae0 |find protocol LACP protocol:Receive State Transmit State Mux State xe-0/1/4 Current Slow periodic Collecting distributing xe-0/1/5 Current Slow periodic Collecting distributing xe-0/1/6 Current Slow periodic Collecting distributing xe-0/1/7 Current Slow periodic Collecting distributing show chassis hardware |match SX Xcvr 4 REV 02 740-011613 - SFP-SX Xcvr 5 REV 02 740-011613 - SFP-SX Xcvr 6 REV 02 740-011613 - SFP-SX Xcvr 7 REV 02 740-011613 - SFP-SX show interfaces xe-0/1/4 |match speed Speed: 10Gbps, BPDU Error: None, Loop Detect PDU Error: None, Flow control: Disabled, Speed Configuration: 1G It just gets more bizarre from there. Don't run 1G on these boxes if you can find any way to avoid it. -Rob
Re: Weekly Routing Table Report
Did we all forget the size of the IPv6 table is nearing a milestone number in the DFZ? ;) > It is a 3-day weekend in the US. A good time to pause for a few minutes and consider what all of us accomplished together. > Pat yourselves on the back, raise a glass or whatever your personal traditions are, and bask in the glory of a job well done. Patrick W. Gilmore (Okay pat the back of your local network engineer if you forgot.) Aclamaciones, Cheers, À votre santé! > Nowadays boxes can easily take 5x the current 768 in > tcam and in control-plane -only sky is the limit, so for example there's no > need for any clever RR infrastructure designs anymore to hold all the routes > in your AS control-plane. > adamv0025 If you have an older router that can only handle x number of routes in TCAM less than the current number of routes; what software are you using to keep it default free? Or if the sky is really the limit, sell me your most or least expensive Tbps capable TCAM that will hold a routing table of 3M+ routes IPv4 and another 3M+ IPv6 without gimmicks or stipulations. (Low or high number of interfaces, small or god-sized box.) Let me know why you like what you have, or what you want to have. Be thankful for your network. What's in your rack? Good Luck On Sun, Sep 1, 2019 at 11:46 PM Masataka Ohta < mo...@necom830.hpcl.titech.ac.jp> wrote: > Scott Weeks wrote: > > > Yes, my apologies for no reference. Further, I have no URL to > > point to as I read the book. (actual book; no e-something) > > > > Here's something: http://pouzinsociety.org > > as I can't find open access papers or something like that there, > let me stick to wikipedia. > > > Like the book, in the Wikipedia article you have to get through > > or skip the first part. In the book, that's the first 5 or so > > chapters. He just describes why, in his opinion, previous things > > have failed and the way he does it turns a lot of folks off. > > Another major misunderstanding of him is that he is not aware that > domain name with MX is application name and there are proposals > (though unnecessarily complicated) such as SRV to cover other > applications beyond SMTP. With SRV, non-default port numbers do not > have to be specified in URLs. > > So, we already have application names of domain names and mapping > mechanism between names and addresses/port_numers of DNS. > > E2E (end-to-end principle) is not relevant > > That someone can not recognize relevance between something and the > E2E principle does not mean much. > > IPv6 is/was a waste of time > > True, but, the reason is because IPv4 Internet with DNS, TCP > and NAT is good enough. > > That TCP identifies connections only by single source and destination > addresses is certainly a problem. But, the least painful solution > is to extend TCP to be able to identify connections by multiple > addresses. > > Properly designed NAT can save IP addresses a lot still keeping the > E2E transparency. > > > The RINA's fundamental principles are that computer > > networking is just Inter-Process Communication or IPC, > > That is a too much computer centric view not very > applicable to communications involving human beings, > where the E2E argument must often be applied to human > beings (true end) behind applications (tentative end > in a computer). > > Masataka Ohta >
RE: Mx204 alternative
> From: Saku Ytti > Sent: Tuesday, September 3, 2019 9:55 AM > > On Tue, 3 Sep 2019 at 10:27, Łukasz Bromirski wrote: > > > 64B traffic simply doesn’t happen apart from DDoS scenarios, so why > > bother at all? Customers anyway want to use dedicated > > > And like you said, QoS and filters usually have 0 pps cost. > Not true. This is the case only in fixed pipelines. adam
Re: Mx204 alternative
On Tue, 3 Sep 2019 at 10:27, Łukasz Bromirski wrote: > 64B traffic simply doesn’t happen apart from DDoS scenarios, so > why bother at all? Customers anyway want to use dedicated ACK. And as such, you're not going to get DDoS on all ports at the same time. So you just need to have enough ports on a chip and even very high average packet size, is more than enough. And if you absolutely need 64B on every port, that's easy, just put putty on the remaining ports, boom. The problem is when you rock 1 chip per port and you don't get 64B. But if it's 8, 16, 32 ports per chip, 64B is simply not needed. And like you said, QoS and filters usually have 0 pps cost. Only feature that typically has pps cost is uRPF which is not really needed for anything. -- ++ytti
Re: Mx204 alternative
Adam, > On 2 Sep 2019, at 19:42, adamv0...@netconsultings.com wrote: > > You nailed it, > Actually very few line-cards or fabric-less boxes with (run to completion > vendor chips) out there do line-rate at 64B packets nowadays. > -with the advent of 100G the "line-rate at 64B" is pretty much not a thing > anymore... > Something to consider, not because one wants to push 64B packets at > line-rate on all ports but because one needs to push IMIX through QOS or > filters... and the card/box might simply not deliver. But those are two completely different use cases. The fact that vendors (full disclosure - I work for Cisco) don’t want to optimize for 64 bytes forwarding is totally independent on how those architectures deal/manage to apply policies on the traffic. 64B traffic simply doesn’t happen apart from DDoS scenarios, so why bother at all? Customers anyway want to use dedicated anty-DDoS boxes, so apart from synthetic performance testing, pushing the architecture to be able to forward couple of mpps more just to cover the “64B” scenario means $ (sometimes $$$) just to satisfy requirement that’s usually simply not there. In other words, the fact that given architecture can’t forward "wire-rate" of 64B traffic doesn’t mean that it can’t apply QoS for IMIX pattern at wire-speed. Forwarding engine is usually different part of hardware than services, more often than not decisions are totally independent to speed up processing. -- Łukasz Bromirski CCIE R/SP #15929, CCDE #2012::17, PGP Key ID: 0xFD077F6A
