June 2020 - Test - lists.nanog.org

Re: [c-nsp] Devil's Advocate - Segment Routing, Why?
by Mark Tinka 19 Jun '20

19 Jun '20

I think it's less about just the forwarding chips and more about an entire solution that someone can go and buy without having to fiddle with it. You remember the saying, "Gone are the days when men were men and wrote their own drivers"? Well, running a network is a full-time job, without having to learn how to code for hardware and protocols. There are many start-ups that are working off of commodity chips and commodity face plates. Building software for those disparate hardware systems, and then developing the software so that it can be used in commercial deployments is non-trivial. That is the leverage Cisco, Juniper, Nokia... even Huawei, have, and they won't let us forget it. Then again, if one's vision is bold enough, they could play the long game, start now, patiently build, and then come at us in 8 or so years. Because the market, surely, can't continue at the rate we are currently going. Everything else around us is dropping in price and revenue, and yet traditional routing and switching equipment continues to stay the same, if not increase. That's broken!` Mark. On 19/Jun/20 13:25, Robert Raszuk wrote: > But talking about commodity isn't this mainly Broadcom ? And is there > single chip there which does not support line rate IP ? Or is there any > chip which supports MPLS and cost less then IP/MPLS one ? > > On Fri, Jun 19, 2020 at 1:22 PM Benny Lyne Amorsen via cisco-nsp < > cisco-nsp(a)puck.nether.net> wrote: > >> >> >> ---------- Forwarded message ---------- >> From: Benny Lyne Amorsen <benny+usenet(a)amorsen.dk> >> To: cisco-nsp(a)puck.nether.net >> Cc: >> Bcc: >> Date: Fri, 19 Jun 2020 13:12:06 +0200 >> Subject: Re: [c-nsp] Devil's Advocate - Segment Routing, Why? >> Saku Ytti <saku(a)ytti.fi> writes: >> >>> This is simply not fundamentally true, it may be true due to market >>> perversion. But give student homework to design label switching chip >>> and IPv6 switching chip, and you'll use less silicon for the label >>> switching chip. And of course you spend less overhead on the tunnel. >> What you say is obviously true. >> >> However, no one AFAIK makes an MPLS switch at prices comparable to basic >> layer 3 IPv6 switches. You can argue that it is a market failure as much >> as you want, but I can only buy what is on the market. According to the >> market, MPLS is strictly Service Provider, with the accompanying Service >> Provider markup (and then ridiculous discounts to make the prices seem >> reasonable). Enterprise and datacenter are not generally using MPLS, and >> I can only look on in envy at the prices of their equipment. >> >> There is room for a startup to rethink the service provider market by >> using commodity enterprise equipment. Right now that means dumping MPLS, >> since that is only available (if at all) at the most expensive license >> level. Meanwhile you can get get low-scale BGPv6 and line-speed GRE with >> commodity hardware without extra licenses. >> >> I am not saying that it will be easy to manage such a network, the >> tooling for MPLS is vastly superior. I am merely saying that with just a >> simple IPv6-to-the-edge network you can deliver similar services to an >> MPLS-to-the-edge network at lower cost, if you can figure out how to >> build the tooling. >> >> Per-packet overhead is hefty. Is that a problem today? >> >> >> >> >> ---------- Forwarded message ---------- >> From: Benny Lyne Amorsen via cisco-nsp <cisco-nsp(a)puck.nether.net> >> To: cisco-nsp(a)puck.nether.net >> Cc: >> Bcc: >> Date: Fri, 19 Jun 2020 13:12:06 +0200 >> Subject: Re: [c-nsp] Devil's Advocate - Segment Routing, Why? >> _______________________________________________ >> cisco-nsp mailing list cisco-nsp(a)puck.nether.net >> https://puck.nether.net/mailman/listinfo/cisco-nsp >> archive at http://puck.nether.net/pipermail/cisco-nsp/ >> > _______________________________________________ > cisco-nsp mailing list cisco-nsp(a)puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > .

3 7

Re: [c-nsp] Devil's Advocate - Segment Routing, Why?
by Mark Tinka 19 Jun '20

19 Jun '20

