Re: ICMPv6 "too-big" packets ignored (filtered ?) by Cloudflare farms
* Jean-Daniel Pauget > I confess using IPv6 behind a 6in4 tunnel because the "Business-Class" > service > of the concerned operator doesn't handle IPv6 yet. > > as such, I realised that, as far as I can figure, ICMPv6 packet "too-big" > (rfc 4443) > seem to be ignored or filtered at ~60% of ClouFlare's http farms > > as a result, random sites such as http://nanog.org/ or > https://www.ansible.com/ > are badly reachable whenever small mtu are involved ... Hi Jean-Daniel. If you're using using tunnels you'll want to have your tunnel endpoint adjust down the TCP MSS value to match the MTU of the tunnel interface. That way, you'll avoid problems with Path MTU Discovery. Even in those situations where PMTUD does work fine, doing TCP MSS adjustment will improve performance as the server does not need to spend an RTT to discover your reduced MTU. (This isn't really an IPv6 issue, by the way - ISPs using PPPoE will typically perform MSS adjustment for IPv4 packets too.) If you're using Linux as your tunnel endpoint, try: ip6tables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu Tore
Re: WIndows Updates Fail Via IPv6 - Update!
On 6/3/19 03:29, Mark Andrews wrote: > > >> On 6 Mar 2019, at 3:37 pm, Fernando Gont wrote: >> >> On 6/3/19 01:09, Mark Andrews wrote: >>> >>> On 6 Mar 2019, at 1:30 pm, Fernando Gont wrote: On 3/3/19 18:04, Mark Andrews wrote: > There are lots of IDIOTS out there that BLOCK ALL ICMP. That blocks PTB > getting > back to the TCP servers. There are also IDIOTS that deploy load > balancers that > DO NOT LOOK INSIDE ICMP messages for redirecting ICMP messages to the > correct > back end. There are also IDOITS that rate limit PTB generation to > ridiculously > low rates. One should be able to generate PTB at line rate. > > Everyone that has configured mss-fix-up has contributed to > misunderstanding that > you can block ICMP. It is time we had a flag day to REMOVE mss-fix-up > from all > the boxes you control. We need to get PTB working and unfortunately that > means > that we need to stop pandering to admins who don’t know how IP is > supposed to > work. ICMP is NOT optional. It would seem IETF's intention is to actually move away from ICMPv6-based PMTUD, to the extent that is possible. (RFC4821). >>> >>> Which is not a reason to not fix broken equipment and misconfigured >>> firewalls. >>> The workarounds are basically there because people deploy broken equipment. >> >> Agreed. That said, it wasn't solved in 30+ years of IPv4. Do you have >> hopes it will be different with IPv6? > > Make a big enough stink and it will get fixed. People just don’t make enough > of > a stink. Use social media. None of the companies with broken firewalls > really > want their idiotic practices pointed out in public. Start doing so every time > you see it #STUPIDFIREWALL. At times, it's fw defaults. Other times, it is admin policies. RFC4821 seems to signal that the IETF has given up in making ICMP-based PMTUD work, and aims at a (mostly) ICMP-free PMTUD. Essentially, when brokenness is widespread, you have to come-up with workarounds. And when workarounds are sufficiently widespread, there's less of an incentive to fix the original issue. Other times, there's a disconnect between with protocol standards, products, and operational requirements. That's the case of IPv6 EHs. This is their usability on the public Internet: RFC 7872. And these are some of the reasons why you get the numbers in RFC 7872: https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops Cheers, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
Re: WIndows Updates Fail Via IPv6 - Update!
> On 6 Mar 2019, at 3:37 pm, Fernando Gont wrote: > > On 6/3/19 01:09, Mark Andrews wrote: >> >> >>> On 6 Mar 2019, at 1:30 pm, Fernando Gont wrote: >>> >>> On 3/3/19 18:04, Mark Andrews wrote: There are lots of IDIOTS out there that BLOCK ALL ICMP. That blocks PTB getting back to the TCP servers. There are also IDIOTS that deploy load balancers that DO NOT LOOK INSIDE ICMP messages for redirecting ICMP messages to the correct back end. There are also IDOITS that rate limit PTB generation to ridiculously low rates. One should be able to generate PTB at line rate. Everyone that has configured mss-fix-up has contributed to misunderstanding that you can block ICMP. It is time we had a flag day to REMOVE mss-fix-up from all the boxes you control. We need to get PTB working and unfortunately that means that we need to stop pandering to admins who don’t know how IP is supposed to work. ICMP is NOT optional. >>> >>> It would seem IETF's intention is to actually move away from >>> ICMPv6-based PMTUD, to the extent that is possible. (RFC4821). >> >> Which is not a reason to not fix broken equipment and misconfigured >> firewalls. >> The workarounds are basically there because people deploy broken equipment. > > Agreed. That said, it wasn't solved in 30+ years of IPv4. Do you have > hopes it will be different with IPv6? Make a big enough stink and it will get fixed. People just don’t make enough of a stink. Use social media. None of the companies with broken firewalls really want their idiotic practices pointed out in public. Start doing so every time you see it #STUPIDFIREWALL. > Thanks, > -- > Fernando Gont > SI6 Networks > e-mail: fg...@si6networks.com > PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: WIndows Updates Fail Via IPv6 - Update!
On 6/3/19 01:09, Mark Andrews wrote: > > >> On 6 Mar 2019, at 1:30 pm, Fernando Gont wrote: >> >> On 3/3/19 18:04, Mark Andrews wrote: >>> There are lots of IDIOTS out there that BLOCK ALL ICMP. That blocks PTB >>> getting >>> back to the TCP servers. There are also IDIOTS that deploy load balancers >>> that >>> DO NOT LOOK INSIDE ICMP messages for redirecting ICMP messages to the >>> correct >>> back end. There are also IDOITS that rate limit PTB generation to >>> ridiculously >>> low rates. One should be able to generate PTB at line rate. >>> >>> Everyone that has configured mss-fix-up has contributed to misunderstanding >>> that >>> you can block ICMP. It is time we had a flag day to REMOVE mss-fix-up from >>> all >>> the boxes you control. We need to get PTB working and unfortunately that >>> means >>> that we need to stop pandering to admins who don’t know how IP is supposed >>> to >>> work. ICMP is NOT optional. >> >> It would seem IETF's intention is to actually move away from >> ICMPv6-based PMTUD, to the extent that is possible. (RFC4821). > > Which is not a reason to not fix broken equipment and misconfigured firewalls. > The workarounds are basically there because people deploy broken equipment. Agreed. That said, it wasn't solved in 30+ years of IPv4. Do you have hopes it will be different with IPv6? Thanks, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
Re: Arista Layer3
How much do these boxes cost? On Tue, Mar 5, 2019 at 5:24 PM Kaiser, Erich wrote: > It would be worth your time to look at Extreme SLX9640 with advanced > routing license. > > > > On Tue, Mar 5, 2019 at 4:47 PM Roel Parijs wrote: > >> We have been using the 7280SR-48C6 for 2.5 years now. Just after Arista >> announced the full table BGP routing. >> Looking at the price / port there is nothing near Arista. We also use >> Cisco ASR1K and Juniper MX204 but these have far less capacity. >> >> When we first started, there were quite a few features missing but over >> the past 2 year they have really been catching up. I was very happy when >> they added MSS clamping at the end of last year. >> >> The new version 7280R2K should be able to handle 2M routes. >> >> On Tue, Mar 5, 2019 at 9:31 PM wrote: >> >>> Check out the 7280sr2k, which is actually 24*10G, 24*25G, 6*100G >>> >>> On 03/05/2019 08:55 PM, David Hubbard wrote: >>> > I love the NCS5501, but once Arista gets the 2M-route capacity down >>> into the 48x10g format, I'd jump ship in a heartbeat; currently you have to >>> do a much larger chassis-based device or their 100gig 7280 to have that >>> route scale. My big gripes with the 5501 are that, due to its >>> architecture, if you want to do uRPF, you chop your route scale in half, >>> even on the 5501-SE. 5501 also has no supported configuration where you >>> have both first hop redundancy and physical path redundancy, because you >>> can't do both VRRP (its only redundant first hop option) and BVI's, can't >>> do MC-LAG, can't do vPC, so you need switches in addition to the 5501's if >>> that's the goal.. >>> > >>> > David >>> > >>> >>>
Re: Comcast contact for wholesale ethernet/local loop
Access to Comcast ethernet services on a wholesale level, interconnection for NNI to use comcast as local access, etc On Tue, Mar 5, 2019 at 9:01 PM Keith Christian wrote: > TJ, > > What are you seeking, exactly? > > Keith > > On Tue, Mar 5, 2019 at 7:46 PM TJ Trout wrote: > >> Does anyone know the name, or have contact information for the department >> within Comcast that handles carriers looking to purchase local access, etc? >> >> Normally this would be the carrier or wholesale group, but either of >> their websites seem to be aligned to the services we are looking for? >> >> Thank you, >> >> TJ Trout >> EXPOHL LLC >> AS62809 >> >
Re: ICMPv6 "too-big" packets ignored (filtered ?) by Cloudflare farms
> On 6 Mar 2019, at 1:36 pm, Fernando Gont wrote: > > On 5/3/19 03:26, Mark Andrews wrote: >> >> >>> On 5 Mar 2019, at 5:18 pm, Mark Tinka wrote: >>> >>> >>> >>> On 5/Mar/19 00:25, Mark Andrews wrote: >>> Then Cloudflare should negotiate MSS’s that don’t generate PTB’s if they have installed broken ECMP devices. The simplest way to do that is to set the interface MTUs to 1280 on all the servers. Why should the rest of the world have to put up with their inability to purchase devices that work with RFC compliant data streams. >>> >>> I've had this issue with cdnjs.cloudflare.com for the longest time at my >>> house. But as some of you may recall, my little unwanted TCP MSS hack >>> for IPv6 last weekend fixed that issue for me. >>> >>> Not ideal, and I so wish IPv6 would work as designed, but… >> >> It does work as designed except when crap middleware is added. ECMP >> should be using the flow label with IPv6. It has the advantage that >> it works for non-0-offset fragments as well as 0-offset fragments and >> also works for transports other than TCP and UDP. This isn’t a protocol >> failure. It is shitty implementations. > > Not to play devil's advocate but the IETF fot to publish a spec for ECMP > use of Flow Labels only a few years ago. > > For quite a while, they were unasable... and might still be, for some > implementations. And if it is still using the quintuple the PTB has all the necessary information for unfragmented and 0 offset fragment packets (which there shouldn’t be with a working TCP stack) to be passed through. > -- > Fernando Gont > SI6 Networks > e-mail: fg...@si6networks.com > PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: WIndows Updates Fail Via IPv6 - Update!
> On 6 Mar 2019, at 1:30 pm, Fernando Gont wrote: > > On 3/3/19 18:04, Mark Andrews wrote: >> There are lots of IDIOTS out there that BLOCK ALL ICMP. That blocks PTB >> getting >> back to the TCP servers. There are also IDIOTS that deploy load balancers >> that >> DO NOT LOOK INSIDE ICMP messages for redirecting ICMP messages to the correct >> back end. There are also IDOITS that rate limit PTB generation to >> ridiculously >> low rates. One should be able to generate PTB at line rate. >> >> Everyone that has configured mss-fix-up has contributed to misunderstanding >> that >> you can block ICMP. It is time we had a flag day to REMOVE mss-fix-up from >> all >> the boxes you control. We need to get PTB working and unfortunately that >> means >> that we need to stop pandering to admins who don’t know how IP is supposed to >> work. ICMP is NOT optional. > > It would seem IETF's intention is to actually move away from > ICMPv6-based PMTUD, to the extent that is possible. (RFC4821). Which is not a reason to not fix broken equipment and misconfigured firewalls. The workarounds are basically there because people deploy broken equipment. Additionally everything isn’t TCP. > Thanks, > -- > Fernando Gont > SI6 Networks > e-mail: fg...@si6networks.com > PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: ICMPv6 "too-big" packets ignored (filtered ?) by Cloudflare farms
On 5/3/19 03:26, Mark Andrews wrote: > > >> On 5 Mar 2019, at 5:18 pm, Mark Tinka wrote: >> >> >> >> On 5/Mar/19 00:25, Mark Andrews wrote: >> >>> >>> Then Cloudflare should negotiate MSS’s that don’t generate PTB’s if >>> they have installed broken ECMP devices. The simplest way to do that >>> is to set the interface MTUs to 1280 on all the servers. Why should >>> the rest of the world have to put up with their inability to purchase >>> devices that work with RFC compliant data streams. >> >> I've had this issue with cdnjs.cloudflare.com for the longest time at my >> house. But as some of you may recall, my little unwanted TCP MSS hack >> for IPv6 last weekend fixed that issue for me. >> >> Not ideal, and I so wish IPv6 would work as designed, but… > > It does work as designed except when crap middleware is added. ECMP > should be using the flow label with IPv6. It has the advantage that > it works for non-0-offset fragments as well as 0-offset fragments and > also works for transports other than TCP and UDP. This isn’t a protocol > failure. It is shitty implementations. Not to play devil's advocate but the IETF fot to publish a spec for ECMP use of Flow Labels only a few years ago. For quite a while, they were unasable... and might still be, for some implementations. -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
Comcast contact for wholesale ethernet/local loop
Does anyone know the name, or have contact information for the department within Comcast that handles carriers looking to purchase local access, etc? Normally this would be the carrier or wholesale group, but either of their websites seem to be aligned to the services we are looking for? Thank you, TJ Trout EXPOHL LLC AS62809
Re: WIndows Updates Fail Via IPv6 - Update!
On Tue, Mar 5, 2019 at 07:15 Rich Kulawiec wrote: > On Mon, Mar 04, 2019 at 08:04:12AM +1100, Mark Andrews wrote: > > ICMP is NOT optional. > > I've pointed folks at this for years: > > ICMP Packet Filtering v1.2 > http://www.cymru.com/Documents/icmp-messages.html > > ---rsk > Some of the networks that completely block ICMP are shocking. Best, -M<
Re: WIndows Updates Fail Via IPv6 - Update!
On 3/3/19 20:16, Mark Andrews wrote: > > >> On 4 Mar 2019, at 9:33 am, Stephen Satchell wrote: >> >> On 3/3/19 1:04 PM, Mark Andrews wrote: >>> There are lots of IDIOTS out there that BLOCK ALL ICMP. That blocks PTB >>> getting >>> back to the TCP servers. >> >> For those of us who are in the dark, "PTB" appears to refer to "Packet >> Too Big" responses in ICMPv6. >> >> Yes, some admins don't have fine-enough grain tools to block or throttle >> specific types of ICMP, but that's the fault of the vendors, not the admins. > > No, it is the fault of the admins. They should be making it part of the > purchasing > decision if they want to filter ICMP. It’s not like selective filtering is a > new idea. > It is well over 20 years old at this stage. The amount of +20 year old > equipment on the > net is minimal. > > That said modern OS’s don’t need other equipment to “protect" them from ICMP > of any form. > These news don't help in that direction: https://www.theregister.co.uk/2016/06/02/cisco_warns_of_ipv6_dos_vulnerability/ (I'm not complaining about the news, but about the bugs, if you wish) -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
Re: WIndows Updates Fail Via IPv6 - Update!
On 3/3/19 18:04, Mark Andrews wrote: > There are lots of IDIOTS out there that BLOCK ALL ICMP. That blocks PTB > getting > back to the TCP servers. There are also IDIOTS that deploy load balancers > that > DO NOT LOOK INSIDE ICMP messages for redirecting ICMP messages to the correct > back end. There are also IDOITS that rate limit PTB generation to > ridiculously > low rates. One should be able to generate PTB at line rate. > > Everyone that has configured mss-fix-up has contributed to misunderstanding > that > you can block ICMP. It is time we had a flag day to REMOVE mss-fix-up from > all > the boxes you control. We need to get PTB working and unfortunately that > means > that we need to stop pandering to admins who don’t know how IP is supposed to > work. ICMP is NOT optional. It would seem IETF's intention is to actually move away from ICMPv6-based PMTUD, to the extent that is possible. (RFC4821). Thanks, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
Re: WIndows Updates Fail Via IPv6 - Update!
On 3/3/19 16:57, Jeroen Massar wrote: > On 2019-03-03 20:13, Mark Tinka wrote: >> >> >> On 3/Mar/19 18:05, Jeroen Massar wrote: >> >>> IPv6 requires a minimum MTU of 1280. >>> >>> If you cannot transport it, then the transport (the tunnel in this case) >>> needs to handle the fragmentation of packets of 1280 down to whatever does >>> fit in the tunnel. >> >> As you know, IPv6 does not support fragmentation in transit. So that's >> not an option. > > The transport (tunnel) CAN support that kind of fragmentation. Still, that's certainly not panacea. See: https://tools.ietf.org/html/rfc7872 -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
Re: ICMPv6 "too-big" packets ignored (filtered ?) by Cloudflare farms
On 27/2/19 07:01, Jean-Daniel Pauget wrote: > hello, > > I confess using IPv6 behind a 6in4 tunnel because the "Business-Class" > service > of the concerned operator doesn't handle IPv6 yet. > > as such, I realised that, as far as I can figure, ICMPv6 packet "too-big" > (rfc 4443) > seem to be ignored or filtered at ~60% of ClouFlare's http farms > > as a result, random sites such as http://nanog.org/ or > https://www.ansible.com/ > are badly reachable whenever small mtu are involved ... > > support@cloudflare answered me that because I'm not the owner of > concerned site, > and because of security reasons, they wouldn't investigate further. > > are there security concerns with ICMP-too-big ? Please see: https://tools.ietf.org/html/rfc5927 and also: https://tools.ietf.org/html/rfc8021 Thanks, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
Re: Best practices for BGP Communities
On Wed, Mar 6, 2019 at 8:32 Smith, Courtney wrote: > On 3/5/19, 6:04 PM, "NANOG on behalf of Job Snijders" > j...@instituut.net> wrote: > > On Sun, Mar 03, 2019 at 08:42:02PM -0500, Joshua Miller wrote: > > A while back I read somewhere that transit providers shouldn't delete > > communities unless the communities have a specific impact to their > > network, but my google-fu is failing me and I can't find any sources. > > > > Is this still the case? Does anyone have a source for the practice of > > leaving unknown communities alone or deleting them? > > https://tools.ietf.org/html/rfc7454#section-11 > > > Remember policies between two peers may not be same as customer policies. > > Example: Customers_of_transit_X >>> Transit X >>> Peer_A >> > Customers_of_Peer_A > > Customers_of_Peer_A may use community A:50 to set local pref to 50 in > Peer_A network. But that doesn’t not mean Customers_of_transit_X can send > A:50 to set lpref on their routes in Peer_A's network. Peer_A's policy > with Transit X likely does not take action on customer communities since > they are 'peers' not customers. Transit X can send A:50 to Peer_A but > nothing would happen. What's the benefit of Transit X preserving A:50 from > its customers if it means nothing in Transit X? OP didn’t specify what kind of BGP communities they were referring to. In general we can separate communities into two categories: “Informational” and “Action”. You are right that preserving/propagating “action” communities (such as in your example) probably isn’t that interesting. “informational” communities on the other hand can be very valuable. See https://tools.ietf.org/html/rfc8195 for more information on how the two types differ. Kind regards, Job
Re: Best practices for BGP Communities
On 3/5/19, 6:04 PM, "NANOG on behalf of Job Snijders" wrote: On Sun, Mar 03, 2019 at 08:42:02PM -0500, Joshua Miller wrote: > A while back I read somewhere that transit providers shouldn't delete > communities unless the communities have a specific impact to their > network, but my google-fu is failing me and I can't find any sources. > > Is this still the case? Does anyone have a source for the practice of > leaving unknown communities alone or deleting them? https://tools.ietf.org/html/rfc7454#section-11 Kind regards, Job Remember policies between two peers may not be same as customer policies. Example: Customers_of_transit_X >>> Transit X >>> Peer_A >> Customers_of_Peer_A Customers_of_Peer_A may use community A:50 to set local pref to 50 in Peer_A network. But that doesn’t not mean Customers_of_transit_X can send A:50 to set lpref on their routes in Peer_A's network. Peer_A's policy with Transit X likely does not take action on customer communities since they are 'peers' not customers. Transit X can send A:50 to Peer_A but nothing would happen. What's the benefit of Transit X preserving A:50 from its customers if it means nothing in Transit X?
Re: Arista Layer3
It would be worth your time to look at Extreme SLX9640 with advanced routing license. On Tue, Mar 5, 2019 at 4:47 PM Roel Parijs wrote: > We have been using the 7280SR-48C6 for 2.5 years now. Just after Arista > announced the full table BGP routing. > Looking at the price / port there is nothing near Arista. We also use > Cisco ASR1K and Juniper MX204 but these have far less capacity. > > When we first started, there were quite a few features missing but over > the past 2 year they have really been catching up. I was very happy when > they added MSS clamping at the end of last year. > > The new version 7280R2K should be able to handle 2M routes. > > On Tue, Mar 5, 2019 at 9:31 PM wrote: > >> Check out the 7280sr2k, which is actually 24*10G, 24*25G, 6*100G >> >> On 03/05/2019 08:55 PM, David Hubbard wrote: >> > I love the NCS5501, but once Arista gets the 2M-route capacity down >> into the 48x10g format, I'd jump ship in a heartbeat; currently you have to >> do a much larger chassis-based device or their 100gig 7280 to have that >> route scale. My big gripes with the 5501 are that, due to its >> architecture, if you want to do uRPF, you chop your route scale in half, >> even on the 5501-SE. 5501 also has no supported configuration where you >> have both first hop redundancy and physical path redundancy, because you >> can't do both VRRP (its only redundant first hop option) and BVI's, can't >> do MC-LAG, can't do vPC, so you need switches in addition to the 5501's if >> that's the goal.. >> > >> > David >> > >> >>
Re: Best practices for BGP Communities
On Sun, Mar 03, 2019 at 08:42:02PM -0500, Joshua Miller wrote: > A while back I read somewhere that transit providers shouldn't delete > communities unless the communities have a specific impact to their > network, but my google-fu is failing me and I can't find any sources. > > Is this still the case? Does anyone have a source for the practice of > leaving unknown communities alone or deleting them? https://tools.ietf.org/html/rfc7454#section-11 Kind regards, Job
RE: Internap Corporation - DDOS
Don't forget, just because its the source IP in the packet doesn't mean thats where it originated from (its probably not). But, since it contains a consistent source IP, it should be fairly simple to filter it upstream. -Original message- From:Tyler Harden Sent:Tue 03-05-2019 02:44 pm Subject:Internap Corporation - DDOS To:nanog@nanog.org; Is anyone else being DDOS’d or flooded with traffic from Internap Corporation registered IP space? We’re on day 2 of consistent outages and the traffic I’m receiving is entirely from IPs in the /15 range 64.94.0.0-64.95.255.255 Cheers, Tyler Harden President exospec
Re: Arista Layer3
We have been using the 7280SR-48C6 for 2.5 years now. Just after Arista announced the full table BGP routing. Looking at the price / port there is nothing near Arista. We also use Cisco ASR1K and Juniper MX204 but these have far less capacity. When we first started, there were quite a few features missing but over the past 2 year they have really been catching up. I was very happy when they added MSS clamping at the end of last year. The new version 7280R2K should be able to handle 2M routes. On Tue, Mar 5, 2019 at 9:31 PM wrote: > Check out the 7280sr2k, which is actually 24*10G, 24*25G, 6*100G > > On 03/05/2019 08:55 PM, David Hubbard wrote: > > I love the NCS5501, but once Arista gets the 2M-route capacity down into > the 48x10g format, I'd jump ship in a heartbeat; currently you have to do a > much larger chassis-based device or their 100gig 7280 to have that route > scale. My big gripes with the 5501 are that, due to its architecture, if > you want to do uRPF, you chop your route scale in half, even on the > 5501-SE. 5501 also has no supported configuration where you have both > first hop redundancy and physical path redundancy, because you can't do > both VRRP (its only redundant first hop option) and BVI's, can't do MC-LAG, > can't do vPC, so you need switches in addition to the 5501's if that's the > goal.. > > > > David > > > >
Re: a quick survey about LLDP and similar
On Fri, Mar 1, 2019 at 8:26 AM Anderson, Charles R wrote: > > We require LLDP/LLDP-MED to configure our VOIP phones. > > For trunk links, it is extremely helpful to verify correct topology. > > For datacenters, it is EXTREMELY helpful to verify hypervisor connectivity. I'd say it's extremely helpful anywhere. We enable it on every single port unless there is a specific reason to disable it. Our particularly clueful customers can now submit requests like: "For the system attached to port 1/2/3, please switch to VLAN 456." This ticket gets closed in about 10 seconds. We also run LLDP speakers on our University-controlled workstations so we can see details about the system in "slow lldp neighbor" on the switch. The more LLDP the better, from my perspective.
Re: How to choose a transit provider?
thanks everyone watching the video, working on some more new ones. I am also working on a ranking system for transit providers. The way ranking will work is going to be limited to a Metro Do you guys have any recommendations what technical aspects to look for when ranking ISPs? it's quiet hard to rank them fairly without having their routing table views, i think, please let me know your thoughts on this and any recommendation is welcome. On Thu, Feb 14, 2019 at 3:05 PM Mehmet Akcin wrote: > thanks for all feedback, I have tried to summarize my thoughts in a video, > hoping this is useful set of notes https://youtu.be/4gihKxb6uys > > On Sat, Dec 15, 2018 at 9:46 AM Mark Tinka wrote: > >> >> >> On 15/Dec/18 19:37, nanog-...@mail.com wrote: >> >> > >> > I certainly subscribe to the notion that transport + transit is >> usually less expensive than DIA, but this does depend on the market and >> location. >> >> ... and the type of customer. >> >> DIA for a high-value "Enterprise" customer (think of a large >> conglomerate) is typically more costly than DIA for a low-value >> "Enterprise" customer (think of a family-owned travel & tour company). >> The large global ISP's are making more money from "enterprise" business >> than typical wholesale/transit services. This can support the idea that >> DIA can be pricier than transit. >> >> Mark. >> >
Internap Corporation - DDOS
Is anyone else being DDOS’d or flooded with traffic from Internap Corporation registered IP space? We’re on day 2 of consistent outages and the traffic I’m receiving is entirely from IPs in the /15 range 64.94.0.0-64.95.255.255 Cheers, Tyler Harden President exospec
Re: Arista Layer3
Thanks for info! -- Dmitry Sherman Interhost Networks Ltd dmi...@interhost.net Mobile: +972-54-3181182 Office: +972-74-7029881 Web: www.interhost.co.il On 05/03/2019, 21:26, "Saku Ytti" wrote: Hey Dmitry, > What do you think about Arista 7280SR (DCS-7280SR-48C6-M-R) as a BGP peering router with 3 x upstream with full route view in RIB (ipv4 + ipv6) and another IXP feed? > Considering switching from ASR9001 which is doing perfect work but has no more ports left. > The price is very competitive comparing to MX or ASR and this router-switch have 48x10Gig + 6x100GigE ports. You should compare 7280SR against NCS5500 and PTX1k, not ASR and MX. ANET is great company, with great people, but they are like 2 years old in SP market and this is quite visible. It is impressive though what they've done in so little time. -- ++ytti
Re: Arista Layer3
Check out the 7280sr2k, which is actually 24*10G, 24*25G, 6*100G On 03/05/2019 08:55 PM, David Hubbard wrote: > I love the NCS5501, but once Arista gets the 2M-route capacity down into the > 48x10g format, I'd jump ship in a heartbeat; currently you have to do a much > larger chassis-based device or their 100gig 7280 to have that route scale. > My big gripes with the 5501 are that, due to its architecture, if you want to > do uRPF, you chop your route scale in half, even on the 5501-SE. 5501 also > has no supported configuration where you have both first hop redundancy and > physical path redundancy, because you can't do both VRRP (its only redundant > first hop option) and BVI's, can't do MC-LAG, can't do vPC, so you need > switches in addition to the 5501's if that's the goal.. > > David >
Re: Arista Layer3
On 3/5/19, 2:28 PM, "NANOG on behalf of Saku Ytti" wrote: Hey Dmitry, > What do you think about Arista 7280SR (DCS-7280SR-48C6-M-R) as a BGP peering router with 3 x upstream with full route view in RIB (ipv4 + ipv6) and another IXP feed? > Considering switching from ASR9001 which is doing perfect work but has no more ports left. > The price is very competitive comparing to MX or ASR and this router-switch have 48x10Gig + 6x100GigE ports. You should compare 7280SR against NCS5500 and PTX1k, not ASR and MX. ANET is great company, with great people, but they are like 2 years old in SP market and this is quite visible. It is impressive though what they've done in so little time. -- ++ytti I love the NCS5501, but once Arista gets the 2M-route capacity down into the 48x10g format, I'd jump ship in a heartbeat; currently you have to do a much larger chassis-based device or their 100gig 7280 to have that route scale. My big gripes with the 5501 are that, due to its architecture, if you want to do uRPF, you chop your route scale in half, even on the 5501-SE. 5501 also has no supported configuration where you have both first hop redundancy and physical path redundancy, because you can't do both VRRP (its only redundant first hop option) and BVI's, can't do MC-LAG, can't do vPC, so you need switches in addition to the 5501's if that's the goal.. David
Re: Arista Layer3
Hey Dmitry, > What do you think about Arista 7280SR (DCS-7280SR-48C6-M-R) as a BGP peering > router with 3 x upstream with full route view in RIB (ipv4 + ipv6) and > another IXP feed? > Considering switching from ASR9001 which is doing perfect work but has no > more ports left. > The price is very competitive comparing to MX or ASR and this router-switch > have 48x10Gig + 6x100GigE ports. You should compare 7280SR against NCS5500 and PTX1k, not ASR and MX. ANET is great company, with great people, but they are like 2 years old in SP market and this is quite visible. It is impressive though what they've done in so little time. -- ++ytti
Re: Arista Layer3
Those devices are awesome, I use those on the same usecase, and recommend them (I do not run pim, tho) On 03/05/2019 07:17 PM, Dmitry Sherman wrote: > Hello, > What do you think about Arista 7280SR (DCS-7280SR-48C6-M-R) as a BGP peering > router with 3 x upstream with full route view in RIB (ipv4 + ipv6) and > another IXP feed? > Considering switching from ASR9001 which is doing perfect work but has no > more ports left. > The price is very competitive comparing to MX or ASR and this router-switch > have 48x10Gig + 6x100GigE ports. > Will it run smoothly with BGP, PIM, IPV6? > Thanks. >
Re: Arista Layer3
Hello, What do you think about Arista 7280SR (DCS-7280SR-48C6-M-R) as a BGP peering router with 3 x upstream with full route view in RIB (ipv4 + ipv6) and another IXP feed? Considering switching from ASR9001 which is doing perfect work but has no more ports left. The price is very competitive comparing to MX or ASR and this router-switch have 48x10Gig + 6x100GigE ports. Will it run smoothly with BGP, PIM, IPV6? Thanks. -- Dmitry Sherman Interhost Networks Ltd dmi...@interhost.net Mobile: +972-54-3181182 Office: +972-74-7029881 Web: www.interhost.co.il On 01/12/2017, 1:17, "NANOG on behalf of joel jaeggli" wrote: On 11/30/17 13:00, Ken Chase wrote: > >Arista DCS-7280SRA-48C6 is a 1ru box.?? > > > >Has a nominally million route fib, Jericho+ 8GB of packet buffer. > >control-plane is 8GB of ram andAMD GX-424CC SOC which is 4 core 2.4ghz. > >We do direct fib injection with bird rather than the arista bgpd but the > >control-plane is capable of managing quite a few bgp sessions. > > > >the 1/2ru 7280CR2K-30 and 60 are 2m route fib boxes with still heftier > >control planes but they're a different class of box being all 100G and > >requiring multi-chip/internal fabrics. > > Sounds pretty good - hows your power draw on that thing? Why'd you pick Bird > in this case? this a standard sr that's moderately busy but not exactly slammed, I'm be impressed if you could triple that at full tilt. #show environment power Power InputOutput Output Supply ModelCapacity Current Current PowerStatus --- - - 1 PWR-500AC-R 500W0.35A5.27A62.8W Ok 2 PWR-500AC-R 500W0.32A4.81A56.4W Ok Total -- 1000W -- -- 119.1W -- bird had memory footprint going with it as well as some local modification and we hacked addpath into it a few years ago. filtering poilcy is something we programmatically generate and interact with via agents so a traditional style monolithic config isn't that useful. > /kc > > > >> /kc > >> > >> On Thu, Nov 30, 2017 at 10:45:09AM -0800, Tyler Conrad said: > >> >For Enterprise/DC, it works great. For service provider, they're not 100% > >> >yet. The main issue is going to be around VRFs, as there's no interaction > >> >between them (at least in the code version I'm on, that may have changed > >> >recently or be changing soon). They'll work great as a P-Router, but if you > >> >need a PE with route leaking I'd look at another vendor. > >> > > >> >I use a couple pairs of 7280SRs as edge routers/border leaves. Multiple > >> >full table feeds without any issue. > >> > > >> >On Thu, Nov 30, 2017 at 10:36 AM, Romeo Czumbil >> >> wrote: > >> > > >> >> So I've been using Arista as layer2 for quite some time, and I'm pretty > >> >> happy with them. > >> >> Kicking the idea around to turn on some Layer3 features but I've been > >> >> hearing some negative feedback. > >> >> The people that I did hear negative feedback don't use Arista themselves. > >> >> (they just heard) > >> >> > >> >> So do we have any Arista L3 people out here that can share some negatives > >> >> or positives? > >> >> > >> >> Use case: Just some MPLS IPv4/IPv6 routing, l2vpn OSPF/BGP > >> >> Maybe 20k routes (no full internet routes) > >> >> 7050 Series > >> >> 7280 Series > >> >> > >> >> -Romeo > >> >> > >> > > > > > > > > This mail was received via Interhost Mail-SeCure System.
Re: ICMPv6 "too-big" packets ignored (filtered ?) by Cloudflare farms
On Tue, Mar 5, 2019 at 10:09 AM Bjørn Mork wrote: > Stephen Satchell writes: > > Did you submit a bug report? > > I believe this was fixed 5 years ago (in Linux v3.17): > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cb1ce2ef387b01686469487edd45994872d52d73 > > But RHEL and CentOS are using kernels from the stone age, so they > haven't noticed yet. For those who might need this feature, and have a Red Hat contract, a suggestion: If you submit a ticket, someone at Red Hat might backport the patch for you.
Re: ICMPv6 "too-big" packets ignored (filtered ?) by Cloudflare farms
Stephen Satchell writes: > On 3/5/19 2:54 AM, Thomas Bellman wrote: >> Out of curiosity, which operating systems put anything useful (for use >> in ECMP) into the flow label of IPv6 packets? At the moment, I only >> have access to CentOS 6 and CentOS 7 machines, and both of them set the >> flow label to zero for all traffic. > > Did you submit a bug report? I believe this was fixed 5 years ago (in Linux v3.17): https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cb1ce2ef387b01686469487edd45994872d52d73 But RHEL and CentOS are using kernels from the stone age, so they haven't noticed yet. Bjørn
Looking for a Google contact
Can someone contact me off list about an issue.
Re: WIndows Updates Fail Via IPv6 - Update!
On Tue, Mar 5, 2019 at 4:54 PM wrote: > Let me play a devil's advocate here, the above statement begs a question > then, how do you know all that is harmful would you test for every possible > extension and hw/sw permutation? > So there would be 3 sets (though lines might be blurred) known safe, known > harmful and the biggest of them unknown unknowns. > Now as an operator of a commercial network (i.e. your customers like it > mostly up) wouldn't you do a calculated risk evaluation and opt for the known > safe -which you know 99% of your customers use and block the rest while > pissing off the remaining 1%? > I know it sounds awful (like a calculations for vehicle safety recalls), but > ... You don't know. Everything is horribly broken anyhow and if you are not pwned, the main reason is that you're not attractive target. If you are being targeted, you will be pwned by zero to modest budget. Attacker budget leverage to defender is ridiculous. And ICMP won't be the vector. Fear is excellent marketing tool, as we can see in politics, works every time. But I rather fix realised problems, rather than make unprovable assumptions of actions yielding to net benefit. The assumption here is, if we just allow ICMP types A, B and C we are gaining in security, can we substantiate that claim at all? We can substantiate easily that the proposed ICMP filter breaks real useful ICMP tooling. -- ++ytti
RE: WIndows Updates Fail Via IPv6 - Update!
> From: NANOG On Behalf Of Saku Ytti > > Hey Rich, > > > I've pointed folks at this for years: > > ICMP Packet Filtering v1.2 > > http://www.cymru.com/Documents/icmp-messages.html > > > To me, the correct pattern is here is to deny things you know to be harmful > and can justify it reasonably and test that justification over time for its > validity. > Let me play a devil's advocate here, the above statement begs a question then, how do you know all that is harmful would you test for every possible extension and hw/sw permutation? So there would be 3 sets (though lines might be blurred) known safe, known harmful and the biggest of them unknown unknowns. Now as an operator of a commercial network (i.e. your customers like it mostly up) wouldn't you do a calculated risk evaluation and opt for the known safe -which you know 99% of your customers use and block the rest while pissing off the remaining 1%? I know it sounds awful (like a calculations for vehicle safety recalls), but ... adam
Re: ICMPv6 "too-big" packets ignored (filtered ?) by Cloudflare farms
On 3/5/19 2:54 AM, Thomas Bellman wrote: > Out of curiosity, which operating systems put anything useful (for use > in ECMP) into the flow label of IPv6 packets? At the moment, I only > have access to CentOS 6 and CentOS 7 machines, and both of them set the > flow label to zero for all traffic. Did you submit a bug report?
Re: WIndows Updates Fail Via IPv6 - Update!
Hey Rich, > I've pointed folks at this for years: > ICMP Packet Filtering v1.2 > http://www.cymru.com/Documents/icmp-messages.html To me this seems anti-pattern. It seems it was written on basis of 'what we know we allow, what we don't know we deny'. With assumption that ICMP dangerous. Similarly we break IP extensibility by not allowing IP protocols we don't know about. There are many, hopefully obvious reasons that just because we don't know about it, doesn't mean it's dangerous. One more obvious is, that it may not exist yet. To me, the correct pattern is here is to deny things you know to be harmful and can justify it reasonably and test that justification over time for its validity. One particular example springs to mind, ICMP Timestamp, this allows you to measure unidirectional latency to millisecond precision, unless we specifically break it. It's been useful troubleshooting tool to me in the past, saving time and money. -- ++ytti
Re: WIndows Updates Fail Via IPv6 - Update!
On Mon, Mar 04, 2019 at 08:04:12AM +1100, Mark Andrews wrote: > ICMP is NOT optional. I've pointed folks at this for years: ICMP Packet Filtering v1.2 http://www.cymru.com/Documents/icmp-messages.html ---rsk
Re: ICMPv6 "too-big" packets ignored (filtered ?) by Cloudflare farms,Re: ICMPv6 "too-big" packets ignored (filtered ?) by Cloudflare farms
> Out of curiosity, which operating systems put anything useful (for use > in ECMP) into the flow label of IPv6 packets? At the moment, I only > have access to CentOS 6 and CentOS 7 machines, and both of them set the > flow label to zero for all traffic. FreeBSD 11.2-STABLE. Steinar Haug, Nethelp consulting, sth...@nethelp.no
Re: ICMPv6 "too-big" packets ignored (filtered ?) by Cloudflare farms
On Tue, Mar 5, 2019 at 12:09 PM Joel Jaeggli wrote: > Parsing the icmp payload was something we considered in rfc7690 but wasn’t > one the approaches we pursued (we broadcasted the ptb to all hosts on the > segment(s) behind the load balancers in our original implementation). > > It actually seems like it is becoming feasible to do in an Ethernet switch > ASIC like tofino if that is what you want to burn real estate on. Being > worthwhile is another matter. It is definitely possible in all relevant existing NPUs like Trio, Solar, FP, EZChip, Lightspeed et.al. As it is within visibility of lookup engine and it is at fixed offset. So not only possible but also cheap. -- ++ytti
Re: ICMPv6 "too-big" packets ignored (filtered ?) by Cloudflare farms
On 2019-03-05 07:26 CET, Mark Andrews wrote: > It does work as designed except when crap middleware is added. ECMP > should be using the flow label with IPv6. It has the advantage that > it works for non-0-offset fragments as well as 0-offset fragments and > also works for transports other than TCP and UDP. This isn’t a protocol > failure. It is shitty implementations. Out of curiosity, which operating systems put anything useful (for use in ECMP) into the flow label of IPv6 packets? At the moment, I only have access to CentOS 6 and CentOS 7 machines, and both of them set the flow label to zero for all traffic. There is also the problem that the device generating the Packet Too Big ICMP, is not the same as the end host that the big packet was destined for, and does not know what flow label the end host would have set in its TCP responses. RFC 6437 is also explicit that: o Forwarding nodes such as routers and load distributors MUST NOT depend only on Flow Label values being uniformly distributed. In any usage such as a hash key for load distribution, the Flow Label bits MUST be combined at least with bits from other sources within the packet, so as to produce a constant hash value for each flow In practice, using at least the source and destination IP(v6) addresses in addition to the flow label. But the ICMP packet has a different source address than TCP responses from the end host. Further problem is that the TCP responses from the destination end host might not even be *passing* the router that generates a Packet Too Big ICMP error. In an anycast scenario, that router might have a route to the sending IPv6 address that goes to a different datacenter than the host that sent the large packet. E.g, consider the following network: A1 A2 | | DC1 DC2 / \ / / \ / / \ / R1 R2 \ / \ / \ / R3 | B A1 and A2 are hosts in different datacenters, using the same anycast address A. Host B initiates a TCP session with address A, R3 selects the route via R1, and thus reaches A1 in datacenter DC1. A1 sends a large packet towards B, but the router in DC1 elects to send that via R2. R2 generates a PTB ICMP, but has its best route to address A towards DC2... /Bellman signature.asc Description: OpenPGP digital signature
Re: ICMPv6 "too-big" packets ignored (filtered ?) by Cloudflare farms
Sent from my iPhone > On Mar 5, 2019, at 01:31, Saku Ytti wrote: > >> On Tue, Mar 5, 2019 at 12:26 AM Mark Andrews wrote: >> >> Then Cloudflare should negotiate MSS’s that don’t generate PTB’s if >> they have installed broken ECMP devices. The simplest way to do that > > Out of curiosity does that imply you are aware of non-broken ECMP > devices, which are able to hash on the embedded original packet? Parsing the icmp payload was something we considered in rfc7690 but wasn’t one the approaches we pursued (we broadcasted the ptb to all hosts on the segment(s) behind the load balancers in our original implementation). It actually seems like it is becoming feasible to do in an Ethernet switch ASIC like tofino if that is what you want to burn real estate on. Being worthwhile is another matter. > > -- > ++ytti >
Re: ICMPv6 "too-big" packets ignored (filtered ?) by Cloudflare farms
On Tue, Mar 5, 2019 at 12:26 AM Mark Andrews wrote: > Then Cloudflare should negotiate MSS’s that don’t generate PTB’s if > they have installed broken ECMP devices. The simplest way to do that Out of curiosity does that imply you are aware of non-broken ECMP devices, which are able to hash on the embedded original packet? -- ++ytti
Re: ICMPv6 "too-big" packets ignored (filtered ?) by Cloudflare farms
Sent from my iPhone > On Mar 4, 2019, at 22:26, Mark Andrews wrote: > > > >> On 5 Mar 2019, at 5:18 pm, Mark Tinka wrote: >> >> >> >>> On 5/Mar/19 00:25, Mark Andrews wrote: >>> >>> >>> Then Cloudflare should negotiate MSS’s that don’t generate PTB’s if >>> they have installed broken ECMP devices. The simplest way to do that >>> is to set the interface MTUs to 1280 on all the servers. Why should >>> the rest of the world have to put up with their inability to purchase >>> devices that work with RFC compliant data streams. >> >> I've had this issue with cdnjs.cloudflare.com for the longest time at my >> house. But as some of you may recall, my little unwanted TCP MSS hack >> for IPv6 last weekend fixed that issue for me. >> >> Not ideal, and I so wish IPv6 would work as designed, but… > > It does work as designed except when crap middleware is added. ECMP > should be using the flow label with IPv6. It has the advantage that > it works for non-0-offset fragments as well as 0-offset fragments and > also works for transports other than TCP and UDP. This isn’t a protocol > failure. It is shitty implementations. Your mobile carrier’s stateless tcp accelerator should stop sending acks with a zero flow label so we can actually identify them as part of the same flow... There a lot of headwind in the real world for using the flow label as a hash component. > >> Mark. > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > >
