Re: 10G-capable customer router recommendations?
I highly doubt that. It is not easy to configure, certainty trial and error approaches will generate low performance. I have Mikrotik CCR in production and everything the manufacturer states it does, it does for me. Best regards, Kurt Kraut Em 15 de abr de 2016 19:08, "Filip Hruska" escreveu: > Hi, > > I would also vote for Mikrotik products; IMHO this looks perfect for this > situation. > > http://routerboard.com/CCR1009-8G-1S-1SplusPC > > > > On 04/16/2016 12:01 AM, mike.l...@gmail.com wrote: > >> Check out the Mikrotik Cloud Core routers, they make them with SFP+ >> support now. I have one of them with 10g deployed right now. >> >> -Mike >> >> On Apr 15, 2016, at 14:52, Aaron wrote: >>> >>> Not a lot of 10G capable CPEs out there. For our 10G residential >>> customers we install Brocade ICXs. >>> >>> Aaron >>> >>> >>> On 4/15/2016 3:18 PM, David Sotnick wrote: >>>> Hello masters of the Internet, >>>> >>>> I was recently asked to set up networking at a VIP's home where he has >>>> Comcast "Gigabit Pro" service, which is delivered on a 10G-SR MM port >>>> on a >>>> Comcast-supplied Juniper ACX-2100 router. >>>> >>>> Which customer router would you suggest for such a setup? It needs to do >>>> IPv4 NAT, DHCP, IPv4+IPv6 routing and have a decent L4 firewall (that >>>> also >>>> supports IPv6). >>>> >>>> The customer pays for "2Gb" service (Comcast caps this at 2G+10% = >>>> 2.2Gbps) >>>> and would like to get what he pays for (*cough*) by having the ability >>>> to >>>> stream two 1Gbps streams (or at least achieve > 1.0Gbps). >>>> >>>> I'm tempted to get another ACX-2100 and do a 4x1Gb LACP port-channel to >>>> the >>>> customer switch, or replace the AV-integrator-installed Cisco SG300-52P >>>> (Cisco switch with e.g. an EX-3300 with 10Gb uplinks). >>>> >>>> Thanks in advance for your suggestions. >>>> >>>> -Dave >>>> >>> >>> -- >>> >>> Aaron Wendel >>> Chief Technical Officer >>> Wholesale Internet, Inc. (AS 32097) >>> (816)550-9030 >>> http://www.wholesaleinternet.com >>> >>> >>> >>
Re: Cogent NOC
Hello, mtr packet loss column has no scientific precision and should not be considered. It is not mtr fault but forwarding routers have a low priority to respond to ICMP requests. The only way you can prove there is a problem is a end to end ping, the regular ping command, not mtr. Best regards, Kurt Kraut 2016-12-14 17:16 GMT-02:00 Randy : > Hi all, > > Anyone beyond front line support at cogento on list? > > Nanog is the last place I'd look for assistance but it seems support over > at cogentco is not nearly what it used to be. > > Example MTR to cogen't own website (support doesn't utilize or understand > MTR at all apparently): > > Host Loss% Snt Last Avg Best Wrst > StDev > 1. x.x.x.x 0.0% 1960.5 11.7 0.3 > 186.8 35.2 > 2. x.x.x.x 0.0% 1960.6 10.2 0.4 > 226.3 36.2 > 3. 38.88.249.209 0.0% 1960.9 1.1 0.7 > 17.7 1.2 > 4. te0-0-2-3.nr13.b023801-0.iad01.atl 0.0% 1961.0 1.0 0.8 > 2.0 0.1 > 5. te0-0-0-1.rcr22.iad01.atlas.cogent 2.0% 1962.1 1.9 1.0 > 3.3 0.4 > 6. be2961.ccr41.iad02.atlas.cogentco. 2.6% 1961.8 2.1 1.1 > 3.8 0.5 > 7. be2954.rcr21.iad03.atlas.cogentco. 2.6% 1962.0 2.3 1.2 > 9.4 0.7 > 8. be2952.agr11.iad03.atlas.cogentco. 0.5% 1962.7 2.6 1.5 > 6.8 0.6 > 9. cogentco.com4.1% 1962.1 2.0 1.0 > 16.8 1.1 > > Pretty much the same to anywhere. Packet loss begins at rcr22.iad01 and > propagates all the way down the line. Worse during peak hours, gone late > at night. > > After three days of no email response for my ticket, I called and after an > hour of my life I want back, front line support cannot reproduce the loss. > Final conclusion: "Your host is dropping packets". > > -- > ~Randy >
Re: internet - sparkle
Hello, Also Sparkle (AS6762) has a significant footprint in South America, I'd say even bigger than Level 3 because they have mobile telco and broadband ISP in Brazil. I wouldn't worry much with latency in NA because at least in South America they do hot potato (as everyone does) and all their PoPs exchange traffic with at least Level 3. So I suspect traffic hardly ever exits their PoP within their network. Best regards, Kurt Kraut Em qua, 16 de mai de 2018 às 16:32, Jared Geiger escreveu: > If most of your traffic is for US based destinations, you might see worse > performance since Sparkle doesn't seem to have many US POPs/Peering > locations compared to Centurylink/Level3 or HE. You'd probably benefit more > by pulling in some peering from Dallas than adding or replacing a transit > provider as your current mix is decent for an eyeball network. Pick up > peering with Cloudflare, Netflix, Amazon, EdgeCast, Facebook, Apple, > Akamai, and Microsoft in Dallas and you might even be able to get rid of > one of your transit providers. > > Sparkle would "shine" if you were a US hosting provider with many eyeballs > in Europe/Africa/Middle East. > > On Wed, May 16, 2018 at 11:34 AM, Mark Tinka wrote: > > > > > > > On 16/May/18 16:54, Aaron Gould wrote: > > > .written in 12/2015 - do y'all think this is accurate, and, in 2018, is > > it > > > still accurate ? (asking since my next question is related to Sparkle, > > since > > > they are listed in that previous article as a significant Internet > > presence) > > > > I don't know about "owning" the Internet, but I would agree with the > > article re: the 7 key global transit providers as things stand in 2018. > > > > It matches up with our own compliment of transit providers in our > > network (AS37100). > > > > > > > > > > > > > My coworker just got back from ITW/Chicago and he is considering > Sparkle > > as > > > an additional Internet provider for the ISP I work for in San Antonio, > > TX . > > > we would need to uplink to Sparkle in the central Texas area somehow. > He > > > mentioned that Sparkle may be in McAllen / Dallas and could possibly, > in > > the > > > future be in Austin or San Antonio > > > > My initial experience with TI Sparkle was in South East Asia back in > > '08. They were decent. > > > > We have them in our stable, and like them for their South American > > coverage. > > > > Mark. > > >
Re: did facebook just DoS me?
Hello Mr. Mata, I'd like to register you might not be the only one. At work, I deal with DDoS on a daily basis. A pretty common UDP DDoS attack was hiting random IPs of our autonomous system and I applied a bunch of rules to block it. There rule had exceptions for content providers with high demand, like Google, Facebook and Akamai. For my surprise, after I applied my DROP rules, there was still a significant amount of traffic reaching the target servers. I perform some PCAPs I many IP addresses belonged to Facebook. At first I thought: - 'Clever attacker. He guesses I could not be as severe as I am to regular UDP traffic if the origin was Facebook and he deliberately spoofed their IP address.' But one of my collegues quickly realized the incoming MAC ADDRESS was the actual Facebook router we have a peering at a internet exchange. So indeed the traffic came from their network. The UDP source IP address is not enough to drag to this conclusion, but the MAC ADDRESS was very convincing to me. Best regards, Kurt Kraut 2017-04-03 19:46 GMT-03:00 Miguel Mata : > Guys and gals, > > just received a DoS from supposedly Facebook. Any contact of way of > getting in touch with > them? > > Thanks. > > >
Re: did facebook just DoS me?
Hello Christopher, I hardly belive it. IP addresses not allocated to servers were receiving attack, a whole /22 was attacked and it was solely used for servers (including IP addresses not allocated to devices), not for computers with user interface or mobile devices that could actually use Facebook. And if I recall it correctly, it was SSDP amplification attack. Best regards, Kurt Kraut 2017-04-04 21:58 GMT-03:00 Christopher Morrow : > > > On Tue, Apr 4, 2017 at 6:47 PM, Kurt Kraut wrote: > >> >> I perform some PCAPs I many IP addresses belonged to Facebook. At first I >> thought: - 'Clever attacker. He guesses I could not be as severe as I am >> to >> regular UDP traffic if the origin was Facebook and he deliberately spoofed >> their IP address.' >> >> But one of my collegues quickly realized the incoming MAC ADDRESS was the >> actual Facebook router we have a peering at a internet exchange. So indeed >> the traffic came from their network. >> > > one wonders if this is the new (ish?) Streaming thingy they launched? >
Re: any known outage in BR?
Hello, Do you mean Brazil? Can you provide further details, traceroute, IPs etc.? Best Regards, Kurt Kraut 2017-05-11 12:34 GMT-03:00 T Kawasaki via NANOG : > does anyone know of any outage in BR, perhaps associate ATT? >
How can I obtain the abuse e-mail address for IPs from Japan?
Hello, I'm having a hard time to figure out the abuse e-mail address for IPs from Japan. Any query I perform at the WHOIS, for any IP, from any autonomoyus system I get the same e-mail addresses: ab...@apnic.net hm-chan...@apnic.net ip-ap...@nic.ad.jp hostmas...@nic.ad.jp These e-mail addresses belong to JPNIC, not the autonomous system itself. So any messages sent to these e-mail addresses will not reach the offending NOC/SOC so I can report vulnerabilities and DDoS attacks. What am I missing and how should I report security issues to autonomous systems from this region? Has anyone here any experience on this? Thanks in advance, Kurt Kraut
Re: How can I obtain the abuse e-mail address for IPs from Japan?
Hello Suresh, It doesn't seem to help a lot: ktk@ktk:~$ whois -h whois.nic.ad.jp 59.106.13.181 [ JPNIC database provides information regarding IP address and ASN. Its use ] [ is restricted to network administration purposes. For further information, ] [ use 'whois -h whois.nic.ad.jp help'. To only display English output, ] [ add '/e' at the end of command, e.g. 'whois -h whois.nic.ad.jp xxx/e'. ] Network Information: a. [Network Number] 59.106.12.0-59.106.27.255 b. [Network Name] SAKURA-NET g. [Organization] SAKURA Internet Inc. m. [Administrative Contact] KT749JP n. [Technical Contact] KW419JP p. [Nameserver] ns1.dns.ne.jp p. [Nameserver] ns2.dns.ne.jp [Assigned Date] 2004/11/24 [Return Date] [Last Update] 2004/11/24 18:41:02(JST) Less Specific Info. -- SAKURA Internet Inc. [Allocation] 59.106.0.0/16 More Specific Info. No e-mail addresses of the abuse team or NOC or SOC. Best regards, Kurt Kraut 2017-08-23 11:55 GMT-03:00 Suresh Ramasubramanian : > whois -h whois.nic.ad.jp IP /e > > --srs > > > On 23-Aug-2017, at 7:38 PM, Kurt Kraut wrote: > > > > Hello, > > > > > > I'm having a hard time to figure out the abuse e-mail address for IPs > from > > Japan. Any query I perform at the WHOIS, for any IP, from any autonomoyus > > system I get the same e-mail addresses: > > > > ab...@apnic.net > > hm-chan...@apnic.net > > ip-ap...@nic.ad.jp > > hostmas...@nic.ad.jp > > > > These e-mail addresses belong to JPNIC, not the autonomous system itself. > > So any messages sent to these e-mail addresses will not reach the > offending > > NOC/SOC so I can report vulnerabilities and DDoS attacks. > > > > What am I missing and how should I report security issues to autonomous > > systems from this region? Has anyone here any experience on this? > > > > > > Thanks in advance, > > > > > > Kurt Kraut >
Re: How can I obtain the abuse e-mail address for IPs from Japan?
Hello folks, Thank you for your assistance. I'm used to query AS entries for LACNIC region and their WHOIS spit out righ away all contacts. I didn't realise I had to make a secondary query for the Technical Contact ID to only then see the e-mail address. Best regards, Kurt Kraut 2017-08-23 12:52 GMT-03:00 Andrew Latham : > Kurt > > I see contact info for KW419JP maybe I don't understand what you are > looking for. > > On Wed, Aug 23, 2017 at 10:16 AM, Kurt Kraut wrote: > >> Hello Suresh, >> >> >> It doesn't seem to help a lot: >> >> ktk@ktk:~$ whois -h whois.nic.ad.jp 59.106.13.181 >> [ JPNIC database provides information regarding IP address and ASN. Its >> use >> ] >> [ is restricted to network administration purposes. For further >> information, ] >> [ use 'whois -h whois.nic.ad.jp help'. To only display English output, >>] >> [ add '/e' at the end of command, e.g. 'whois -h whois.nic.ad.jp xxx/e'. >>] >> >> Network Information: >> a. [Network Number] 59.106.12.0-59.106.27.255 >> b. [Network Name] SAKURA-NET >> g. [Organization] SAKURA Internet Inc. >> m. [Administrative Contact] KT749JP >> n. [Technical Contact] KW419JP >> p. [Nameserver] ns1.dns.ne.jp >> p. [Nameserver] ns2.dns.ne.jp >> [Assigned Date] 2004/11/24 >> [Return Date] >> [Last Update] 2004/11/24 18:41:02(JST) >> >> Less Specific Info. >> -- >> SAKURA Internet Inc. >> [Allocation] >> 59.106.0.0/16 >> >> More Specific Info. >> >> >> >> No e-mail addresses of the abuse team or NOC or SOC. >> >> >> Best regards, >> >> >> Kurt Kraut >> >> 2017-08-23 11:55 GMT-03:00 Suresh Ramasubramanian : >> >> > whois -h whois.nic.ad.jp IP /e >> > >> > --srs >> > >> > > On 23-Aug-2017, at 7:38 PM, Kurt Kraut wrote: >> > > >> > > Hello, >> > > >> > > >> > > I'm having a hard time to figure out the abuse e-mail address for IPs >> > from >> > > Japan. Any query I perform at the WHOIS, for any IP, from any >> autonomoyus >> > > system I get the same e-mail addresses: >> > > >> > > ab...@apnic.net >> > > hm-chan...@apnic.net >> > > ip-ap...@nic.ad.jp >> > > hostmas...@nic.ad.jp >> > > >> > > These e-mail addresses belong to JPNIC, not the autonomous system >> itself. >> > > So any messages sent to these e-mail addresses will not reach the >> > offending >> > > NOC/SOC so I can report vulnerabilities and DDoS attacks. >> > > >> > > What am I missing and how should I report security issues to >> autonomous >> > > systems from this region? Has anyone here any experience on this? >> > > >> > > >> > > Thanks in advance, >> > > >> > > >> > > Kurt Kraut >> > >> > > > > -- > - Andrew "lathama" Latham - >
Re: Carrier IRR Update Frequency
Hello, Seabone/LANautilus/TI Sparkle (AS6762), an italian Tier-1 with strong footprint in Latin America updates it once a day at 06:00 AM at Milan time. If I recall correctly, only during business days. Works like a charm. Best regards, Kurt Kraut 2018-01-01 14:17 GMT-02:00 Mike Hammett : > Any idea how often Cogent, XO, and Level 3 update their prefix filters > from the IRRDBs? > > > > > - > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com >
Any IP Transit provider currently offering BGP FlowSpec?
Hello, I'm looking for an IP Transit provider (in the Americas region preferrably) that provides BGP FlowSpec capabilities. I've found some that accept filtering rules at the IP Transit level but changes are done by support ticket, which is subpar to me. I must have autonomy to change rules at will. Could anyone mention known providers publically? If you work for an IP Transit provider, feel free to contact me privately/directly. Best regards, Kurt Kraut
Re: GVT Brazil - contact
Hi, Based on the phone numbers you provided (+55) you are in Brazil. I'm pretty sure nobody from the telephony departament of a big telco will step up and try to help will. In fact, by the company policies, they are forbidden to provide help outside the company offical channels. Probably your e-mail is motivated as an act of despair. You must do it through the official channels. First, register a formal complaint through the GVT call center. Then pick up the protocol number and present it to ANATEL, the government agency that controls telecommunications. ANATEL cannot act if you don't provide them the protocol number of your complain already registered at GVT. If you complaint is valid and if the company exceeded the max number of days to complete an instalation or the service is malfunctioning ANATEL will give the company more 5 days to fix the problem or the company will be fined. As soon as they get warned by the goverment agency you filed a official complain the'll you contact you really willing to fix the issue to not get the fine. Just follow these instructions: http://www.anatel.gov.br/consumidor/saiba-como-reclamar-de-sua-operadora (pt-br_. Best regards, Kurt Kraut 2014-07-03 13:10 GMT-03:00 Oliver Doug : > There are anyone up there from GVT Brazil who are able to contact me inbox? > Having some issues to hire a fixed phone number plan to a customer. > > Cheers, > > Douglas S. Oliveira > Eletel Telecom > +55 19 9 8182-8816 > +55 19 9 9915-0538 > >
Is there a DNS lookup, traceroute, ping and HTTP GET as a service?
Hi, I'm evaluating different datacenters and vendors accross the globe and it isn't worthy to perform tests like DNS, traceroute, ping and HTTP GET from my office. I need to be able to perform this tests remotely, from multiple endpoints. The only company I know allow such thing is ThousandEyes, but it is brutally and inexplicably expensive and doesn't fit perfectly to what I'm looking for. It has a paradigm I'm willing to monitor 24x7 specific targets from multiple points of view. I need to make tests on demand, on different targets and URLs. Does anyone know such service, DNS lookup, traceroute, ping and HTTP GET as a service from multiple nodes geographically spread? Thanks in advance, Kurt Kraut
Re: Is there a DNS lookup, traceroute, ping and HTTP GET as a service?
Hi, Thank you for the quick replies. Sorry for not being clear enough: I need it to have an API so I can integrate it with my own solution, generate my own metrics. So looking glasses are pretty much useless: they don't support HTTP GET and DNS lookup (usually) and the parsing for so many different HTML or telnet sources would be very time consuming. Also I've seen many looking glasses with captchas to halt these intents. So I need a SaaS with an API for these tests. About RIPE ATLAS, I already have one of their boxes and it never worked. Simply doesn't appear as online. Their support just barely gave me some tips but with no meaningful result. I need something reliable and I'm willing to pay for this service. RIPE Atlas falls in the category of 'best effort'. Best regards, Kurt Kraut 2015-11-18 14:32 GMT-02:00 William Herrin : > On Wed, Nov 18, 2015 at 11:28 AM, Kurt Kraut via NANOG > wrote: > > I'm evaluating different datacenters and vendors accross the globe and it > > isn't worthy to perform tests like DNS, traceroute, ping and HTTP GET > from > > my office. I need to be able to perform this tests remotely, from > multiple > > endpoints. > > For common tests like ping and traceroute, google "ip looking glass". > There are a lot of them in a lot of locations, all free to use. > > -Bill > > > -- > William Herrin her...@dirtside.com b...@herrin.us > Owner, Dirtside Systems . Web: <http://www.dirtside.com/> >
Is RouteViews dead? Is there any alternatives?
Hi, For the past couple of months I've been attempting to add new Autonomous Systems to the RouteViews project and got no response. Talking to other AS in my area, I wasn't able to find no new BGP operator that got a response from them since July. Is RouteViews dead? If the answer is yes, it is sad. It is the most used resource about the internet routing for multiple perspectives. Is there any other similar project that I could colaborate providing the point of view of my routers have of the internet? Best regards, Kurt Kraut
Internet Exchanges supporting jumbo frames?
Hi, I'm trying to convince my local Internet Exchange location (and it is not small, exceed 1 terabit per second on a daily basis) to adopt jumbo frames. For IPv6 is is hassle free, Path MTU Discovery arranges the max MTU per connection/destination. For IPv4, it requires more planning. For instance, two datacenters tend to exchange relevant traffic because customers with disaster recovery in mind (saving the same content in two different datacenters, two different suppliers). In most cases, these datacenters are quite far from each other, even in different countries. In this context, jumbo frames would allow max speed even the latency is from a tipical international link. Could anyone share with me Internet Exchanges you know that allow jumbo frames (like https://www.gr-ix.gr/specs/ does) and how you notice benefit from it? Best regards, Kurt Kraut
Re: Internet Exchanges supporting jumbo frames?
2016-03-09 11:45 GMT-03:00 Nick Hilliard : > this has been tried before at many ixps. No matter how good an idea it > sounds like, most organisations are welded hard to the idea of a 1500 > byte mtu. Even for those who use larger MTUs on their networks, you're > likely to find that there is no agreement on the mtu that should be > used. Some will want 9000, some 9200, others 4470 and some people > will complain that they have some old device somewhere that doesn't > support anything more than 1522, and could everyone kindly agree to that > instead. > Hi Nick, Thank you for replying so quickly. I don't see why the consensus for an MTU must be reached. IPv6 Path MTU Discovery would handle it by itself, wouldn't it? If one participant supports 9k and another 4k, the traffic between them would be at 4k with no manual intervention. If to participants adopts 9k, hooray, it will be 9k thanks do PMTUD. Am I missing something? Best regards, Kurt Kraut
Re: Internet Exchanges supporting jumbo frames?
Hi Mike, The adoption of jumbo frames in a IXP doesn't brake IPv4. For an ISP, their corporate and residencial users would still use 1,5k. For datacenters, their local switches and servers are still set to 1,5k MTU. Nothing will brake. When needed, if needed and when supported, from a specific server, from a specific switch, to a specific router it can raise the MTU up to the max MTU supported by IXP if the operator know the destination also supports it, like in the disaster recovery example I gave. For IPv6, the best MTU will be detected and used with no operational effort. For those who doesn't care about it, an IXP adopting jumbo frames wouldn't demand any kind of change for their network. They just set their interfaces to 1500 bytes and go rest. For those who care like me can take benefit from it and for that reason I see no reason for not adopting it. Best regards, Kurt Kraut 2016-03-09 11:53 GMT-03:00 Mike Hammett : > Maybe breaking v4 in the process? > > > > > - > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > Midwest Internet Exchange > http://www.midwest-ix.com > > > - Original Message - > > From: "Kurt Kraut via NANOG" > To: "Nick Hilliard" > Cc: "NANOG list" > Sent: Wednesday, March 9, 2016 8:50:23 AM > Subject: Re: Internet Exchanges supporting jumbo frames? > > 2016-03-09 11:45 GMT-03:00 Nick Hilliard : > > > this has been tried before at many ixps. No matter how good an idea it > > sounds like, most organisations are welded hard to the idea of a 1500 > > byte mtu. Even for those who use larger MTUs on their networks, you're > > likely to find that there is no agreement on the mtu that should be > > used. Some will want 9000, some 9200, others 4470 and some people > > will complain that they have some old device somewhere that doesn't > > support anything more than 1522, and could everyone kindly agree to that > > instead. > > > > > > Hi Nick, > > > Thank you for replying so quickly. I don't see why the consensus for an MTU > must be reached. IPv6 Path MTU Discovery would handle it by itself, > wouldn't it? If one participant supports 9k and another 4k, the traffic > between them would be at 4k with no manual intervention. If to participants > adopts 9k, hooray, it will be 9k thanks do PMTUD. > > Am I missing something? > > > Best regards, > > > Kurt Kraut > >
Re: Internet Exchanges supporting jumbo frames?
Hello folks, First of all, thank you all for this amazing debate. So many important ideas were exposed here and I wish we keep going on this. I've seen many opposition to my proposal but I still remain on the side of jumbo frame adoption for IXP. I'm pretty confident there is no need for a specific MTU consensus and not all IXP participants are obligated to raise their interface MTU if the IXP starts allowing jumbo frames. One of the reasons I'm so surprised with concerns about compatibility and breaking the internet I've seen here is the offers I get from my IP transit providers: half of them offered me jumbo frame capable ports by default, it wasn't a request. When this subject became important to me and I open support tickets, half of them replied something like 'You don't need to request it. From our end the max MTU is X'. The lowest X I got was 4400 and the highest 9260 bytes. All my Tier-1 providers already provided me jumbo frames IP transit. Even my south american IP Transit provider activated my link with 9k MTU by default. So we have Tier-1 backbones moving jumbo frames around continents, why in a controlled L2 enviroment that usually resides in a single building and managed by a single controller having jumbo frames is that concerning? Best regards, Kurt Kraut 2016-03-09 19:22 GMT-03:00 Tassos Chatzithomaoglou : > I must be missing something very obvious here, because i cannot think of > any reason why an IXP shouldn't enable the maximum possible MTU on its > infrastructure to be available to its customers. Then it's clearly > customers' decision on what MTU to use on their devices, as long as: > > * It fits inside IXP's MTU > * It suits with any other customer's (exchanging traffic with) MTU > > > -- > Tassos > > Kurt Kraut via NANOG wrote on 9/3/16 16:26: > > Hi, > > > > > > I'm trying to convince my local Internet Exchange location (and it is not > > small, exceed 1 terabit per second on a daily basis) to adopt jumbo > frames. > > For IPv6 is is hassle free, Path MTU Discovery arranges the max MTU per > > connection/destination. > > > > For IPv4, it requires more planning. For instance, two datacenters tend > to > > exchange relevant traffic because customers with disaster recovery in > mind > > (saving the same content in two different datacenters, two different > > suppliers). In most cases, these datacenters are quite far from each > other, > > even in different countries. In this context, jumbo frames would allow > max > > speed even the latency is from a tipical international link. > > > > Could anyone share with me Internet Exchanges you know that allow jumbo > > frames (like https://www.gr-ix.gr/specs/ does) and how you notice > benefit > > from it? > > > > > > Best regards, > > > > > > Kurt Kraut > > > >
Re: Anycast provider for SMTP?
Ray, "Anycast is generally not well-suited for stateful connectivity (e.g. most things TCP)." I don't know anything that would support that claim. I have been using for years BGP anycast for audio and video streaming, always in TCP (RTMP, HLS, WMS, and even the good and old ShoutCast) and works like a charm. And this is the 'secret sauce' of the company I work for, the thing we do better than our competitors that make our users happy and never wanting to leave us: anycast. We have customers that are TV stations and stream 24x7x365 their content and they have watchers getting their streaming also 24x7x365 (like waiting rooms, airports) with no complaints or instability. Best regards, Kurt Kraut 2015-06-17 16:13 GMT-03:00 Ray Soucy : > Anycast is generally not well-suited for stateful connectivity (e.g. most > things TCP). The use case for anycast is restricted to simple > challenge-response protocol design. > > As such, you typically only see it leveraged for simple services (e.g. DNS, > NTP). > > The reason for this, as you suspect, is you can never guarantee that the > path and thus the server will remain consistent across client connections. > > Ideally you can leverage DNS to provide a response to a unicast resource > rather than trying to make the service itself anycast. DNS can be anycast, > and DNS can provide different responses based on geographical location, but > these can happen independently or together. > > As you still want failover, you might opt to announce the MX record with > the priorities reversed but still pointing to each server. For example MX > 10 server1, MX 20 server2 on one side, and MX 10 server2, MX 20 server1 on > the other. > > Typically you would use a DNS load balancer rather than simple anycast DNS > to achieve this though. > > > On Mon, Jun 15, 2015 at 1:50 PM, Joe Hamelin wrote: > > > I have a mail system where there are two MX hosts, one in the US and one > in > > Europe. Both have a DNS MX record metric of 10 so a bastardized > > round-robin takes place. This does not work so well when one site goes > > down. My solution will be to place a load balancer in a hosting site > > (virtual, of course) and have it provide HA. But what about HA for the > > LB? At first glance anycasting would seem to be a great idea but there > is > > a problem of broken sessions when routes change. > > > > Have any of you seen something like this work in the wild? > > > > > > -- > > Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 > > > > > > -- > Ray Patrick Soucy > Network Engineer > University of Maine System > > T: 207-561-3526 > F: 207-561-3531 > > MaineREN, Maine's Research and Education Network > www.maineren.net >
