Re: Weekly Routing Table Report
On 9/2/19 4:40 PM, Seth Mattinen wrote: > May the world come to an end if someone dares to have an independent > thought or shares original information that can't be backed up by at > least 50 crosschecked references. Actually, independent thought or original information is welcome to anyone with a brain, as long as the author shows his/her work such that it can be verified and reproduced by others. You don't need a ton of references to the work (and conclusions) of others if you do a complete job yourself. There is a reason for the joke publication _The Journal of Irreproducible Results_, started in 1955. So many "scientific" publications have this little tiny problem: no one can duplicate the work.
Re: Mx204 alternative
On 2019-09-02 8:07 p.m., Brandon Martin wrote: On 9/2/19 6:04 PM, Mark Tinka wrote: Like how about 8-16*100GE single Trio PCI card with no-questions asked, specification released, would there be a market? I like to think there would be. Oh my gosh this. Especially if the docs are truly public (i.e. available with single click-wrap "don't be an asshat" license or even something like GDFL) and not just under NDA, but honestly even if it's an NDA required as long as it's broadly available for issuance (no need to be a high-volume) Broadcom partner and allows the results of its use to be distributed as F/OSS software, I'm game. In light of the xeon cost benefit mentioned earlier, I don't know how this fits, but with enough pcie lanes going to an appropriate number of cores, Mellanox has dual port 100gbps and 200gbps ConnectX cards. Plunk four of those cards into a suitable chassis, you could conceivably have 8 ports by 100 or 200gbps. From their site, ConnectX-6 can do various smart offload and such. ConnectX has some sort of XDP Redirect capability, so may have eBPF hardware/software offload capability. Not sure. A commit back in December indicates 100Mpps on single port and 72Mpps on dual port depending upon how things are setup. Actual routing/switching actions at those rates might be challenging but for smaller shops with pipes not fully utilized, might be an entertaining evaluation. Raymond.
Re: Mx204 alternative
I'd like to register my interest as well. I think an open hardware platform will do a lot to move the industry forward. On Mon, Sep 2, 2019, 10:09 PM Brandon Martin wrote: > On 9/2/19 6:04 PM, Mark Tinka wrote: > >> Like how about 8-16*100GE single Trio PCI card with no-questions > >> asked, specification released, would there be a market? I like to > >> think there would be. > > I'd be down for this. > > > > Mark. > > Oh my gosh this. Especially if the docs are truly public (i.e. > available with single click-wrap "don't be an asshat" license or even > something like GDFL) and not just under NDA, but honestly even if it's > an NDA required as long as it's broadly available for issuance (no need > to be a high-volume) Broadcom partner and allows the results of its use > to be distributed as F/OSS software, I'm game. > > I kinda wonder if the culture at Broadcom has changed any since the > merger/acquisition with Avagao. Obviously in ye olde days, you wouldn't > even get the time of day from them unless you were wanting to commit to > a million or so in sales. > > I spread my interest (and professional practice) between SP networking, > industrial networking, industrial controls, and industrial computing > including hardware, so this is drool-level interest for me even if I > don't get to work on it directly. So much so that I've been wanting to > play with an FPGA platform for this sort of thing, but there's just no > compelling reason given that existing, openly-documented accelerated > NICs from e.g. Intel on high-end PC hardware can basically match the > performance of any reasonable-cost FPGA Ethernet switching system in > useful workloads. > -- > Brandon Martin >
Re: Weekly Routing Table Report
Seth Mattinen wrote: May the world come to an end if someone dares to have an independent thought or shares original information that can't be backed up by at least 50 crosschecked references. Unlike references to facts, references to thought are required when the thought is not purely original and derived from someone else's thought. As such, if the thought is really independent, no references necessary. Masataka Ohta
Re: Mx204 alternative
On 9/2/19 6:04 PM, Mark Tinka wrote: Like how about 8-16*100GE single Trio PCI card with no-questions asked, specification released, would there be a market? I like to think there would be. I'd be down for this. Mark. Oh my gosh this. Especially if the docs are truly public (i.e. available with single click-wrap "don't be an asshat" license or even something like GDFL) and not just under NDA, but honestly even if it's an NDA required as long as it's broadly available for issuance (no need to be a high-volume) Broadcom partner and allows the results of its use to be distributed as F/OSS software, I'm game. I kinda wonder if the culture at Broadcom has changed any since the merger/acquisition with Avagao. Obviously in ye olde days, you wouldn't even get the time of day from them unless you were wanting to commit to a million or so in sales. I spread my interest (and professional practice) between SP networking, industrial networking, industrial controls, and industrial computing including hardware, so this is drool-level interest for me even if I don't get to work on it directly. So much so that I've been wanting to play with an FPGA platform for this sort of thing, but there's just no compelling reason given that existing, openly-documented accelerated NICs from e.g. Intel on high-end PC hardware can basically match the performance of any reasonable-cost FPGA Ethernet switching system in useful workloads. -- Brandon Martin
Re: Mx204 alternative
On 8/Aug/19 14:20, Eric Kuhnke wrote: > I am not certain on the value of having 1GbE interfaces natively on a > $25k plus router in the year 2019. Pair the router with a nice 1RU > 1/10GbE switch installed directly next to it with full metro Ethernet > layer 2 feature set. > > Anything that needs a 1GbE inteface, attach it to that switch, give > the switch a single 10GbE port to the router, and create the 1Gbps on > the router as a subinterface. That's what we do for Metro-E rings that require 10Gbps to customers. Use an MX204 to upgrade the ring to 100Gbps, hand an ASR920 on one of the MX204 10Gbps ports, and feed 1Gbps customers from the Cisco. 10Gbps customers can enjoy the MX204. Mark.
Re: Mx204 alternative
On 9/Aug/19 08:06, Radu-Adrian Feurdean wrote: > 9001, while approaching EoL, can be a good solution if your needs are limited > : 8x10G + 20x1G, you should get it for a good price - refurbished. Although better than the MX80, those are in the, as we say in Africa, "the same WhatsApp group" :-). Mark.
Re: Mx204 alternative
On 2/Sep/19 10:28, Hank Nussbacher wrote: > > > What about handling LAG on 1Gb/sec links? That is a major showstopper > if indeed it is missing: > > https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/speed-gigether-options.html > > • On MX10003 and MX204 routers, rate selectability at PIC > level and port level does not support 1-Gbps speed. > • On MX10003 and MX204 routers, the interface name prefix > must be xe. > • On MX10003 and MX204 routers, even after configuring > 1-Gbps speed, the protocol continues to advertise the bandwidth as > 10-Gigabit Ethernet. > • On MX10003 and MX204 routers, Link Aggregation Group > (LAG) is supported on 10-Gbps speed only. It is not supported on > 1-Gbps speed. Well, that's not ideal at all. That said, in the Metro, we don't generally support LAG's toward customers because getting policing to work reliably on them is difficult. So we wouldn't hit this issue, although I can see how annoying it would be for networks that prefer to do this. Mark.
Re: Mx204 alternative
On 2/Sep/19 11:02, Aled Morris via NANOG wrote: > The forthcoming Juniper ACX700 sounds like a good fit for metro > Ethernet with 4x100G and 24x10G in a shallow 1U hardened form factor. Do you know what chip it's running? Mark.
Re: Mx204 alternative
Mark Tinka writes: > The MX80 and MX104 have no business being in any modern conversation > these days :-). Except for the other MX-80, of course, which are better than ever. https://en.wikipedia.org/wiki/MX-80 Bjørn
Re: Mx204 alternative
On 2/Sep/19 10:52, Brandon Martin wrote: > > I try to avoid them in customer-facing applications, too. And in > intra-network situations, I don't know why you'd be LAGging 1Gbps > links anymore. In the backbone, we moved away from LAG's to ECMP. The only places we run Layer 2 LAG's is on switch<=>router trunks (in the edge), and of course, on peering routers facing the exchange point. > > But yeah, MX204 and similar LCs on the chassis platforms have some > bizarre port usage/speed limitations. Juniper has a little web page > to validate your port configurations, but it still seems easy to hit > gotchas like this. You need to have regular lunches with your Juniper SE to get on top of this :-)... Mark.
Re: Mx204 alternative
On 8/Aug/19 06:46, Randy Carpenter wrote: > If you don't require redundant routing engines, there is nothing from > Juniper that will cost less and have the capacity you require. In > fact, there really aren't any cheaper MX options at all, other than > the kneecapped MX80 and MX104 variants. MX204 is really a nice box. I > only wish they had a redundant version. The MX80 and MX104 have no business being in any modern conversation these days :-). For what you could do with it, the MX204 is pretty neat. Juniper have never really considered the Metro in a serious way, because if they did, they'd have an MX204-1G (if you can call it that). They've lost plenty of ground to Cisco's ASR920 (and older MX3600X) on the back of this. Mark.
Re: Mx204 alternative
On 8/Aug/19 08:33, Baldur Norddahl wrote: > 45k? No no, the mx204 with enough license to do BGP is more like 20k - > 25k or less. It is actually quite cheap, so I doubt the OP will find > anything much cheaper without going used or do a software router. > > I feel it should be mentioned that a Linux box with 4x10G NIC and some > random switch as port expander also will be able to fulfil the > requirements and for a fraction of any other solution. Including the code maturity for BGP, IS-IS, OSPF and friends? Mark.
Re: Mx204 alternative
On 02/09/2019 11:16, Mark Tinka wrote: On 8/Aug/19 05:33, Brandon Martin wrote: MX204 is a very nice pizza box router for service providers. I'm not aware of anything quite like it in terms of having a mature control plane. I like the JunOS config language better than Cisco-style that most other folks use. The MX204 is pretty hard to beat. It fits well as a peering/transit router, as well as a Metro-E router where you need a 100Gbps ring to carry 10Gbps customers, as well as downstream cheaper routers that will do sub-10Gbps quite nicely. That said, at least for the Metro, I still believe a lighter version of the MX204, with dense 1Gbps capability, is still needed. Been asking since 2007. Mark. What about handling LAG on 1Gb/sec links? That is a major showstopper if indeed it is missing: https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/speed-gigether-options.html • On MX10003 and MX204 routers, rate selectability at PIC level and port level does not support 1-Gbps speed. • On MX10003 and MX204 routers, the interface name prefix must be xe. • On MX10003 and MX204 routers, even after configuring 1-Gbps speed, the protocol continues to advertise the bandwidth as 10-Gigabit Ethernet. • On MX10003 and MX204 routers, Link Aggregation Group (LAG) is supported on 10-Gbps speed only. It is not supported on 1-Gbps speed. -Hank
Re: Mx204 alternative
On 9/Aug/19 20:18, Forrest Christian (List Account) wrote: > > Assuming one can find a used mx204, what is the official juniper > licensing policy? They are too new... doubt you'll find any pre-owned units on sale. Mark.
Re: Mx204 alternative
On 2/Sep/19 10:28, Saku Ytti wrote: > I think the Baldur's proposal works for organisation with few and > highly skilled employees. But for larger organisation the CAPEX isn't > relevant, it's the OPEX that matters and managing that magic linux box > is going to be very OPEX heavy. Totally agreed. > Also XEON isn't cheap chip, Jericho/PE/Trio/Solar/FP all are cheaper, > significantly so. XEON does cover some segment of the market, but it's > not large one. Agreed as well. Years back, when we considered virtual routers on servers + a cheap Layer 2 switch to run a proper but inexpensive "small router", the servers always worked out more expensive to maintain over time. Mark.
Re: Mx204 alternative
On Mon, 2 Sep 2019 at 10:14, Mark Tinka wrote: > > > On 2/Sep/19 11:02, Aled Morris via NANOG wrote: > > The forthcoming Juniper ACX700 sounds like a good fit for metro > > Ethernet with 4x100G and 24x10G in a shallow 1U hardened form factor. > > Do you know what chip it's running? > Sorry I have no inside info, only what's been released publicly. Aled
Re: Mx204 alternative
On 8/Aug/19 05:33, Brandon Martin wrote: > > > MX204 is a very nice pizza box router for service providers. I'm not > aware of anything quite like it in terms of having a mature control > plane. I like the JunOS config language better than Cisco-style that > most other folks use. The MX204 is pretty hard to beat. It fits well as a peering/transit router, as well as a Metro-E router where you need a 100Gbps ring to carry 10Gbps customers, as well as downstream cheaper routers that will do sub-10Gbps quite nicely. That said, at least for the Metro, I still believe a lighter version of the MX204, with dense 1Gbps capability, is still needed. Been asking since 2007. Mark.
Re: Mx204 alternative
On 9/2/19 4:49 AM, Mark Tinka wrote: That said, in the Metro, we don't generally support LAG's toward customers because getting policing to work reliably on them is difficult. So we wouldn't hit this issue, although I can see how annoying it would be for networks that prefer to do this. I try to avoid them in customer-facing applications, too. And in intra-network situations, I don't know why you'd be LAGging 1Gbps links anymore. But yeah, MX204 and similar LCs on the chassis platforms have some bizarre port usage/speed limitations. Juniper has a little web page to validate your port configurations, but it still seems easy to hit gotchas like this. -- Brandon Martin
Re: Mx204 alternative
The forthcoming Juniper ACX700 sounds like a good fit for metro Ethernet with 4x100G and 24x10G in a shallow 1U hardened form factor. Aled
Re: Mx204 alternative
On 8/Aug/19 16:50, Tom Hill wrote: > > No-one has mentioned it yet, so for completeness big C have the ASR 9901 > (not 9001) with traditional router bits in it. This is the closest competitor to the MX204 as in-house silicon-based boxes go. But for me, I've always felt that IOS XR is too bloated for Metro-E applications. I actually prefer IOS XE in the Metro. Mark.
Re: Mx204 alternative
On Mon, 2 Sep 2019 at 11:24, Mark Tinka wrote: > > 45k? No no, the mx204 with enough license to do BGP is more like 20k - > > 25k or less. It is actually quite cheap, so I doubt the OP will find > > anything much cheaper without going used or do a software router. > > > > I feel it should be mentioned that a Linux box with 4x10G NIC and some > > random switch as port expander also will be able to fulfil the > > requirements and for a fraction of any other solution. > > Including the code maturity for BGP, IS-IS, OSPF and friends? I think the Baldur's proposal works for organisation with few and highly skilled employees. But for larger organisation the CAPEX isn't relevant, it's the OPEX that matters and managing that magic linux box is going to be very OPEX heavy. Also XEON isn't cheap chip, Jericho/PE/Trio/Solar/FP all are cheaper, significantly so. XEON does cover some segment of the market, but it's not large one. -- ++ytti
Re: Mx204 alternative
Does anyone use Juniper 0% finance? We're looking to upgrade from 4 x MX80s and they are a big jump. Thanks
Re: Mx204 alternative
On Mon, 2 Sep 2019 at 17:48, Denys Fedoryshchenko wrote: > Of course, they are much stronger (and cheaper in $/bps or $/pps) when > it comes to L2/L3 lookup, basic stateless filters, simple QoS. > But can Trio perform stateful firewall filtering for millions of flows+ > lot of mpps that Xeon easily handle? Thats the case of recent DDoS > attacks. No it can't, certainly domain where XEON is marketable. Technically if you could program Trio, it could do that and lot more, cheaper and faster than XEON, but you can't program it. I feel like we're at networking vendors same place where we were in early 90s with linux and GPU/NIC, vendors thought their code is secret sauce and wouldn't release specs for people to write their own free software fopr them. Hopefully we'll start seeing network specific chips enter the market with public specs, P5 compiler, no questions (signatures, contracts) asked. I'm convinced there is market that is not being addressed, who is now forced to use XEON but could use something much more efficient, if they were allowed to. Looking at JNPR's market cap evolution over past couple decades, they certainly need to figure out something new. Like how about 8-16*100GE single Trio PCI card with no-questions asked, specification released, would there be a market? I like to think there would be. -- ++ytti
Re: Mx204 alternative
By the way they now say in this KB article that they implemented a «high performance mode» for MX204 / MX10003 with some «set chassis fpc slot high-performance-mode». Anyone wiling to test? :) > Le 2 sept. 2019 à 15:23, Denys Fedoryshchenko a > écrit : > > From snabbco discussion, issue #1013, "If you read Intel datasheets then the > minimum packet rate they are guaranteeing is 64B for 10G (82599), 128B for > 40G (XL710), and 256B for 100G (FM10K)." > > But "hardware", ASIC enabled routers such as MX might be not better and even > need some tuning. > https://kb.juniper.net/InfoCenter/index?page=content=KB33477=METADATA > "On summit MX204 and MX10003 platforms, the line rate frame size is 119 byte > for 10/40GbE port and 95 byte for 100GbE port."
Re: Mx204 alternative
On 2019-09-02 17:16, Saku Ytti wrote: On Mon, 2 Sep 2019 at 16:26, Denys Fedoryshchenko wrote: or some QFX, for example, Broadcom Tomahawk 32x100G switches only do line-rate with >= 250B packets according to datasheets. Only is peculiar term here. 100Gbps is 148Mpps, give or take 100PPM, at 250B it's still some 50Mpps. Times 32 that's 1600Mpps, or 1.6Gpps. Only implies it's modest compared to some other solution, what is that solution? XEON doing ~nothing (not proper lookup even) is some couple hundred Mpps, far cry from 1.6Gpps with ACL, QoS and L3 lookup. I don't care about wire rate on chip with lot of ports, because statistics. 250B average size on 32x100GE on a chip is fine to me. 250B average size on 32x100GE with 32 chips, would be horrifying. I'm not saying XEON does not have application, I'm just saying XEON is bps and pps expensive chip compared to almost anything out there, however there are some application with very deep touch where it is marketable. Btw. technically Tomahawk and Trio are very different, Trio has tens or hundreds of cores executing software, cores happen to have domain specific instruction set, but still software box with lot of cores. Tomahawk is pipeline box, having domain specific hardware and largely not running a software (but all pipelines today are somewhat programmable anyhow). On Trio you are mostly just time limited on what you can do, on Tomahawk you have physical hardware restrictions on what you can do. Of course, they are much stronger (and cheaper in $/bps or $/pps) when it comes to L2/L3 lookup, basic stateless filters, simple QoS. But can Trio perform stateful firewall filtering for millions of flows+ lot of mpps that Xeon easily handle? Thats the case of recent DDoS attacks.
Re: Mx204 alternative
man. 2. sep. 2019 10.22 skrev Mark Tinka : > > > On 8/Aug/19 08:33, Baldur Norddahl wrote: > > 45k? No no, the mx204 with enough license to do BGP is more like 20k - > > 25k or less. It is actually quite cheap, so I doubt the OP will find > > anything much cheaper without going used or do a software router. > > > > I feel it should be mentioned that a Linux box with 4x10G NIC and some > > random switch as port expander also will be able to fulfil the > > requirements and for a fraction of any other solution. > > Including the code maturity for BGP, IS-IS, OSPF and friends? > > Mark. > Maturity is such a subjective word. But yes there are plenty of options for routing protocols on a Linux. Every internet exchange is running BGP on Linux for the route server after all. I am not recommending a server over MX204. I think MX204 is brilliant. It is one of the cheapest options and if that is not cheap enough, THEN the server solution is probably what you may be looking for. You can move a lot of traffic even with an old leftover server. Especially if you are not concerned with moving 64 bytes DDoS at line speed, because likely you would be down anyway in that case. As to the OPEX I would claim there are small shops that would have an easier time with a server, because they know how to do that. They would have only one or two routers and learning how to run JUNOS just for that might never happen. It all depends on what workforce you have. Network people or server guys? Regards Baldur
Re: Weekly Routing Table Report
On Mon, 02 Sep 2019 14:02:43 +0900, Masataka Ohta said: > If you think we should blindly believe your unfounded statement > not supported by any verifiable reference, that is the > condescending behavior. Well Masataka... If "Owen DeLong, who was widely known to have been in an actual job position to know of certain facts, stating these facts" isn't sufficient evidence for you, then applying that very same standard of evidence to your assertions leads directly to "can safely be ignored" *plonk* (the sound of an email address dropping into a not-often-used ignore file) pgpA1j3jgYBYh.pgp Description: PGP signature
Re: Mx204 alternative
Baldur Norddahl wrote on 02/09/2019 13:52: You can move a lot of traffic even with an old leftover server. Especially if you are not concerned with moving 64 bytes DDoS at line speed, because likely you would be down anyway in that case. indeed, and there are very few problems that might happen in practice that couldn't be solved by something with kernel development experience. Nick
Re: Mx204 alternative
On Monday, 2 September, 2019 15:03, "Valdis Klētnieks" said: > Hardened? Is this just "will survive in a not-well-cooled telco closet" > hardening, > or something more unusual? I don't see specs yet, but I would expect it's the former, similar to the MX104 against the rest of the MX range. NEBS-compliances, and -40C to 65C operating temperature range (standard 0C to 46C). We've been very grateful for the latter in exchange (CO) installations - old, brick buildings weary from decades of housing Strowgers are at times hot and filthy compared to your average DC. Regards, Tim.
Re: Mx204 alternative
On 2/Sep/19 11:24, Aled Morris wrote: > > > Sorry I have no inside info, only what's been released publicly. We stayed away from the ACX5000 because the Broadcom chip in there wasn't great for high-touch services. I hope this ACX700 has a better plan. Mark.
RE: Mx204 alternative
> Does anyone use Juniper 0% finance? We're looking to upgrade from 4 x MX80s > and they are a big jump. Last I heard, it was $250k minimum order value so you'll struggle if you're only buying 4 units
Re: Weekly Routing Table Report
> On Sep 2, 2019, at 9:33 AM, Tony Finch wrote: > > Patrick W. Gilmore wrote: >> >> This time I waited for 768,000. (Everyone happy now?) > > I thought the magic number for breaking old Cisco gear was 786432 > (768 * 1024) ... there was a panic about it earlier this year but growth > slowed so it didn't happen as soon as they feared. > > https://www.zdnet.com/article/some-internet-outages-predicted-for-the-coming-month-as-768k-day-approaches/ > > But looking at https://twitter.com/bgp4_table I see we passed the higher > thresold (by some metrics) last month without any apparent routing > failures so maybe the old Cisco gear isn't very important any more! It may be that there were failures but not at the core, which is more likely. I recall writing the internal technical note on the edge devices when we hit 128k and 256k numbers, especially as I was a promoter of u-RPF and this halved the TCAM size. It was only certain devices/customers that may have seen an issue, AND only for new routes not older stable ones. People who want to promote BGP churn as a platform solution need to keep this in mind. It also matters if you have the ability to disaggregate your FIB (default) vs RIB. I’m seeing more of this right now which I think is overall good. Don’t need to install all those routes in hardware if they’re all going the same way.
Re: Mx204 alternative
On Mon, 2 Sep 2019 at 16:26, Denys Fedoryshchenko wrote: > or some QFX, for example, Broadcom Tomahawk 32x100G switches only do > line-rate with >= 250B packets according to datasheets. Only is peculiar term here. 100Gbps is 148Mpps, give or take 100PPM, at 250B it's still some 50Mpps. Times 32 that's 1600Mpps, or 1.6Gpps. Only implies it's modest compared to some other solution, what is that solution? XEON doing ~nothing (not proper lookup even) is some couple hundred Mpps, far cry from 1.6Gpps with ACL, QoS and L3 lookup. I don't care about wire rate on chip with lot of ports, because statistics. 250B average size on 32x100GE on a chip is fine to me. 250B average size on 32x100GE with 32 chips, would be horrifying. I'm not saying XEON does not have application, I'm just saying XEON is bps and pps expensive chip compared to almost anything out there, however there are some application with very deep touch where it is marketable. Btw. technically Tomahawk and Trio are very different, Trio has tens or hundreds of cores executing software, cores happen to have domain specific instruction set, but still software box with lot of cores. Tomahawk is pipeline box, having domain specific hardware and largely not running a software (but all pipelines today are somewhat programmable anyhow). On Trio you are mostly just time limited on what you can do, on Tomahawk you have physical hardware restrictions on what you can do. -- ++ytti
Re: Weekly Routing Table Report
Patrick W. Gilmore wrote: > > This time I waited for 768,000. (Everyone happy now?) I thought the magic number for breaking old Cisco gear was 786432 (768 * 1024) ... there was a panic about it earlier this year but growth slowed so it didn't happen as soon as they feared. https://www.zdnet.com/article/some-internet-outages-predicted-for-the-coming-month-as-768k-day-approaches/ But looking at https://twitter.com/bgp4_table I see we passed the higher thresold (by some metrics) last month without any apparent routing failures so maybe the old Cisco gear isn't very important any more! Tony. -- f.anthony.n.finchhttp://dotat.at/ North Foreland to Selsey Bill: Southwesterly veering westerly, 4 or 5, occasionally 6 at first in east. Smooth or slight, becoming slight, occasionally moderate. Showers later. Good.
Re: Mx204 alternative
On Mon, 02 Sep 2019 10:02:55 +0100, Aled Morris via NANOG said: > The forthcoming Juniper ACX700 sounds like a good fit for metro Ethernet > with 4x100G and 24x10G in a shallow 1U hardened form factor. Hardened? Is this just "will survive in a not-well-cooled telco closet" hardening, or something more unusual? pgpIHiAdTbYyi.pgp Description: PGP signature
Re: Mx204 alternative
On 2019-09-02 15:52, Baldur Norddahl wrote: Maturity is such a subjective word. But yes there are plenty of options for routing protocols on a Linux. Every internet exchange is running BGP on Linux for the route server after all. I am not recommending a server over MX204. I think MX204 is brilliant. It is one of the cheapest options and if that is not cheap enough, THEN the server solution is probably what you may be looking for. You can move a lot of traffic even with an old leftover server. Especially if you are not concerned with moving 64 bytes DDoS at line speed, because likely you would be down anyway in that case. As to the OPEX I would claim there are small shops that would have an easier time with a server, because they know how to do that. They would have only one or two routers and learning how to run JUNOS just for that might never happen. It all depends on what workforce you have. Network people or server guys? Regards Baldur I think that such types of DDoS are much easier to solve on a server with XDP/eBPF than on MX. And much cheaper if we are talking about the new SYN+ACK DDoS and it is exactly 64b ddos case. I used multiple 82599. From snabbco discussion, issue #1013, "If you read Intel datasheets then the minimum packet rate they are guaranteeing is 64B for 10G (82599), 128B for 40G (XL710), and 256B for 100G (FM10K)." But "hardware", ASIC enabled routers such as MX might be not better and even need some tuning. https://kb.juniper.net/InfoCenter/index?page=content=KB33477=METADATA "On summit MX204 and MX10003 platforms, the line rate frame size is 119 byte for 10/40GbE port and 95 byte for 100GbE port." or some QFX, for example, Broadcom Tomahawk 32x100G switches only do line-rate with >= 250B packets according to datasheets.
RE: Mx204 alternative
> Mark Tinka > Sent: Monday, September 2, 2019 9:22 AM > > > On 8/Aug/19 16:50, Tom Hill wrote: > > > > > No-one has mentioned it yet, so for completeness big C have the ASR > > 9901 (not 9001) with traditional router bits in it. > > This is the closest competitor to the MX204 as in-house silicon-based boxes > go. > > But for me, I've always felt that IOS XR is too bloated for Metro-E > applications. I actually prefer IOS XE in the Metro. > I'm afraid I have some bad news for you then, since the new metro portfolio (NCS) from Cisco is all XR. But on the upside it means better support for YANG... adam
Re: Mx204 alternative
On Mon, 2 Sep 2019 at 20:51, wrote: > Judging from mpc7 with hyper-mode I'm sceptical, but as always subject to > test results. We saw 25% pps advantage with hyper-mode on MX10k (which supposedly is same as high-performance-mode). New linecards will be high-performance-mode out-of-box. I think this sort of microcode cleanup periodically makes sense, if you have long enough story on hardware capable of running same microcode. Usually you have to start hardware from scratch which forces the same, rewriting the forwarding plane code and paying some technology debts. -- ++ytti
RE: Mx204 alternative
> Denys Fedoryshchenko > Sent: Monday, September 2, 2019 2:24 PM > > On 2019-09-02 15:52, Baldur Norddahl wrote: > > > > Maturity is such a subjective word. But yes there are plenty of > > options for routing protocols on a Linux. Every internet exchange is > > running BGP on Linux for the route server after all. > > > > I am not recommending a server over MX204. I think MX204 is brilliant. > > It is one of the cheapest options and if that is not cheap enough, > > THEN the server solution is probably what you may be looking for. > > > > You can move a lot of traffic even with an old leftover server. > > Especially if you are not concerned with moving 64 bytes DDoS at line > > speed, because likely you would be down anyway in that case. > > > > As to the OPEX I would claim there are small shops that would have an > > easier time with a server, because they know how to do that. They > > would have only one or two routers and learning how to run JUNOS just > > for that might never happen. It all depends on what workforce you > > have. Network people or server guys? > > > > Regards > > > > Baldur > > > >> > > I think that such types of DDoS are much easier to solve on a server with > XDP/eBPF than on MX. > And much cheaper if we are talking about the new SYN+ACK DDoS and it is > exactly 64b ddos case. I used multiple 82599. > > From snabbco discussion, issue #1013, "If you read Intel datasheets then the > minimum packet rate they are guaranteeing is 64B for 10G (82599), 128B for > 40G (XL710), and 256B for 100G (FM10K)." > > But "hardware", ASIC enabled routers such as MX might be not better and > even need some tuning. > https://kb.juniper.net/InfoCenter/index?page=content=KB33477= > METADATA > "On summit MX204 and MX10003 platforms, the line rate frame size is 119 > byte for 10/40GbE port and 95 byte for 100GbE port." > or some QFX, for example, Broadcom Tomahawk 32x100G switches only do > line-rate with >= 250B packets according to datasheets. > 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. adam
Re: Mx204 alternative
On Mon Sep 02, 2019 at 05:07:07PM +0100, t...@pelican.org wrote: > On Monday, 2 September, 2019 15:03, "Valdis Kl??tnieks" > said: > > > Hardened? Is this just "will survive in a not-well-cooled telco closet" > > hardening, > > or something more unusual? > > I don't see specs yet, but I would expect it's the former, similar to the > MX104 against the rest of the MX range. NEBS-compliances, and -40C to 65C > operating temperature range (standard 0C to 46C). For telco sites Cisco do theirs NCS-55A2-MOD-HD-S: Temperature-hardened NCS-55A2-MOD-HX-S: Temperature-hardened, conformal coated Operating Temperature -40C to +70C they don't say to what degree the conformal coating protects it but that is usually used in dirty environments (military was a common user, I don't know their target for this) brandon
RE: Mx204 alternative
> Olivier Benghozi > Sent: Monday, September 2, 2019 5:02 PM > > By the way they now say in this KB article that they implemented a «high > performance mode» for MX204 / MX10003 with some «set chassis fpc slot > high-performance-mode». > Anyone wiling to test? :) > Judging from mpc7 with hyper-mode I'm sceptical, but as always subject to test results. adam
Re: Weekly Routing Table Report
> On 2. Sep 2019, at 15:49, Valdis Klētnieks wrote: > > *plonk* (the sound of an email address dropping into a not-often-used ignore > file) mmhmm nice nerd burn. ouchie.
Re: Mx204 alternative
On 2/Sep/19 14:52, Baldur Norddahl wrote: > > Maturity is such a subjective word. As service provider operations go, maturity. > But yes there are plenty of options for routing protocols on a Linux. > Every internet exchange is running BGP on Linux for the route server > after all. Not quite the same thing, but I take your point. > > I am not recommending a server over MX204. I think MX204 is brilliant. > It is one of the cheapest options and if that is not cheap enough, > THEN the server solution is probably what you may be looking for. > > You can move a lot of traffic even with an old leftover server. > Especially if you are not concerned with moving 64 bytes DDoS at line > speed, because likely you would be down anyway in that case. > > As to the OPEX I would claim there are small shops that would have an > easier time with a server, because they know how to do that. They > would have only one or two routers and learning how to run JUNOS just > for that might never happen. It all depends on what workforce you > have. Network people or server guys? That's what Saku was alluding to earlier - opex is not just in the hardware. Mark.
Re: Mx204 alternative
On 2/Sep/19 17:07, Saku Ytti wrote: > Like how about 8-16*100GE single Trio PCI card with no-questions > asked, specification released, would there be a market? I like to > think there would be. I'd be down for this. Mark.
Re: Mx204 alternative
On 2/Sep/19 20:00, adamv0...@netconsultings.com wrote: > I'm afraid I have some bad news for you then, since the new metro portfolio > (NCS) from Cisco is all XR. > But on the upside it means better support for YANG... We'll see what happens when we get to that bridge. Mark.
Re: Mx204 alternative
1 Gig is supported on later release versions Sent from my iPhone > On Sep 2, 2019, at 1:49 AM, Mark Tinka wrote: > > > >> On 2/Sep/19 10:28, Hank Nussbacher wrote: >> >> >> >> What about handling LAG on 1Gb/sec links? That is a major showstopper >> if indeed it is missing: >> >> https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/speed-gigether-options.html >> >> •On MX10003 and MX204 routers, rate selectability at PIC >> level and port level does not support 1-Gbps speed. >> •On MX10003 and MX204 routers, the interface name prefix >> must be xe. >> •On MX10003 and MX204 routers, even after configuring >> 1-Gbps speed, the protocol continues to advertise the bandwidth as >> 10-Gigabit Ethernet. >> •On MX10003 and MX204 routers, Link Aggregation Group >> (LAG) is supported on 10-Gbps speed only. It is not supported on >> 1-Gbps speed. > > Well, that's not ideal at all. > > That said, in the Metro, we don't generally support LAG's toward > customers because getting policing to work reliably on them is > difficult. So we wouldn't hit this issue, although I can see how > annoying it would be for networks that prefer to do this. > > Mark.
Re: Mx204 alternative
On the MX204 that is.. Sent from my iPhone > On Sep 2, 2019, at 3:27 PM, Kenneth McRae via NANOG wrote: > > 1 Gig is supported on later release versions > > Sent from my iPhone > >> On Sep 2, 2019, at 1:49 AM, Mark Tinka wrote: >> >> >> >>> On 2/Sep/19 10:28, Hank Nussbacher wrote: >>> >>> >>> >>> What about handling LAG on 1Gb/sec links? That is a major showstopper >>> if indeed it is missing: >>> >>> https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/speed-gigether-options.html >>> >>> •On MX10003 and MX204 routers, rate selectability at PIC >>> level and port level does not support 1-Gbps speed. >>> •On MX10003 and MX204 routers, the interface name prefix >>> must be xe. >>> •On MX10003 and MX204 routers, even after configuring >>> 1-Gbps speed, the protocol continues to advertise the bandwidth as >>> 10-Gigabit Ethernet. >>> •On MX10003 and MX204 routers, Link Aggregation Group >>> (LAG) is supported on 10-Gbps speed only. It is not supported on >>> 1-Gbps speed. >> >> Well, that's not ideal at all. >> >> That said, in the Metro, we don't generally support LAG's toward >> customers because getting policing to work reliably on them is >> difficult. So we wouldn't hit this issue, although I can see how >> annoying it would be for networks that prefer to do this. >> >> Mark. >
Re: Weekly Routing Table Report
Valdis Klētnieks wrote: If you think we should blindly believe your unfounded statement not supported by any verifiable reference, that is the condescending behavior. As you can see, that you finally mentioned rfc1518 as reference helped a lot to suppress unfounded and, thus, useless messages from you, because I verified the rfc to find that all of your points are denied. That's the point to have verifiable references. Well Masataka... If "Owen DeLong, who was widely known to have been in an actual job position to know of certain facts, stating these facts" isn't sufficient evidence for you, I can't see any confirmed facts. Moreover, even if some of his point on a single company might be valid, it is nothing for the discussion on the entire Internet. then applying that very same standard of evidence to your assertions leads directly to "can safely be ignored" As I already wrote: > The following page by Geoff Huston is better than your delusion. > http://www.potaroo.net/ispcolumn/2001-03-bgp.html > What is driving this recent change to exponential growth > of the routing table? > In a word, multi-homing. feel free to verify it. Masataka Ohta
Re: Weekly Routing Table Report
On 9/2/19 15:02, Masataka Ohta wrote: then applying that very same standard of evidence to your assertions leads directly to "can safely be ignored" As I already wrote: > The following page by Geoff Huston is better than your delusion. > http://www.potaroo.net/ispcolumn/2001-03-bgp.html > What is driving this recent change to exponential growth > of the routing table? > In a word, multi-homing. feel free to verify it. May the world come to an end if someone dares to have an independent thought or shares original information that can't be backed up by at least 50 crosschecked references.