On 19/Jun/20 13:11, Saku Ytti wrote: > ASR9k also has low and high scale cards, we buy the low scale, even > for edge. But even low scale is pretty high scale in this context. You're probably referring to the TR vs. SE line cards, yes? We would also buy TR line cards for high-touch use-cases, because, as you say, that is pretty high scale as well, already :-). I think the SE line cards are meant for high-capacity BNG terminations in a single chassis, per line card. But with most IP traffic a network is carrying being best-effort and capacity available all over the place, what's the point anymore? > > I think there would be market for on-chip only LSR/core cards. > Ultimately if you design for that day1, it won't add lot of costs to > you. Yes the BOM difference may not be that great, because ultimately > silicon is cheap and costs are in NRE. But the on-chip only cards > would have bit more ports and they'd have better availability due to > less component failures. > I would fight very hard for us buy such cards in core, if vendor would > offer them. Same here. For now, we are exploring the PTX1000/10002 machinery. I know fixed form factor boxes for a core are a bit strange, but looking at how far the tech has come, I'm feeling a lot more bullish about having a core box that isn't redundant in control planes, data planes, and all the rest. Just power supplies :-). A lot of money to be saved if the idea works. > Like the trio-in-pci full open, I think this is just marketing > failure. Vendors are wearing their DC glasses and don't see anything > else. While the big-name DC are lost cause, AMZN employs more chip > designers than JNPR, matter of time before JNPR loses amzn edge too to > internal amzn product. > > Someone with bit bolder vision on what the market could be, may have > real opportunity here. This is what I've been telling the vendors since about 2017, both IP and Transport. It's only a matter of time before the level of development happening in the cloud + content houses far surpasses what the vendors are doing, if not already. Why spend all your time, energy and resources on a market that isn't going to find use for your NRE, and can probably out-code and out-research you with one hand tied behind their back, any day? The only reason they aren't building their own core routers yet is because that's an area where they can still afford to offload development time to the vendors. The edge is where they need to badly optimize, and they will do it a lot more efficiently than the vendors can, in time, if not already. When I saw one cloud provider present their idea on collapsing an entire DWDM line card into an optic that they can code for and stick into a server, I saw the DWDM's vendor's hearts sink right across the table where I sat. This was 3 years ago. The vendors need, as you say, someone with a bold enough vision to pivot the tradition. Mark.

2 1

Re: AS hijacking (Philosophy, rants, GeoMind)
by Sriram, Kotikalapudi (Fed) 18 Jun '20

18 Jun '20

Mike, >As our canned Email stated, AS2 (and many low digit AS') get hijacked and >often go on to hijack someone's prefix. AS2 (proper) is rarely changed and >the chances of an actual prefix hijack from it is extremely low. > >So as I've asked our peers, I'll ask here: What is expected of us to be good >"Net Citizens" with these hijacks? Thoughts on AS hijack prevention: With RPKI-based route origin validation (ROV), it turns out that incremental solution for prefix hijacking is also an incremental solution for AS hijacking. For example -- assuming Invalid routes will be dropped -- if 70% of the announced prefixes are protected by ROAs, then those 70% prefixes cannot be hijacked with a hijacked AS. (Note: An exception to this is -- a deliberate hijacker can still perform what is called forged-origin hijack [1], i.e., the attacker matches the hijacked prefix with a hijacked AS such that they both belong to the same ROA.) So, the community should keep pushing ahead with ROA and RPKI-based ROV deployments to achieve 100% ROA coverage for announced prefixes and also 100% dropping of Invalid. The above can also be said about “trusted” IRR-based (or IRR+RPKI based) ROV [1]. However, priority should be given to speedup the RPKI/ROA deployment towards full adoption. FYI... Worldwide ROA coverage is currently at 20% for globally routed prefixes. https://rpki-monitor.antd.nist.gov/ Security guidance regarding route objects in IRR, ROAs in RPKI, and ROV deployment can be found here: [1] “Resilient Interdomain Traffic Exchange: BGP Security and DDoS Mitigation,” NIST Special Publication, NIST SP 800-189, December 2019. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-189.pdf Also, look up: [2] MANRS: https://www.manrs.org/ Thank you. Regards, Sriram

1 0

Network card with relay in case of power failure
by Dovid Bender 18 Jun '20

18 Jun '20

Hi, I am sorry if this is off topic.I was once demoed a network device that had two interfaces. The traffic would go through the device. If there was a power cut or some other malfunction there would be a relay that would physically bridge the two network interfaces so the traffic would flow as if it was just a network cable. Is anyone aware of such a network card or device? TIA.

8 9

Quality of the internet
by Dovid Bender 18 Jun '20

18 Jun '20

Hi, My 9-5 is working for a VoIP provider. When we started in 2006 we had a lot of issues with the quality of the internet in eastern europe and central Asia. It was not rare for us to have to play around with routing to get the quality that we needed. In a review of tickets for the last two years it seems as if we barely do any of that these days. Rarely do we get a quality complaint that comes back to an issue where a carrier or ISP dropping or mangling packets. Has anyone else observed this as well?

8 12

Router Suggestions
by Colton Conor 18 Jun '20

18 Jun '20

For around $11,000 right now, you can get a brand new Juniper MX204 router. Alternatively, you can get a used MX240 / MX480 with quad power supplies, redundant quad core RE's, and 2 16X10G MIC cards for around $12,000. My question, is there anything else worth looking at in this price range / port configuration? Open to both new and used options. Looking to take full BGP routes.

14 23

Mikrotik RPKI Testing
by Mike Hammett 18 Jun '20

18 Jun '20

I noticed that Mikrotik has added RPKI into their very much beta v7 branch. I would like to ask those of you that know RPKI well to check it out and offer Mikrotik feedback on what they've done right\wrong\broken. Thanks. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com

9 12

Hurricane Electric has reached 0 RPKI INVALIDs in our routing table
by Mike Leber 18 Jun '20

18 Jun '20

I'm pleased to announce Hurricane Electric has completed our RPKI INVALID filtering project and we now have 0 RPKI INVALIDs in our routing table. Hurricane Electric has 29021 BGP sessions with 22109 prefix filters with 7191 networks directly and 8239 networks including Internet exchanges. We filter all BGP sessions using prefix filters based on IRR and RPKI. These prefix filters are updated automatically both through a system of daily updates and real time updates to prevent RPKI INVALID routes from being carried in our routing table.

11 18

Re: [c-nsp] Devil's Advocate - Segment Routing, Why?
by Mark Tinka 18 Jun '20

18 Jun '20

On 18/Jun/20 02:32, Phil Bedard wrote: > I look at the basic SR via IGP extensions like VPLS vs. EVPN. If we had a way to go back in history I'm not sure anyone would have said VPLS was a good idea vs. EVPN. > > There were reasons back in the day why something like SR wasn't done. The thought of global MPLS labels scared people and source routing was also evil. So LDP was created to distribute labels hop by hop, while still relying 100% on the IGP to do so. It kind of defies common sense when you look at it now, but there were supposedly good reasons for it back then. > > SR-MPLS on an existing device supporting MPLS forwarding is a control-plane change, meaning almost any device could support SR-MPLS. > > SR is meant to be data plane agnostic, the SID is just an identifier. Most support MPLS, some support IPv6. Fair enough. There's still a whole IGP mess to sort out though, not to mention many years of field experience to bake in. Mark.

1 0

Client-side information gathering tool
by Matt Harris 17 Jun '20

17 Jun '20

Hey folks, I was hoping maybe someone could point me in a useful direction here. I'm looking into software tools (ideally, they'd support Windows, Mac, and Linux, though Windows is perhaps the only critical one) that can be sent over to random users with varying (mostly very little) knowledge of how the internet works to gather a bunch of data that they can then provide to us to help identify connectivity issues between the client and a chosen endpoint. IPv4 and IPv6 support are requirements. I've got a lot of clients with VPN connections of varying sorts running on internet connections of often very low quality, and sometimes even in places where reasonable quality doesn't seem to even exist. Right now, when these users complain, this often means my support folks get to walk them through downloading winmtr and running that as well as other command line tools to gather a bunch of other information about their computer, its connection to their LAN, their LAN configuration as best as we can tell, and their connection to the greater internet. This is somewhat cumbersome of a process though. If we could send them something they could click on and then copy/paste out of or otherwise direct the data to us, that would save a fair bit of time and also be a lot less patience-grating on the part of our clients. Any links to potentially useful tools (commercial or free are both fine) would be appreciated. The main goal is getting lots of relevant information to us without having to walk an end-user through lots of steps to do so. The more relevant data, the better. Thanks, Matt Matt Harris|Infrastructure Lead Engineer 816-256-5446|Direct Looking for something? Helpdesk Portal|Email Support|Billing Portal We build and deliver end-to-end IT solutions.

2 1