Any AI or Data Science Projects?
Hi everyone, I am a masters student of Artificial Intelligence and Data Science at the University of Hull and I am in need of a suitable project for my final semester. Prior to studying I was heavily involved in the formation and building of an ISP network in my local area. We built out to approximately 15k customers using a mix of wireless and fibre before selling the business to a competitor in 2022. I am still very interested in all things Internet and would very much like a project within this sector. If anyone has any requirements or any ideas then please do not hesitate to contact me off list. Many thanks, Adrian. Sent from my iPhone
Re: Strange IPSEC traffic
On 11/13/23 19:10, Shawn L via NANOG wrote: Is anyone else seeing a lot of 'strange' IPSEC traffic? We started seeing logs of IPSEC with invalid spi on Friday. We're seeing it on pretty much all of our PE routers, none of which are setup to do anything VPN related. Most are just routing local customer traffic. decaps: rec'd IPSEC packet has invalid spi for destaddr=X.X.X.X, prot=50, spi=0x9D2D(2636972032), srcaddr=211.112.195.167, input interface=TenGigabitEthernet0/0/11 decaps: rec'd IPSEC packet has invalid spi for destaddr=Y.Y.Y.Y, prot=50, spi=0x1469(342425600), srcaddr=74.116.56.244, input interface=TenGigabitEthernet0/0/5 The destination address is always one of our customer's ip addresses. The source seems to be all over the place, mostly Russia, Korea, China or south east asia. It's not really impacting anything at the moment, just rather annoying. Thanks Shawn Hi Shawn, we saw a lot of syslog messages like these and the targets are cisco devices, some of witch, according to the data sheets, are not even capable of ipsec. Cisco is punting some ESP traffic to control plane on ios and ios-xe devices, regardless of the configuration. Last week somebody on the internet started a campaign to scan and perhaps to exploit some zero day ipsec vulnerabilities. This is the list of ip addresses we saw: https://pastebin.com/vrLRai9Q -- Best regards, Adrian Minta
Re: Operator survey: Incrementally deployable secure Internet routing
Hi Scott > "Do you use countries as ISDs? Doesn't that create opportunities for government intervention and censorship? > I asked about the ISDs and put a FAQ you have as an example. I didn't ask about the SBAS. It seems to me that the ingress/egress of an ISD is the place a government surveillance network would reside. All country internet communications go through a chokepoint to get on the SBAS, so it's easier to surveil the population. Especially if you envision the ISD to have its own DNS. You're referring to the FAQ on page 409 of the SCION book: https://www.scion-architecture.net/pdf/SCION-book.pdf The following question in the book is about government censorship, stating the arguments why censorship is more challenging in SCION than in today's Internet. As we have witnessed in the past, censorship has been successful in today's Internet. Note that the ISD concept represents a virtual grouping of ASes, an AS can be part of several ISDs at the same time. When you look at the ISD concept, it brings transparency and scalability rather than facilitate censorship. A recent paper shows that (partially thanks to ISDs) scalability of SCION inter-domain routing is much improved compared to BGP or BGPsec, with about 200 times lower overhead than BGP and 1000 times lower overhead than BGPsec on a per-path basis: https://netsec.ethz.ch/publications/papers/2021_conext_deployment.pdf > What will you do about space? The moon? (That one's coming sooner that folks might expect: https://www.nokia.com/networks/insights/network-on-the-moon) As for network deployments on the Moon, SCION can bring advantages there as well, for instance a "moon ISD" will make it easy to ensure that moon-to-moon packets don't inadvertently take a detour via a terrestrial router. A related result that may be of interest to the operator community is our analysis of using path-aware networking for integrating LEO satellite networks into the Internet: https://netsec.ethz.ch/publications/papers/ccr-ibis-2020.pdf > Will each ISD (ISD = Isolation Domain) have it's own DNS? The SCION DNS story has evolved much since the first book, to only use a single global name space in the current design (which is written up in the new SCION book that will go to the printer next week, ping me if you'd like to see a pre-print). All the best Adrian On Tue, Jan 25, 2022 at 2:00 AM scott wrote: > > > Hello, > > "are described in further detail in the survey" > > Doing the survey gives legitimacy to something I feel is not correct > > --- > > "We understand the privacy concern. As for SBAS, the backbone is operated > in a federated manner among PoP operators." > > I asked about the ISDs and put a FAQ you have as an example. I didn't ask > about the SBAS. It seems to me that the ingress/egress of an ISD is the > place a government surveillance network would reside. All country internet > communications go through a chokepoint to get on the SBAS, so it's easier > to surveil the population. Especially if you envision the ISD to have its > own DNS. > > scott > > > > > > On 1/22/2022 5:22 PM, Yixin Sun wrote: > > Hi Scott, > > Thank you for your comment! We understand the privacy concern. As for > SBAS, the backbone is operated in a federated manner among PoP operators. > In our current deployment, the PoP operators are located across three > continents. On the other hand, due to the federated structure of the SBAS > PoP operators, a governance structure is needed to coordinate global > operation. We have outlined four potential governance models, i.e., ICANN > and Regional Internet Registries, a multi-stakeholder organization, a > federation of network providers, or a decentralized governance model. The > four models are described in further detail in the survey, and we would > love to hear your opinions about them. > > Best, > Yixin > > On Fri, Jan 21, 2022 at 8:24 PM scott wrote: > >> >> >> >> On 1/21/2022 12:07 PM, Yixin Sun wrote: >> >> >> We appreciate that your time is very precious, but we wanted to ask you >> for your help in answering a brief survey about a new secure routing system >> we have developed in a research collaboration between ETH, Princeton >> University, and University of Virginia. We'd like to thank those of you who >> have already helped us fill out the survey and provided insightful >> feedback. Your input is critical for helping inform our further work on >> this project. >> >> Here is the link to our survey, which takes about 10 minutes to complete, >> including watching a brief 3-minute introductory video: >> >> https://docs.google.com/forms/d/e/1FAIpQLSc4VCkqd7i88y0CbJ31B7tVXyxBlhEy_zsYZByx6tsKAE7ROg/viewform?usp=pp_url=N
Re: Operator survey: Incrementally deployable secure Internet routing
Hi Laura > With the greatest of respect I'm afraid this kind of exemplifies the sort of dream-ware that can only be thought up in the cozy confines of a university campus. Indeed, that's the origin of many innovations -- and some of them do make it into the real world. > So the chances of something more drastic like your proposal ever seeing the light of day beyond some university labs? We already have a working prototype system. It's quite exciting to see how the existing SCION backbone can be used to provide immediate benefits for traditional IP end hosts. > Sorry to rain on your parade guys! No problem, thank you for your honest feedback! It is very important to gather these opinions / viewpoints. All the best Adrian On Mon, Jan 24, 2022 at 10:32 PM Laura Smith via NANOG wrote: > ‐‐‐ Original Message ‐‐‐ > > On Friday, January 21st, 2022 at 22:07, Yixin Sun < > yix...@alumni.princeton.edu> wrote: > > > Dear Nanog, > > > > We appreciate that your time is very precious, but we wanted to ask you > for your help in answering a brief survey about a new secure routing system > we have developed in a research collaboration between ETH, Princeton > University, and University of Virginia. > > > Prateek, Adrian, and Yixin, > > With the greatest of respect I'm afraid this kind of exemplifies the sort > of dream-ware that can only be thought up in the cozy confines of a > university campus. > > Why do I say this ? > > Because the first thing that I thought of when I read the subject line of > your email and a cursory glance through the body was "Uh huh, I've heard > this sort of thing somewhere before", and that somewhere was > > IPv6 was sold as "incrementally deployable", and with IPv6 we're talking > something natively dual-stack operating over the same old "internet". > > And look where we are today ? A decade or so on and the world is still > nowhere near 100% IPv6 coverage, with some major networks still not > anywhere near, and with other major networks only just launching IPv6 (e.g. > the hyperscalers ... or at least some of them). And that's before we start > considering the developing world. > > Or if we put IPv6 to one side. Why do you think BGP is *still* so > stubbornly here ? Because it works (most of the time), everyone knows how > it works, and its been battle tested. > > So the chances of something more drastic like your proposal ever seeing > the light of day beyond some university labs ? > > Sorry to rain on your parade guys ! > > Laura > > >
Incrementally deployable secure Internet routing: operator survey
Dear Nanog, Knowing how challenging it is to apply new technologies to current networks, in a collaboration between ETH, Princeton University, and University of Virginia, we constructed a system that provides security benefits for current Internet users while requiring minimal changes to networks. Our design can be built on top of the existing Internet to prevent routing attacks that can compromise availability and cause detrimental impacts on critical infrastructure – even given a low adoption rate. This provides benefits over other proposed approaches such as RPKI that only protects a route’s origin first AS, or BGPsec that requires widespread adoption and significant infrastructure upgrades. Our architecture, called Secure Backbone AS (SBAS), allows clients to benefit from emerging secure routing deployments like SCION by tunneling into a secure infrastructure. SBAS provides substantial routing security improvements when retrofitted to the current Internet. It also provides benefits even to non-participating networks and endpoints when communicating with an SBAS-protected entity. Our ultimate aim is to develop and deploy SBAS beyond an experimental scope. We have designed a survey to capture the impressions of the network operator community on the feasibility and viability of our design. The survey is anonymous and takes about 10 minutes to complete, including watching a brief 3-minute introductory video. https://docs.google.com/forms/d/e/1FAIpQLSc4VCkqd7i88y0CbJ31B7tVXyxBlhEy_zsYZByx6tsKAE7ROg/viewform?usp=pp_url=NANOG+mailing+list We thank you for helping inform our further work on this project. We will be happy to share the results with the community. With kind regards Prateek Mittal, Adrian Perrig, Yixin Sun
Re: [External] Re: Anyone else getting the 'spam' bomb threat?
On Tue, Oct 19, 2021, at 16:00, Hunter Fuller via NANOG wrote: > We have a distinct abuse address (not just abuse@) and that is where > the messages were sent. > > We didn't receive the bomb threat ones. We only received the (somewhat > more amusing) messages entitled "Your network has been PWNED" and > "Fuck you". Hi, We got the same here at France-IX. It was on friday 15th. Hopefully, they "PWNED" all our Cisco and Mikrotik routers (of which we have none). > The situation loses its humor entirely with the introduction of bomb > threats. Seems like a script kiddie taking things way too far. I heard that yesterday (19th) evening there was law enforcement deployment and evacuation in the area of a major Paris (FR, EU) telco hotel, apparently due to "threats to a business in the area". Details (popcorn) on FrNOG (in french) : https://www.mail-archive.com/frnog@frnog.org/msg67540.html
Re: massive facebook outage presently
https://www.youtube.com/watch?v=gmk673M5BoA On 10/4/21 7:03 PM, Eric Kuhnke wrote: https://downdetector.com/status/facebook/ <https://downdetector.com/status/facebook/> Normally not worth mentioning random $service having an outage here, but this will undoubtedly generate a large volume of customer service calls. Appears to be failure in DNS resolution. -- Best regards, Adrian Minta
Re: Alien waves
On Tue, Jul 20, 2021, at 22:44, Saku Ytti wrote: > I'm going to hazard a guess that the exhaustive list is empty. Actually, it's not empty. I know 2 operators in my part of the world that do it in some way or another. > Allowing 3rd parties to launch alien waves to your system puts your existing > waves at the mercy of the 3rd party, power or lack thereof from the There are issues and there are solutions. It's just the solutions may not match the intended price-tag for the desired service (mostly thinking to long-distance alien waves - a.k.a spectrum or channels band - where entry point is very high).
Re: NDAA passed: Internet and Online Streaming Services Emergency Alert Study
On Fri, Jan 1, 2021, at 23:12, Matt Hoppes wrote: > How would that even work? Force a pop up into web traffic? What if > the end users is using an app on a phone? Like any other "commission-based study". Remember, the action is : "after providing public notice and opportunity for comment, the Commission shall complete an inquiry to examine the feasibility" Any eventual action requiring intervention of the operators (access or service) is not yet defined, and will follow at a later date (if ever).
Re: Unexplainable router log entries mentioning IPSEC from Yahoo IPs
=203.84.212.20 Dec 18 02:49:16: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr= prot=50 spi=0x4CF4BE5D(1291107933) srcaddr=203.84.212.51 Dec 18 02:45:59: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr= prot=50 spi=0x4CF4BE5D(1291107933) srcaddr=66.196.91.232 Dec 18 02:42:21: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr= prot=50 spi=0x4CF4BE5D(1291107933) srcaddr=203.84.212.23 Dec 18 02:33:05: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr= prot=50 spi=0x4CF4BE5D(1291107933) srcaddr=203.84.212.37 Dec 18 02:30:46: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr= prot=50 spi=0x4CF4BE5D(1291107933) srcaddr=203.84.212.50 Dec 18 02:23:02: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr= prot=50 spi=0x4CF4BE5D(1291107933) srcaddr=203.84.212.20 Dec 18 00:57:45: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr= prot=50 spi=0x4CF4BE5D(1291107933) srcaddr=203.84.212.50 Dec 17 17:06:12: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr= prot=50 spi=0x4CF4BE5D(1291107933) srcaddr=68.180.160.18 Dec 17 14:45:06.899: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr= prot=50 spi=0x4CF4BE5D(1291107933) srcaddr=68.180.160.34 Dec 17 16:38:03: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr= prot=50 spi=0x4CF4BE5D(1291107933) srcaddr=203.84.212.37 Dec 17 16:28:13: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr= prot=50 spi=0x4CF4BE5D(1291107933) srcaddr=203.84.212.40 Dec 17 16:24:06: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr= prot=50 spi=0x4CF4BE5D(1291107933) srcaddr=68.180.160.99 Dec 17 15:14:03: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr= prot=50 spi=0x4CF4BE5D(1291107933) srcaddr=68.180.160.40 Dec 17 15:06:40: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr= prot=50 spi=0x4CF4BE5D(1291107933) srcaddr=68.180.160.100 Dec 17 08:57:00: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr= prot=50 spi=0xEF7ED795(4018067349) srcaddr=68.180.160.23 Dec 17 08:25:36: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr= prot=50 spi=0xEF7ED795(4018067349) srcaddr=68.180.160.104 Dec 17 08:11:54: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr= prot=50 spi=0xEF7ED795(4018067349) srcaddr=68.180.160.19 Dec 17 07:22:22: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr= prot=50 spi=0xEF7ED795(4018067349) srcaddr=203.84.212.55 Dec 17 06:18:55: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr= prot=50 spi=0xEF7ED795(4018067349) srcaddr=68.180.160.20 Dec 17 06:14:35: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr= prot=50 spi=0xEF7ED795(4018067349) srcaddr=203.84.212.36 Dec 17 06:13:05: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr= prot=50 spi=0xEF7ED795(4018067349) srcaddr=203.84.212.17 Dec 17 05:36:24: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr= prot=50 spi=0xEF7ED795(4018067349) srcaddr=203.84.212.53 Dec 17 01:56:17: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr= prot=50 spi=0xEF7ED795(4018067349) srcaddr=68.180.160.17 Dec 17 03:27:47: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr= prot=50 spi=0xEF7ED795(4018067349) srcaddr=203.84.212.34 -- Best regards, Adrian Minta
Re: Hurricane Electric AS6939
On Wed, Oct 14, 2020, at 22:40, Darin Steffl wrote: > For 1G or less, ethernet > might be cheaper with some protection already Not to mention that 1G waves are becoming less and less comon those days. In this part of the world waves tend to start at 10G.
Re: Cogent Layer 2
On Wed, Oct 14, 2020, at 20:38, Rod Beck wrote: > You are correct that if you have > to carve it up into a lots of VLANs, it would be a nightmare. But > Hibernia was a true wholesale carrier providing backbone to clients, > not links distributing traffic to lots of user end points. The fact that there was a "switched Ethernet" commercial service doesn't mean that the underlying transport was really "switched ethernet" end-to-end. Ethernet over MPLS is a VERY old concept (VLL, VPWS, VPLS, lately EVPN), and these days Ethernet over VXLAN is becoming more and more popular (mostly EVPN). A carrier using a pure, unencapsulated, end-to-end ethernet for transport over 1000s of km is (and was for at least 15 years) a disaster waiting to happen. Almost all ethernet services (switched, not switched or otherwise) use some form of encapsulation (IP or MPLS, see above) these days.
RE: sr - spring - what's the deal with 2 names
>> Does anyone know the scope on why we have 2 names for this ? > > SPRING is the IETF working group name - Source Packet Routing in Networking > Segment Routing is under SPRING Yeah, sorry, this was my fault. Gotta have a catchy name. As to "SPRINGv4" as others have said, this is not a recognised term in the IETF. I can think of it meaning a number of things (ranging from a private invention of SRv4, up to RFC 8663). You're going to have to check with the vendor using the term to find out what they mean, and possibly why they are using a new term instead of an existing one. Cheers, Adrian
Re: sr - spring - what's the deal with 2 names
On Thu, Sep 10, 2020, at 08:08, aar...@gvtc.com wrote: > Interesting... I've never heard of SPRINGv4 Neither did I until a few days ago. > I wonder if SPRINGv4 is like SRv6, meaning, SPRING(SR) over IPv4 dataplane? > Or, am I reading way too much into that SPRINGv4 acronym? Like SR-VXLAN ? Does it even make any sense?
Re: sr - spring - what's the deal with 2 names
On Sun, Sep 6, 2020, at 10:14, Jeff Tantsura via NANOG wrote: > Out of curiosity - if you are interested in SR, where are you getting > your information from if not IETF (SPRING)? Much beloved vendor claims support for "SPRINGv4" feature for a certain family of products (I personally expect something like SR, SR-MPLS or SRv6, definitely not SPRING). Very big WTF, especially that that term is only found on 2 public pages : product family datasheet (PDF and HTML versions).
Re: Bottlenecks and link upgrades
On Sat, Aug 15, 2020, at 11:35, Baldur Norddahl wrote:
> No plan survives contact with the enemy. Your careful made growth
> projection was fine until the brass made a deal with some major
> customer, which caused a traffic spike.
Capacity planning also includes keeping an eye on what is being sold and what
is being prepared.
Having the traffic more than double within a 48h timespan (until day X peak at
N Gbps, after days X+2, peaks at 2.5*N Gbps) -> done with success when the
correct information ("partner X will change delivery system") arrived 4 months
in advance.
Having multiple 200 Mbps and 500 Mbps connections over an already-used 1 Gbps
port and pretending that "everything's gonna be allright" , in that case you
should confront your enemy.
> Or any infinite other events that could and eventually will happen to you.
Among which you try to protect yourself against the most realistic ones.
> One hard thing, that almost everyone will get wrong at some point, is
> simulating load in the event multiple outages takes some links out,
> causing excessive traffic to reroute unto links that previously seemed
> fine.
You should scale the network to absorb a certain degree of "surprise"/damage,
and clearly explain that beyond that certain level, service will be degraded
(or even absent) and there is nothing that can and nothing that will be done
immediately.
Every network fails at a certain moment in time. You just need to make sure you
know how to make it working again, within a reasonable time frame. Or have a
good run-away plan (sometimes this is the best solution).
Re: Bottlenecks and link upgrades
On Sat, Aug 15, 2020, at 02:39, Louie Lee wrote: > get an understanding of your traffic growth and try to project when you > will reach that number. You have to decide whether you care about the > occasional peak, or the consistent peak, or somewhere in between, like > weekday vs weekends, etc. Now you know how much lead time you will have. Get an understanding, and try to make a plan on the longer term (like 2-3 years) if you can. If you're reaching some important milestones (e.g need to buy expensive hardware), make a presentation for the management. You will definitely need adjustments, during the timespan covered (some things will need to be done sooner, others may leave you some extra time) but it should reduce the amount of surprise. That is valid if you have visibility. If you don't (that may happen), the cheatsheet I described previously is a good start. It could be applied at $job[-1], where I applied it to grow the network from almost zero to 35 Gbps, and it is kind of applied at $job[$now] where long term visibility is kind of missing and we need to be ready for rapid capacity variations. > And sometimes, if you need a low latency connection, traffic > utilization levels might not even be something you look at. This goes to the "understand your traffic" chapter. All the traffic (sine sometimes there may be a mix, e.g. regular eyeball traffic + voice traffic).
Re: Bottlenecks and link upgrades
On Thu, Aug 13, 2020, at 12:31, Mark Tinka wrote: > I'm confident everyone (even the cheapest CFO) knows the consequences of > congesting a link and choosing not to upgrade it. I think you're over-confident. > It's great to monitor packet loss, latency, pps, e.t.c. But packet loss > at 10% link utilization is not a foreign occurrence. No amount of > bandwidth upgrades will fix that. That, plus the fact that by the time delay becomes an indication of congestion, it's way too late to start an upgrade. That event should not occur.
Re: Bottlenecks and link upgrades
On Wed, Aug 12, 2020, at 09:31, Hank Nussbacher wrote: > At what point do commercial ISPs upgrade links in their backbone as > well as peering and transit links that are congested? At 80% capacity? > 90%? 95%? Some reflections about link capacity: At 90% and over, you should panic. Between 80% and 90% you should be (very) scared. Between 70% and 80% you should be worried. Between 60% and 70% you should seriously consider speeding up the upgrades that you effectively started at 50%, and started planning since 40%. Of course, that differs from one ISP to another. Some only upgrade after several months with at least 4 hours a day, every day (or almost) at over 95%. Others deploy 10x expected capacity, and upgrade well before 40%.
Re: Product for heat containment per rack unit?
https://objects.eanixter.com/PD317813.PDF On 8/13/20 9:26 PM, David Hubbard wrote: Curious if anyone has knowledge of a vendor / product designed to make it possible to use back-to-front cooled equipment in racks that need to be ‘sealed’ for heat containment reasons? I’d envision this looking like some kind of adjustable depth sleeve, to get the cold air to the equipment, and perhaps a brush strip opening to allow power cables in? Thanks! -- Best regards, Adrian Minta
Re: L2VPN/L2transport, Cumulus Linux & hardware suggestion
On Wed, Jul 8, 2020, at 00:09, Adam Thompson wrote: > Good luck with tunnelling LACP, no matter what boxes you have - LACP > has (de facto) hard jitter requirements of under 1msec, or you'll be > getting TCP resets coming out your ears due to mis-ordered packets. Errr sorry, but at the latest news, TCP was supposed to handle out of order packets and reorder them before sending them to upper layer. Not to mention hashing that almost systematically makes that all packets of the same TCP stream will be sent on the same link in an LAG (also on most if not all ECMP implementations). > Miktotik > "carrier-grade" .
Re: Hurricane Electric has reached 0 RPKI INVALIDs in our routing table
Hi, On Thu, Jun 18, 2020, at 04:01, Jon Lewis wrote: > > Just like I said, if you create an ROA for an aggregate, forgetting that > you have customers using subnets of that aggregate (or didn't create ROAs > for customer subnets with the right origin ASNs), you're literally telling > those using RPKI to verify routes "don't accept our customers' routes." > That might not be bad for "your network", but it's probably bad for > someone's. That makes you a bad upstream operator, one that does things without understanding the consequences. This may still be the unfortunate norm, but it's by no means something to be considered an acceptable state. Put otherwise : if you have downstream customers that you allow to announce part of your address space in the GRT, make sure you can still provide the service after doing changes (like RPKI signing). Put in a yet another way : if you lease IP space (with or without connectivity), make sure all the additional services are included in a way or another. Those services should include RPKI signing and reverse DNS, and the strict minimum (only slightly better than not doing it at all) should be via "open a service ticket"; the more automated the better.
Re: Devil's Advocate - Segment Routing, Why?
On Fri, Jun 19, 2020, at 10:11, Mark Tinka wrote: > > On 19/Jun/20 09:20, Radu-Adrian Feurdean wrote: > > > > A whole ocean of "datacenter" hardware, from pretty much evey vendor. > > You mean the ones deliberately castrated so that we can create a > specific "DC vertical", even if they are, pretty much, the same box a > service provider will buy, just given a darker color so it can glow more > brightly in the data centre night? Yes, exactly that one. Which also happens to spill outside the DC area, because the main "vertical" allows it to be sold at lower prices.
Re: Devil's Advocate - Segment Routing, Why?
On Wed, Jun 17, 2020, at 20:40, Dave Bell wrote: > > I don't understand the point of SRv6. What equipment can support IPv6 > routing, but can't support MPLS label switching? A whole ocean of "datacenter" hardware, from pretty much evey vendor. Because many of them automatically link MPLS to RSVP and IPv4 L3VPN (which may still be an interesting feature in datacenter), many try to stay as far away from it as possible. Othen than some scared C-level guys imposing this, I don't really see a good reason (lack of market demand, which is sometimes invoked, doesn't stand). > where needed. LDP-SR interworking is pretty simple. Mapping servers or something else ?
Re: LDPv6 Census Check
On Wed, Jun 10, 2020, at 20:51, Mark Tinka wrote: > Well, according to them, SRv6 is winning customers over, and nobody > wants LDPv6. Then again, they have LDPv6 in IOS XR; figures. Well, given their (Cisco's) braindead policy regarding non-implementation of LDPv6 on XE, no wonder people are looking for alternatives, and SRv6 is one of them. And don't forget SRv6 is also heavily associated (marketing-wise) with 5G Back to our friends and their policy: It happens that in certain regions of the world, if you want to be an ISP other than the "establishment" (== incumbent + "first alternatives" that started 20-25 years ago), you MUST have LNS (if you want to stay in business). If like many, you are kind of stuck with Cisco because it's Cisco, the only decent solution to have LNS is ASR1K (running XE). Also add ASR920 which has a number of uses. Also, in order to stay in business, you may want to offer L3VPN services, which brings you to doing MPLS. You say MPLS, you say LDP, and there you go, your backbone remains v4-based for the next eternity. There also seems to be a lack of global vision. Tyry to ask your favourite vendor what do you need in order to be able to offer IPv4-L3VPN, IPv6-L3VPN and L2VPN (mainly point-to-point - NO MAC learning) over a backbone that does NOT use any single IPv4 address (backbone-side). Because you can do it on a backbone that does not use any single IPv*6* address, but you may want to go forwards, not backwards. Add a LNS in the mix (the v4 addresses for the LNS go in VRFs - that's not backbone). Add a money, rack space and power needed constraints in the mix. This exercise looks challenging with other vendors too, but with Cisco it's just impossible. Of course, Cisco says there is no demand for one simple reason : the people talking with Cisco account managers (or whatever they are called) are only rarely those that care about technical stuff. They may want some features on the CPEs (like "ui uant SDWAN"), but for anything else (including backbone equipment) they only want lower prices. You end up with everybody having to deal with a specific platform in real life to dream about a specific feature, yet the vendor to consider that "nobody wants it".
Re: IS-IS on FRR - Is Anyone Running It?
On Mon, Apr 6, 2020, at 10:58, Mark Tinka wrote: > Within our core, we run 9,178 bytes (which translates to 9,192 bytes on > Junos and IOS XR), to support the transport of Jumbo frames for Beware of bad dog^H^H^H NCS model. On NCS5000 (don't know about 5500 - those arrived months after me leaving $job[-1]) you will get the nasty surprise of discovering that they have some limits to 9150(IP)/9164(eth), even if you can set the mtu higher (to an unusable 9192 or 92zz bytes).
Re: IS-IS on FRR - Is Anyone Running It?
On Mon, Apr 6, 2020, at 07:51, Saku Ytti wrote: > I'm not sure what 'globally our IS-IS domain runs 8000 bytes' means. > Your LSP MTU is like 1492B, there isn't a mechanism to fragment and > reassemble LSP in-transit. ISIS network doesn't support different MTU > sizes and I've not heard anyone being brave enough to increase LSP MTU > above 1492B. I won't speak for Mark, but NO, when you're carrying somebody's else's traffic you do your best to have the MTU on each and every backbone link "high enough" : preferably in the 9200(bytes) range, so you can easily transport 9000(bytes) client packets, and by no means so small that you need to fragment 1500(IP)/1514(Eth) byte packets. If things are really-really bad, 1600 bytes towards the edge. > The only thing that is larger in your network is hellos, and I'm not > even sure how that works, considering 802.3 cannot signal larger > frames than 1500B. Ethernet cannot signal MTU. But if you have equipment at both sides of a P2P link, you don't need any signalling. You check the MTU suits your needs and put it in statically. Same for NNIs : the MTU is signalled in a document called "contract" or "agreement". And no, the guy that is being woken up at 3am for an issue, if he/she doesn't know that we run Jumbo, then he/she should start updating the CV. Back to the original question, I would expect FRR to be able to manually specify a MTU/frame-size, like any other decent NOS (even if it's not a full NOS).
Re: COVID-19 vs. peering wars
On Fri, Mar 20, 2020, at 20:31, Matthew Petach wrote: > Netflix, Amazon Prime, Youtube, Hulu, and other video > streaming services cut their bit rates down? > > https://www.bbc.com/news/technology-51968302 > https://arstechnica.com/tech-policy/2020/03/netflix-and-youtube-cut-streaming-quality-in-europe-to-handle-pandemic/ > > It seems that perhaps the fingers, and the regulatory > hammer, are being pointed in the wrong direction at There was not regulation for that. There were some politicians crying out and loud in the media that streaming platforms should reduce bit-rates. Netflix took the opportunity to try (sooner than initially scheduled) new compression schemes/algorithms on their platform. Further, they took the opportunity to say "everything is OK, the new stuff will be deployed full-scale around Europe". In parallel, other streaming platforms took their measures, some of them as simple as "default is one level lower" (720p instead of 1080p, or even 480p instead of 720p). That went as far as platforms that would never be named explicitly by any "responsible" politician (like pornhub and sorts). Chances are the results of the "bitrate reduction" will end up in the US pretty soon. Netflix are also insisting on the fact that it's not a quality reduction, just new compression allowing for lower bitrates over the wire. The French regulator is even very decent in this respect, the official message being : "situation is overall good, in the rare cases and places where there are issues operators will do heir job to fix the issues". In general, there are no new issues, just probably more people realising the issues that already existed for some time. Peering-wise, BAU, nothing new. Only thing is one of the 4 majors ISPs, ~21% market share, over 98% IPv6 deployment on fixed (and 0% on mobile) mono-homed to Cogent and de-peering HE. They are not peering as a general rule.
Re: Backhoe season?
On Thu, Mar 26, 2020, at 18:56, William Herrin wrote: > Howdy, > > With so much work shut down, I'm curious how backhoe season is shaping > up this year? How do the circuit and fiber outage numbers look? It seems that in France there are alternatives to backhoes (fr: pelleteuse, jargon: pelleteuz) : https://mobile.twitter.com/acontios_net/status/1242911425938493447 (tldr: scissors seem to work well enough in street sheltres)
Free.fr vs HE.net IPv6 (Was: CISA: Guidance on the Essential Critical Infrastructure Workforce)
On Sat, Mar 28, 2020, at 19:52, Mike Hammett wrote: > https://radar.qrator.net/as12322/providers#startDate=2019-12-27=2020-03-27=current Did you read the part about *IPv6* traffic ? Your link points to some IPv*4* relationship. Over IPv6, you get this : https://radar.qrator.net/as12322/ipv6-providers#startDate=2019-12-29=2020-03-29=current Note the "Active Now" part, which is only active for Cogent. And then, rather than taking QRator (which does a good job and has interesting information on a number of things - who buys transit from who *NOT* being one of those things - or at least not the public information) as word of absolute truth, did you test that bgp.he.net thinks about this ? Since HE is one of the parties, it does make sense to check their tools to see their point of view. Long story short: - Free.fr in known in France (where I happen to live and work) for only having Cogent as a transit for the last few years. - they are also known to peer (like "only exchange own routes and customer routes") with some "very big" networks (usually called "tier-1") : level3 and zayo among them. - Cogent and HE over IPv6 ... I suppose everybody knows the story. - Free.fr depeered he.net about one week ago... There have been some exchanges of tentative traceroutes in both directions on FRnOG (French NOG) and things are clear : free.fr and he.net cannot exchange IPv6 traffic.
Re: CISA: Guidance on the Essential Critical Infrastructure Workforce
On Sat, Mar 21, 2020, at 08:37, Bill Woodcock wrote: > And a giant thumbs up to Free, who are keeping my 10G broadband flying Are you talking about the same Free.fr that depeered HE a few days ago and expects all IPv6(*) traffic from HE to arrive via their only transit - Cogent ? (*) close to 100% of their fixed customers having IPv6 enabled to CPE level.
Re: COVID-19 vs. our Networks
On Tue, Mar 17, 2020, at 19:59, Mike Hammett wrote: > Join an IX your provider is on? As someone that works for an IXP these days, I would prefer *NOT* having to deal with people that do not understand the Internet ecosystem. Which hospitals, and most businesses are. An IXP is not an ISP targeting business/corporate. We're already dealing with people that do not understand what an IXP does, and open tickets every time a direct BGP session (one between 2 peers, not involving the route-server) goes down. Even had "Google is slow" tickets. Joining an IX purely for PNI/NNI interconnection may be an option, but only if you are 100% sure that the other party agrees an PNI/NNI over an IX. Some do, some don't, most don't even know it's a possibility.
Re: COVID-19 vs. our Networks
On Sat, Mar 14, 2020, at 04:31, Darin Steffl wrote: > Playing games doesn't take much bandwidth. Downloading games does. So > as long as everyone already has their games and there's no updates, > playing the game is typically under 100 kbps which is negligible > compared to streaming video which takes 1 to 25 mbps. My experience at $job[$now] (IXP) and $job[-1] (ISP with residential users) show otherwise. ISP-side traffic comes inbound from ASNs hosting gaming platforms, and IXP-side, gaming platforms have no issues taking 100G ports and pushing lots of traffic on them. Ratio-wise, they seem very much "heavy outbound". When new games are released, we see extra traffic from CDNs. Even if a game does not generate much traffic, in a MMO context every user pushes one data stream but receives several ones. And there may be reasons (avoiding cheats) where traffic pushed from the gaming platform contains more then each user's actions. IMO, it depends on how game handles inter-player communication. I do recall playing some serverless networked games some 15-20 years ago, with 3 players each on their own ADSL or cable, and the upstream (in the 512-800 Kbps range) never getting saturated.
Re: IPv6 Prefix Delegation to customers.
On Thu, Jan 16, 2020, at 06:15, Hugo Slabbert wrote: > https://mailman.nanog.org/pipermail/nanog/2019-May/101016.html Actually that one DOES contain some information. TL;DR: - check the "subscriber" or "broadband" functionality of your gear if it has something like that - check if the DHCPv6 relay functionality on your gear can inject the delegated prefixes into IGP or BGP - if you just have an L2 up to the DHCPv6 server, you're most likely out of lack (an not only for the DHCPv6 part) - you can always build something on your own if you have the ressources (take the delegated prefixes from your server, inject them into something like ExaBGP/BIRD/whatever that will re-announce them to your network).
Re: Reaching out to Sony NOC, resolving DDoS Issues - Need POC
On Thu, Jan 9, 2020, at 00:05, Keith Medcalf wrote: > > On Wednesday, 8 January, 2020 14:35. Octolus Development > wrote: > > Stop doing business with Criminal Organizations (SONY). Problem solved. You (as a provider) may not do any business with them, but your customers may, and will yell at you if/when it doesn't work.
Re: breakout
On Wed, Jan 8, 2020, at 20:09, Randy Bush wrote: > i am not a fiber/sfp/... geek, so clue bat please > > on my left, i have a delta 9020SL running arcos, female 40g qsfp > > on my right, i have incoming 10g 1310nm single mode from the seattle > internet exchange. it is currently into a redstone 10g sfp Ideally, you should use a "breakout optic" if supported by your device: it plugs into an 40Gbps port and delivers 4x10 Gbps via a MTP/MPO "breakout cable" (MTP/MPO at one end, change from one fat cable to 4 duplex cables somewhere in the middle, 4xLC duplex at the other end). Optic : https://www.fs.com/fr/products/37016.html (or the "riskier" 1km version : https://www.fs.com/fr/products/48276.html ) Cable : https://www.fs.com/fr/products/80240.html An "10G into 40G port adapter", as previously suggested could also work. > NAMEVALUE > - > SwPort 1 > Status PRESENT > Valid True > Vendor FiberStore > Model SFP-10GLR-31 > Serial-Number G1804021292 > TypeSFP > Module-Type 10G_BASE_SX > Media-Type FIBER > Module-Capability F_10G > Length 255 > Length-Description > > which i am swapping out for the delta 9020 At some point I can see "10G_BASE_SX" which is a little confusing, since "Base SX" is 1G on multi-mode fiber, in conflict with "SFP-10GLR" which is 10G on single-mode. It really is a 10G-LR, right ? > so i am look at something such as https://www.fs.com/products/30900.html > except i do not understand active/passive, AOC1M, etc Don't ! DAC (usually copper-based) and AOC are cables with optics at each end (if you can call a "copper optic" an "optic"). Cable cannot be detached from the *SFP*.
Re: 5G roadblock: labor
On Fri, Jan 3, 2020, at 19:35, Keith Medcalf wrote: > > How absolutely awful that must be, to always be relegated to slow and > insecure childrens band. I turn off childrens band (WiFi) on my phone > with extreme prejudice and it stays that way. I have yet to meet a > childrens band network (WiFi) that was worth connecting too. Well "childrens" band sometimes has the advantage of being availabe (and working) in places where cellular data isn't (or is as bad as in "not working"). Enabling/disabling wifi is a "sport" you get accustomed with... Same for switching wifi networks... > > Then again I don't play on my phone ... > A mobile phone today is much more than voice calling and games.
Re: 5G roadblock: labor
On Fri, Jan 3, 2020, at 16:38, Paul Nash wrote: > > And more interestingly, if that city's residents and visitors had the > > option of connecting to active 5G or wi-fi, what do we think they'd choose? > > They’d probably choose whichever popped un onto the device first. Don't know how things work in US, but mobile devices sold here in Europe do prefer wifi over cellular. If a pre-"approved" wifi network exists, and it doesn't have a captive portal, it will be systematically preferred. And here in France we have some networks lile this. they use SIM-EAP.
Re: Equinix
On Thu, Dec 5, 2019, at 17:10, Martijn Schmidt via NANOG wrote: > Hi Drew, > > You're probably best off ordering those crossconnects through the > Equinix portal, then you can choose the exact positions for the order > that goes to the facility rather than relying on a human to transcribe > them correctly from your PDF. Hi, I used to have issues with them at $job[-1]. At some point I had an "explanation" that they will NOT deliver XCos on ports that already have a cable plugged "in order not to cause disruptions". So much for precabled positions At some point it was also clear that their records (both their portal and their "other/non-official" records) were pretty far from being correct. The best part was when I ordered ONE XCo de-installed an I got TWO (the extra one a backbone link). Everything done via portal. Paris (FR/EU) area. Things seems a little better now, but as far as I can remember, things happen in "waves" there. Actually there's much more to say about them but for today it's enough. -- R-A.F.
Re: Disney+ Geolocation issues
On Wed, Nov 13, 2019, at 15:49, Matthew Huff wrote: > It’s not about optimization, it’s about the contract with the content > providers. For Disney, isn't it the same "house" ?
Re: BGP over TLS (was: Re: "Using Cloud Resources to Dramatically Improve Internet Routing")
On Mon, Oct 21, 2019, at 17:30, Keith Medcalf wrote: > Why do you need to do anything? TLS is Transport Layer Security and > it's sole purpose is to protect communications from eavesdropping or > modification by wiretappers on/in the line between points A and B. MD5 > in BGP is used for authentication (rudimentary, but authentication > nonetheless). TLS can also be used for authentication (in several ways), even if it's not the most appropriate for this situation.
Re: "Using Cloud Resources to Dramatically Improve Internet Routing"
On Mon, Oct 7, 2019, at 16:42, Stephane Bortzmeyer wrote: > Executive summary: it's SDN for BGP. Centralizing Internet routing, > what could go wrong? (As the authors say, "One reason is there is no > single entity that has a big picture of what is going on, no > manager". I wonder who will be Internet's manager.) > > Otherwise, an impressive amount of WTF. My favorite: "while > communication by servers ___on the ground___ might take hundreds of > milliseconds, in the cloud the same operation may take only one > millisecond from one machine to another" I thought that universities > were full of serious people, but university of Massachusets may be an > exception? What I find to be the worst part is in the first phrase : "... have received a three-year, $1.2 million grant to develop and test ..." That makes 200k$/year/person. I find it quite a lot for bu**sh*t-bingo content.
Re: California public safety power shutdowns
On Thu, Oct 10, 2019, at 08:02, Mel Beckman wrote: > The fire risk is from electrical transmission lines, not from end users > of electrical power. The underlying problem is that the State’s rules > for line separation were ill-considered, making it possible for > high-enough winds to cause “line slapping” and the resultant arcing > that ignite fires. > > There is no reason to think that end users are of any particular risk, > and fuel delivery during a preemptive outage wouldn’t be impaired, That looks like a situation that you don't often encounter elsewhere (where electricity - distribution, telecom and transport are not very far from one another).
Re: California public safety power shutdowns
On Wed, Oct 9, 2019, at 22:26, Sean Donelan wrote: > - Will this affect cellphone service? > > Generally no because this is a power shutoff, without other disaster > damage. All major switching offices have backup generators for 24 > to 72 hours and nearly all cell towers and outside plant have backup > batteries for 4 to 8 hours and/or backup generators. Service providers > should be able to re-charge batteries and refill generator tanks > throughout the power shut-off. Of course, if there is some other disaster > during this time, there would be less resiliance in the network. In a Previous e-mail: > Public Safety Power Shut-offs (PSPS) in California wildfire high-risk areas. So, during a Power shut-off because of wild*fire* risk, operators are supposed to be able to re-charge batteries and supply generators with fuel (I suppose diesel, regular gas being even worse) in the affected areas ? Did I understand things wrong ? I don't have an issue with shutting down power preventively in order to reduce an already high risk, but pretending that other people will keep their electricity-dependent equipment up, especially by providing flamable stuff - isn't this a huge WTF ?
Re: Chicago Equinix IX LAN oddity
On Tue, Oct 8, 2019, at 20:47, JASON BOTHE via NANOG wrote: > I realize this might not be the right list but I have a request to peer > on the Chicago Equinix IX to a 206.223.119 IP but we and many others That block is for Equinix-IX Dallas (at least according to PeeringDB). > are on the 208.115.137 network. While I await a response from the > peering partner, I’d curious to know if this is an error, perhaps there > was a renumber at one time or I’m flat out just missing something. You can occasionally get stuff like this for multi-location IXPs run by the same operator, usually from people that do not (?? yet ??) fully understand how things work. Sometimes from people that only care of their view of things (when using remote-peering).
Re: Mx204 alternative
On Fri, Aug 9, 2019, at 08:13, Saku Ytti wrote: > On Fri, 9 Aug 2019 at 09:09, Radu-Adrian Feurdean > wrote: > > > On Thu, Aug 8, 2019, at 16:51, Tom Hill wrote: > > > No-one has mentioned it yet, so for completeness big C have the ASR 9901 > > > > Weren't we talking about "decently priced" ? > > ASR9901 and MX204 being wildly differently priced is market > inefficiency. It's difficult for me to see, how CSCO could justify the > premium for any volume order. Either sell at market or lose sale. The 2 boxes not having exactly the same port count and features(9901 can do - or is suppose to be able to do - subscriber stuff - IPoE,PTA,LAC), this explains the difference. Add the fact that Cisco has customers that buy "Cisco and nothing else". And not everybody buys "enough" in order to get acceptable volume discounts. > Also it will never run eXR. I have no information, but I think it's > reasonable to suspect the OS not being sold may receive decreasing > amount of NRE. I wouldn't certainly spend my time writing code for > product I'm not selling. Agreed.
Re: Mx204 alternative
On Thu, Aug 8, 2019, at 16:51, Tom Hill wrote: > No-one has mentioned it yet, so for completeness big C have the ASR 9901 Weren't we talking about "decently priced" ? > (not 9001) with traditional router bits in it. 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.
Re: Mx204 alternative
Hi, SR1 (without s) is 2u high, bit it doesn't have 1G ports. It doesn't even have "native" 10G ports. Only 40/100G, with 4x10G optics for 10G. For 1G you would need a 7210 in sattelite mode, which is one extra U + $$$. Otherwise very nice box... On Thu, Aug 8, 2019, at 05:30, Mehmet Akcin wrote: > Thank you! Something within 2U (max) form factor :) > > On Wed, Aug 7, 2019 at 8:23 PM Tony Wicks wrote: > > Nokia 7750 sr-1.
RE: GEO IP Updates
Hey folk, Martijn Schmidt said. > They're also working on getting the format standardised in the IETF. I > applaud this, because less badly guessed geoip data and more reliably > self-published data is better: > > https://datatracker.ietf.org/doc/html/draft-google-self-published-geofeeds Just a quick note that this document is being advanced for publication as an Independent Stream [1] RFC. That means it is not getting IETF review or consensus and will not be an IETF RFC or any kind of standard. It is important to recognise that not all RFCs are IETF RFCs. Publication on the Independent Stream is a way to produce RFCs that describe proprietary protocols, provide commentary on IETF work, or offer contrary opinions. While the Independent Stream RFCs are held to the same editorial standards as other RFCs, their technical content is not subject to the same level of scrutiny. Reviews of drafts on the Independent Stream are always welcome. You can send comments and thoughts direct to the authors or to me as Independent Submissions Editor via rfc-...@rfc-editor.org <mailto:rfc-...@rfc-editor.org> . Thanks, Adrian -- Adrian Farrel Independent Submissions Editor (ISE) mailto: rfc-...@rfc-editor.org [1] https://datatracker.ietf.org/doc/rfc4846/
Re: Phoenix IX down/gone?
On Thursday 01 August 2019 14:48:53 Peter Kranz via NANOG wrote: > Anyone know what happened to Phoenix IX? https://peeringdb.com/ix/66 They > seem off the air including website and phones.. permanently? > $DAYJOB is peered and passes traffic thru there. I don't have full access to check but it looks like traffic is flowing thru the peer points currently, for thing like MSN/OWA/etc. I can ping and reach peers, but all traceroute thru the peering point seems to now stop at the border. Maybe they added some sort of filtering and hosed themselves? Not sure. Adrian
Re: netstat -s
On Thu, Jul 18, 2019, at 02:55, Randy Bush wrote: > do folk use `netstat -s` to help diagnose on routers/switches? > > randy Before today, I've never heard on anyone using it on routers/switches. Only on servers. `netstat -s` not very often. `netstat` (all options included) - less ans less often (due to updated tools and data collection methods). Personally, I still consider it a tools to know about.
Re: QoS for Office365
On Mon, Jul 8, 2019, at 18:15, Joe Yabuki wrote: > Hi all, > > How do you deal with QoS for Office365, since the IPs are subject to changes ? For "Classic QoS" : you don't. At best you tell the customer it's done without actually doing anything (it very often works). If it doesn't, see previous answers (those reccomending bandwidth upgrade and correct capacity provisioning a.k.a. "Modern QoS").
Re: Flexible OTN / fractional 100GbE
On Thu, May 30, 2019, at 09:41, Jérôme Nicolle wrote: > Yup. Should it hard-drop ? Buffer ? Both are unthinkable in OTN terms > (is that a cultural thing ?). It's what packet networks are made for. > And that's why an alien device, with support for Ethernet, OTN and > programmable pipelines, could bridge the gap, allowing for a more > efficient use of optical bandwidth. Hi Jerome, When you buy the kind of services that end-up being delivered on OTN, you expect to have a capacity that is dedicated to you, and only to you, and if you don't "use" it nobody else will. And you agree with the constraints that come with that (not protected, or protection is an extra paid option). Than comes the fact that Ethernet is *NEVER* "fractional". It is either 0 (ZERO) or line-rate. It's the amount (in time) of ZERO present over several microseconds (often "several" == "several millions") that gives (by doing an average) the "sub-rate" bandwidth. So no, hard-drop or buffer on OTN are not only "cultural issues", their absence is technically part of the OTN promise. If you are willing to accept to share unused bandwidth, then MPLS based services are the way to go, and you have that choice in a vast majority of the cases. You loose the hard guarantee of bandwidth availability and you usually get some trace of jitter.
Re: DHCPv6-PD relay route injection - standard?
On Sat, May 18, 2019, at 09:52, Brandon Martin wrote: > What it does is hook into the DHCPv6 lightweight relay functionality. > Basically, it just snoops the DHCPv6 replies for a PD assignment and > inserts a quasi-static route into its table for anything that it sees > with next-hop pointing at wherever the reply was going. The static > route is time-limited and gets removed when the delegation expires (or > presumably if it sees a release of the corresponding resources). It > stores the database of those learned delegations, including expiry, in Yep, that's exactly the expected behaviour (or at least a big part of it)... providedit's implemented properly. > persistent memory so that it can re-install them in event of a reload. That's an interesting point, most subscriber management implementations don't implement this, requiring low dhcp timers. > The key here is that it doesn't care about "who" is getting the > resources or why. All it cares is that it saw a DHCPv6 reply via its > relay that included a delegated prefix. Exactly, that's dhcp server's job. Or at least that's what I do at $job[$now]. > Juniper, at least, and presumably Cisco too, also implement a means to > get that information via RADIUS. That may be more what you're thinking of? That's "subscriber management". On Cisco (A9K and A1K) and NokiALU (SR 7750) you normally need a license, even if it's (for now) honor-based. On Cisco it'the "broadband"/BNG, on NokiALU it's "xK subscribers". > I'm not sure that the Cisco implementation I'm thinking of requires the > BNG/BRAS features to be licensed. See [1] under heading "DHCPv6 Relay > Agent Notification for Prefix Delegation". In particular, note: That one seems to be the simpler form, depending only on an external DHCP server. It may be enough for some set-ups. Subscriber functionality provides more options, such as enforcing auth and internal dhcp server that takes data to be returned from RADIUS. It also allows dissociation between L2 and L3 (same subnet on several VLANs). You can almost call it SDN :)
Re: DHCPv6-PD relay route injection - standard?
On Wed, May 15, 2019, at 04:28, Brandon Martin wrote: > Is there a standard that defines/recommends behavior for route injection > of snooped DHCPv6-PD (or IA, I guess) assignments on routers running > relay agents? That is, snooping or otherwise examining a relayed DHCPv6 > response for a delegated prefix (or IA, if you want) and installing a > quasi-static route toward the relevant next-hop based on the lifetime of > the delegation. Typical redistribution can then be used to put it in > IGP if you want. This feature is usually found packed with the BNG/BRAS/broadband termination functionality. The keyword you need to search is "subscriber". The feaure pack is usually subject to additional licensing. Cisco, Juniper, Nokia/ALU, all have product ranges supporting that. Those being said, I'm interested in how that feature is supported on gear that is not "subscriber-aware" (you were talking about Arista), since generating routing information from relayed DHCP(v6) is a big/important part of the "subscriber management" functionality. -- R-A.F.
Re: BGP prefix filter list
On Fri, May 17, 2019, at 15:28, Blake Hudson wrote: > From my perspective one's ability to intelligently route IP traffic is > directly correlated to the data they have available (their routing > protocol and table). For example, with static default routes one can For me, routing table and available routing protocols are not the only things needed for intelligent routing. And the router is not the only component involved in "intelligent routing". Not these days/not anymore. One thing that can help immensely in an internet environment is knowing where the data goes and where it comes from. Knowing your "important" traffic source/destinations is part of it. You can say "I can no longer keep all the routes in FIB, so I'll drop the /24s", then come to a conclusion that that you have loads of traffic towards an anycast node located in a /24 or that you exchange voice with a VoIP provider that announces /24. you just lost the ability to do something proper with your important destination. On the other hand, you may easily leave via default (in extreme cases even drop) traffic to several /16s from Mulgazanzar Telecom which which you barely exchange a few packets per day except the quarterly wave of DDoS/spam/scans/[name your favorite abuse]. Or you may just drop a few hundred more-specific routes for a destination that you do care about, but you cannot do much because network-wise it is too far away. Of course, such an approach involves human intervention, either for selecting the important and non-important destinations or for writing the code that does it automagically. Or both. There is no magic potion. (as a friday afternoon remark, there used to be such a potion in France, the "green powder", but they permanently ran out of stock in 2004 - see http://poudreverte.org/ - site in fr_FR).
Re: BGP prefix filter list
On Thu, May 16, 2019, at 16:38, Blake Hudson wrote: > offloading that responsibility onto the transit provider. IMHO, what's > the point of being multi-homed if you can't make intelligent routing > decisions and provide routing redundancy in the case of a transit > provider outage? Speaking of "intelligent routing", this is why doing some targeting on what you filter by some criteria other than prefix or as-path length is a good idea. Either manually every once in a while (just make sure that you at least check the situation every few weeks), or in an automated manner (better). You just need more data (usually *flow/ipfix based) in order to be able to take the good decisions. You can use traffic levels (or better - lack of traffic), traffic criticality (?!?! cirticity ?!?!) and prefix count saving as criteria. -- R-A.F.
Re: BGP prefix filter list
On Wed, May 15, 2019, at 13:44, Baldur Norddahl wrote: > Or maybe we have a list of worst offenders? I am looking for ASN that > announces a lot of unnecessary /24 prefixes and which happens to be far > away from us? I would filter those to something like /20 and then just > have a default route to catch all. Hi, You can start here : http://www.cidr-report.org/as2.0/#Gains You will have to do some manual work in order to identify how to optimally filter, but you may save some space. But the more important questions are: - how long will it last after one round of clean-up ? - can't you afford to use default route ? You can use tools like AS-Stats (or the more expensive and much more powerful alternatives) if your hardware allows it, in order to get the ASes that you have close to no traffic towards and leave those via default. Or, if you can afford a dedicated internet border router, there are models that start getting to decent pricing level on refurbished market (a thought to ASR9001 that should be pretty cheap these days).
Re: NTP for ASBRs?
On Wed, May 8, 2019, at 14:21, Lars Prehn wrote: > Hi everyone, > > do you NTP sync your AS boundary routers? If so, what are incentives for > doing so? Are there incentives, e.g. security considerations, not to do it? Hi, We (and I suppose a lot of others) do sync the border routers like any other network device : to our internal NTP servers that are in their turn synchronized to other time source. I don't see a reason to treat them differently.
Re: Widespread Firefox issues
My temporary solution was to set "xpinstall.signatures.required" to "false". On 5/4/19 4:55 AM, Brielle Bruns wrote: Just an FYI since this is bound to impact users: https://bugzilla.mozilla.org/show_bug.cgi?id=1548973 Basically, Mozilla forgot to renew an intermediate cert, and people's Firefox browsers have mass-disabled addons. Whoops. -- Best regards, Adrian Minta
Re: SFP supplier in Europe?
On Thu, Apr 4, 2019, at 22:42, na...@jack.fr.eu.org wrote: > I highly recommends https://www.alturnanetworks.com/ > > They sell solid optics, all are tested > Quick shipping, competitive price > > I have never been even remotely disappointed with those guys +1 They ship from the Netherlands, and delivery for France is 1-2 days (because we usually send them orders after 17h00 CET/CEST).
Re: WIndows Updates Fail Via IPv6 - Update!
On Sun, Mar 3, 2019, at 22:05, Mark Andrews wrote: > admins who don’t know how IP is supposed to work. You do realise that in "corporate world" that's more than 80% of network admins ? Some of them even make it to "audit" companies, so they can screw a company with clueful admins with their "mandatory reccomandations". > ICMP is NOT optional. Can we make a short rule that says: For ICMP, *ALLOW* *ALL* unless you do have a very specific and motivated reason to block some types. I would even go as far as "allow all icmp from any to any" (and if possible as the first firewall rule), but I do understand that may make some people have hives.
Re: DNS Flag Day, Friday, Feb 1st, 2019
On Thu, Jan 31, 2019, at 03:24, Mark Andrews wrote: > You do realise that when the day was chosen it was just the date after > which new versions of name servers by the original group of Open Source > DNS developers would not have the work arounds incorporated? I think it's pretty safe to say that the "DNS Flag day" is more like a date of "end of support" rather than an "service termination". My guess is that some uncompliant servers will be still running long after that date... -- R-A.F.
Re: trace from behind tata noam
On Thu, Dec 6, 2018, at 11:52, Radu-Adrian Feurdean wrote: > Router: gin-pv0-thar1 > Site: FR, Paris, PV0 Very similar results (going to NTT in very few hops) from their 2 NYC routers.
Re: trace from behind tata noam
On Thu, Dec 6, 2018, at 00:19, Randy Bush wrote:
> if anyone here is 'behind' 6453 en route 198.180.152.15, can you send
> a trace, please?
They have a looking-glass : http://lg.as6453.net/lg/
which says :
Router: gin-pv0-thar1
Site: FR, Paris, PV0
Command: traceroute inet4 198.180.152.15 as-number-lookup
traceroute to 198.180.152.15 (198.180.152.15), 30 hops max, 52 byte packets
1 if-ae-6-4.tcore1.pg1-paris.as6453.net (80.231.111.25) 1.258 ms 1.726 ms
1.712 ms
MPLS Label=334414 CoS=0 TTL=1 S=1
2 if-ae-7-2.tcore1.pvu-paris.as6453.net (80.231.111.6) 1.703 ms 1.516 ms
if-ae-7-2.tcore1.pvu-paris.as6453.net (80.231.111.2) 1.360 ms
3 if-ae-11-2.tcore1.pvu-paris.as6453.net (80.231.153.49) 1.266 ms
ae-7.r04.parsfr01.fr.bb.gin.ntt.net (129.250.8.1) [AS 2914] 1.126 ms
if-ae-11-2.tcore1.pvu-paris.as6453.net (80.231.153.49) 1.246 ms
4 ae-23.r24.amstnl02.nl.bb.gin.ntt.net (129.250.4.137) [AS 2914] 16.599 ms
20.124 ms 13.608 ms
MPLS Label=304689 CoS=0 TTL=1 S=1
5 ae-3.r25.amstnl02.nl.bb.gin.ntt.net (129.250.4.69) [AS 2914] 13.669 ms
13.672 ms 14.638 ms
MPLS Label=434000 CoS=0 TTL=1 S=0
MPLS Label=531024 CoS=0 TTL=1 S=1
6 ae-5.r23.asbnva02.us.bb.gin.ntt.net (129.250.6.162) [AS 2914] 86.304 ms
86.438 ms 101.443 ms
MPLS Label=309569 CoS=0 TTL=1 S=0
MPLS Label=531024 CoS=0 TTL=2 S=1
7 ae-0.r22.asbnva02.us.bb.gin.ntt.net (129.250.3.84) [AS 2914] 98.043 ms
ae-5.r23.asbnva02.us.bb.gin.ntt.net (129.250.6.162) [AS 2914] 115.804 ms
ae-0.r22.asbnva02.us.bb.gin.ntt.net (129.250.3.84) [AS 2914] 91.169 ms
MPLS Label=379041 CoS=0 TTL=1 S=0
MPLS Label=531024 CoS=0 TTL=3 S=1
8 ae-0.r22.asbnva02.us.bb.gin.ntt.net (129.250.3.84) [AS 2914] 89.571 ms
ae-6.r22.dllstx09.us.bb.gin.ntt.net (129.250.5.12) [AS 2914] 124.242 ms
130.316 ms
MPLS Label=531024 CoS=0 TTL=1 S=1
9 ae-2.r11.dllstx09.us.bb.gin.ntt.net (129.250.5.14) [AS 2914] 130.781 ms
119.661 ms 132.269 ms
10 ae-2.r11.dllstx09.us.bb.gin.ntt.net (129.250.5.14) [AS 2914] 122.000 ms
ge-102-0-0-29-53.r11.dllstx09.us.ce.gin.ntt.net (157.238.224.206) [AS 2914]
128.046 ms ae-2.r11.dllstx09.us.bb.gin.ntt.net (129.250.5.14) [AS 2914]
130.434 ms
11 netsrv.dfw.rg.net (198.180.152.15) [AS 4128] 129.176 ms 121.615 ms
ge-102-0-0-29-53.r11.dllstx09.us.ce.gin.ntt.net (157.238.224.206) [AS 2914]
126.358 ms
{master}
Re: netflix OCA in a CG-NAT world
On Wed, Nov 28, 2018, at 12:37, Nikolay Shopik wrote: > Are you sure about ATV4 netflix app? Support is there and I've seen > traffic from it when recently did tcpdump from ATV4. Or there is some braindead wifi in-between that does not allow IPv6 to function (or makes it unreliable). Already seens a number of such devices from different vendors.
Re: Not announcing (to the greater internet) loopbacks/PTP/infra - how ?
On Thu, Oct 4, 2018, at 21:53, William Herrin wrote: > On Thu, Oct 4, 2018 at 3:10 PM Brandon Applegate wrote: > > - Traceroutes are miserable. > > Also breaks PMTUD which can break TCP for everybody whose packets > transit your router. So don't do this. ... unless you happen to provide a "MTU1500" service over a jumboframe (more than 9100) backbone, which you can very easily do these days. In which case fragmentation/packet too big should never occur. Traceroutes remain miserable, at least from outside towards your network.
Re: Oct. 3, 2018 EAS Presidential Alert test
My son who has a Canadian line got it while in the Washington state area. Adrian On Wed, Oct 3, 2018 at 1:44 PM Stan Barber wrote: > I got it on ATT IPhone I have and a Verizon Pixel as well. > > On Wed, Oct 3, 2018 at 1:38 PM Ray Van Dolson wrote: > >> Anecdotally, we had staff feeding off of both AT and VZW IP-based >> metrocells get the alert message. >> >> Ray >> >> On Wed, Oct 03, 2018 at 12:53:57PM -0700, mike.l...@gmail.com wrote: >> > Iphone, vzw, silicon valley, rcvd. >> > >> > Interesting question though... I wonder if people on micro-cells >> > and/or wifi calling don’t get the alerts. That would be extremely >> > dumb and irresponsible of the cell phone carriers, so its likely the >> > case :) >> > >> > In rural America where cell coverage may not exist but the customer >> > may have PTMP wireless internet and is using a microcell and/or wifi >> > calling over the internet, if they dont get the alert, that could be >> > catastrophic. Something along the lines of the Santa Rosa, CA fires >> > catastrophic. >> > >> > I wonder if that is the case. >> > >> > -Mike >> >
Re: Massive Price Increase for X-conns at Telehouse Chelsea, NYC
On Mon, Sep 17, 2018, at 17:30, Daniel Corbe wrote: > $300 MRC for a once-off cross connect isn’t unreasonable. There’s costs 300$ would be (at the limit of) reasonable *M*RC for a 12 FO cable (= 6 duplex XCOs). Or the one-off (*N*RC) for one XCO. That's actually close to the rates we have on this part of the ocean. 300$ for one XCO (2 FO) is "robbery in organised band" (word-by-word translation of a french legal term). You can get metro waves (some 10-20 km distance) for lower than that (again, on my part of the ocean). -- R-A.F.
Re: netflix OCA in a CG-NAT world
On Mon, Sep 17, 2018, at 17:48, Jared Mauch wrote: > I also strongly suggest you look at how to get native IPv6 from your > clients behind the CG-NAT rolled out. I know many folks have had issues Getting IPv6 to your customers is good, but they still have to use it. If I look at my stats, I can see that the IPv4:IPv6 ratio for Netflix is 5.5:1, while for Google it's 1.1:1 and for Facebook 1.33:1 (peak-time ratios, when traffic is mostly from residential users) . The best explanation I could get is people may use Netflix from devices that do not support IPv6, such as some/most (not-so-old) Smart TVs. There's also the issue of some brain-dead wifi APs that filter or severely limit traffic required for proper IPv6 operation (multicast comes to my mind). I'm not even mentioning the situation in the "pro"/"enterprise" world (much worse) since it doesn't (or it's not supposed to) generate much Netflix traffic (still, during the morning IPv4:IPv6 ratio for Netflix can go as low as 3.5:1). -- R-A.F.
Re: Definition/Classification of Bogon
On Tue, Jul 24, 2018, at 13:24, Aftab Siddiqui wrote: > Q - Generally, Private or Reserved ASNs are considered as Bogon ASN but > what about unallocated ASNs? If you don't have an automated update process running at decent time intervals (one week or more often, under no circumstance less than once a month) and you don't have processes in place that monitor that updates do happen properly with some corrective action being done when they don't - then stick with private or reserved. If you do have everything needed, and are aware that what is unallocated today may be allocated tomorrow, then you can (should) go with private+reserved+unallocated option.
Re: issues through CGNat (juniper ms-mpc-128g in mx960)
On Thu, Jul 19, 2018, at 16:34, Aaron Gould wrote: > I don't know if it's fixed on the endpoints, or in the cgnat config or what. Not specific to Juniper, but it's NOT fixed. You'll either start spending time on work-arounds or you start selling a new service with dedicated public IPv4 - more expensive than the CGNATed one. Or you can afford to still delay deploying CGN.
Re: Proving Gig Speed
On Wed, Jul 18, 2018, at 15:45, Mike Hammett wrote: > Fast.com will pull from multiple nodes at the same time. I think there Here in Europe, fast.com consistently proven to be 100% UNreliable, especially on high-speed FTTH. OOKla and nPerf gave better results for high-speed connections 100% of the time.
Re: Proving Gig Speed
On Tue, Jul 17, 2018, at 18:12, Andy Ringsmuth wrote: > I suppose in reality it’s no different than any other utility. My home > has 200 amp electrical service. Will I ever use 200 amps at one time? No, because at 201 Amps instantaneous the breaker will cut everything. > Highly highly unlikely. But if my electrical utility wanted to advertise > “200 amp service in all homes we supply!” they sure could. Would an > electrician be able to test it? I’m sure there is a way somehow. Will they deal with customers calling to complain that their (unknown to the utility) "megatron equipment" says it cannot draw 199 Amps from a single outlet ? I don't think so. They just ensure the global breaker will not trigger when oven+microwave+home-wide air-con+water heating+BT rig in the basement all draw all they can (i.e. up to ~25 Amps each) for something like 5 min. > saturate my home fiber 300 mbit synchronous connection? Every now and > then yes, but rarely. Although if I’m paying for 300 and not getting it, > my ISP will be hearing from me. Will you waste your time if some random site says "you have 200 Mbps" ? On residential, we only accept complaints for tests in pre-determined (wired, no intermediate device, select set of test servers and tools, customer hardware check) conditions and only for results lower than 60-70% of "advertised speed". If wireless is invoved, test is being dismissed as "dear customer, please fix your network, regards". For pro/enterprise service, we use higher bandwidth threshold, but we do expect the other side to be competent enough for something like an iperf3 test. However, I have to mention that for the moment we can afford to run a congestion-free network (strictly less than 80% charge - usually less than 50% - measured with 1-minute sampling). > If my electrical utility told me “hey, you can upgrade to 500 amp Are the 200 Amps written somewhere in the contract or is it what reads on the usually installed breaker ? Around here, the maximal power is determined in the contract (and enforced by the "connected" electrical meter/breaker that has a generous functioning margin.
Re: Proving Gig Speed
On Tue, Jul 17, 2018, at 16:42, Mike Hammett wrote: > Build your own last mile or order that 10% more? Do you realize what you are saying ? Let me offer a few translations: 1. "Don't spend N00 Currency/month for X Mbps from your customer to your aggregation DC on an existing NNI, but pay something like N0 KCurrency one shot (sometimes significantly more) + whatever is needed to extend your backbone ot the customer area (long-haul capacity, equipment, housing, ...)." CFO hates this unless you have enough customers in a single decently-sized area. 2. The "10% more" does not work this way. In this part of the world, the next step after 100 Mbps is 200 Mbps, and the next step after 1Gbps (on 1G port) is 2 Gbps (on 10G port). You can't buy 110 Mbps or 1100 Mbps. You just can't over-provision L2 transport for those speeds. Even if you are in a situation where you really can over-provision, your customer stays yours only as long as the price is correct. A competitor that does not over-provision but instead explains how things work ends up winning "your"customers. 3. There are zone where you are just not allowed to run your local loop. Most common example is airport and harbor areas. Then there are country-specific zones where you may not be allowed, and finally there are zones where a few select people do a lot of things so that only their favorite provider (usually the incumbent) deploys. A derivative of this, is the "select people" is the telecom regulator, that grants an almost-monopoly in certain areas to the first operator that comes with a deployment plan for the whole area (fiber anyone - individual and business - in a 80K people town - you have 10/15/20 years to do it). You may argue that some of those issues do not apply in North America (the NA from NANOG), but NANOG became pretty much global :)
Re: (perhaps off topic, but) Microwave Towers
On Sat, Jul 14, 2018, at 17:07, Keith Stokes wrote: > There’s a lot less backhoe fade with microwave. ;-) > > Kidding aside, I’m sure there are plenty of scenarios where microwave > makes better sense than fiber especially since it’s a lot easier to HFT or any low-latency app is such a scenario (0.999c through air being 50% faster than 0.66c though fiber), but that region doesn't fit for that use.
Re: AS3266: BitCanal hijack factory, courtesy of many connectivity providers
On Tue, Jun 26, 2018, at 20:23, Job Snijders wrote: > I'm very happy FranceIX apply filters - however Bitcanal is known to > submit fabricated/falsified IRR information to databases like RADB and > RIPE. I've reported this multiple times over the years to IRR database > operators. > > In conclusion in the case of Bitcanal, most of your filtering is useless > (and so is mine). Participants like Bitcanal dillute the value of your > route servers and the IXP as a whole. I can confirm that this mornig (~09h30 CEST, when I read the first message in the thread) there were no BitCanal announces received from FranceIX Paris RS. Not even the ones with an IRR record (the ones in 213/8). All of them were from transit.
Re: WC 2018 impact on network yet
On Sat, Jun 16, 2018, at 22:07, Keith Medcalf wrote: > > People stream HD Video in the Water Closet? I don't think my 80" HDTV > would fit in there! I don't think they do that, but they are more and more to receive regular TV via OTT STBs. And sport events, which attract viewers, are better candidates for higher definition (those days 4K) than regular tv programs (some of them still SD, some "regular HD"). So when everybody will watch the local favourite's match (important ones), we do expect traffic levels to be higher than usual.
Re: WC 2018 impact on network yet
On Fri, Jun 15, 2018, at 12:23, Ong Beng Hui wrote: > Hi, > > With every operators looking at high quality HD video stream, anyone > feeling the impact for WC 2018 yet ? It's too early. For now only minor changes (e.g. 2 hours ago, when local team had their first match we saw levels of traffic slightly higher then usual for that time of the day, but lower than usual prime-time). We expect things to change later in the competition.
Re: AS23456
On Mon, Apr 9, 2018, at 17:03, DurgaPrasad - DatasoftComnet wrote: > Thanks all. Understood. > > Anyone know if AS-STATS understands AS4? > It does, if the flow source sends the information needed.
Re: MTU to CDN's
On Fri, Jan 19, 2018, at 01:14, Jared Mauch wrote: > If you’re then doing DSL + PPPoE and your customers really see a MTU > of 1492 or less, then another device has to fragment 5x again. In this part of the world we have even worse stuff around: PPP over L2TP over over IP with 1500 MTU interconnection. Remove another 40 bytes. Add some more headers for various tunneling scenarios and you may get into a situation where even 1400 is too much. But it usually works with MSS clamping to the correct value. Some small ISPs don't even make the effort to check if the transport supports "more than 1500" in order to give the 1500 bytes to the customer - they just clamp down MSS.
Re: Attacks from poneytelecom.eu
On Fri, Jan 5, 2018, at 00:34, Stephen Satchell wrote: > On 01/04/2018 01:02 PM, Dan Hollis wrote: > > when the first tier incompetence stops, the direct contacts will stop too. > > But, but, but...when the first tier support person gets the training to > not be incompetent, he is promoted to the second tier and the vacuum is > filled with another incompetent first-tier person. > > So, by definition, the first tier of support will only be able to answer > questions "from the book". Anything more complex than what's in "the > book" is bumped to the second tier...where the problem is above the > second-tier pay grade and it gets bumped further up the chain. Yes and no. You need to have a good "script" for the first-level support, and then you need to have people that understand what they are trying to do: take the information from the requester, do minimal (ideally script-defined) checks, run through it the script, then either fix (and confirm that it's fixed) or escalate. For smaller business structures, you may seriously loosen the script and go as far as require that people answering the phone or treating the support queue have an understanding of everything that the company does and how it does it. This does not scale. You cannot expect this for companies with more than (10s of) thousands of customers. You cannot expect to only have technically competent people to handle 100s or 1000s of tickets per day. Then you compare this with contacting directly someone that only receives a few requests a week because he/she is usually doing something else. That's obviously more effective as long as: - the person in question is still in a position to help or at least to escalate/forward properly - the person in question is still willing to help - the person in question is not flooded with requests impacting his/her normal duties, in which case the willingness to help may decrease to zero (or even make sure that a direct contact is counter-productive). Particularly for abuse management, thinks are a little more complex. Arbitration needs to be done between what you (the requestor) think is abuse, what the provider thinks about it, what the customer thinks about it, what the laws says and what does the contract/T/AUP says about it (and about how to deal with it). This may take time, involve non-technical persons and may not give the expected outcome even when dealt with by a good-faith service provider.
Re: Attacks from poneytelecom.eu
On Thu, Jan 4, 2018, at 06:46, Tim Burke wrote: > AS12876 is online.net... home of the €2.99 physical server, perfect for > all of your favorite illegitimate activity. I’m curious how much traffic > originates from that ASN that is actually legitimate... probably close > to none. For you, in US, probably not so much, but you should really check. For us, here in France, Online is one of the 2 top hosting providers (they even have several neutral datacenters where they lease racks/cages/datarooms) with a quite enough of legitimate traffic. I say enough, since 10's of MBps of traffic to classic (locally) well-known sites is easily hidden by spikes due to file transfer (they are also popular here for hosting private off-site backups - they actually even have an archiving service) or bittorrent. I also saw a mention of Iliad, their parent company, stock-listed (ILD on EuroNext Paris), as "buletproof hosting". You should note that they also own one of the top 4 ISPs here in France and one of the 4 frequence-owning mobile operators. But those run each on separate networks. One should probably do some minimal research on non-US companies before accusing. PS: No, I don't work for them. Just happen to be personally a customer of 3 of the Iliad-owned companies (Online.net being one of them).
Re: Static Routing 172.16.0.0/32
On Fri, Dec 8, 2017, at 21:02, Job Snijders wrote: > Nothing wrong with using xxx.0 or xxx::0 in the context of a host route > (/32 or /128). https://labs-pre.ripe.net/Members/stephane_bortzmeyer/all-ip-addresses-are-equal-dot-zero-addresses-are-less-equal For a host route, no problem. For the host itself - a slightly different story.
Re: 4 or smaller digit ASNs
On Thu, Oct 12, 2017, at 07:47, Mel Beckman wrote: > James, > > As far as I know, you can't buy an existing ASN for any amount of money. You can in RIPE region, but you must first find an "owner" ready to tranfer it (for money or for free). ASN transfers do happen here, and there are indications that they happen in ARIN region too ( https://www.ipv4auctions.com/customer/account/previous/ - search for ASN).
Re: Question about Customer Population by ASN for Canada
On Mon, Oct 2, 2017, at 22:15, Filip Hruska wrote: > * OVH is also a home ISP - just in France though; but not sure if/how > APNIC separated OVH as an ISP and OVH as a server provider. > I think it's all under the same ASN (might be wrong though) Hi, OVH ISP uses a slightly weird set-up: - separate AS for residentian IPv4 ranges. That AS is only seen in GRT via OVH main AS. - IPv6 is provided from the "main pool", advertised by the main AS. And yes, their hosting business hosts tons of VPNs (on VPS or dedicated servers) which are also used by a number of french users in order to get decent internet performance (for the case when their ISP does saturate transit - which is every day 17h-24h).
Re: Some advice on IPv6 planning and ARIN request, please
On Sat, Jul 8, 2017, at 19:13, Mel Beckman wrote: > Radu, > > Are you assuming that a goal of IPv6 is to efficiently fill subsets? I No, but I assume IPv6 is still subject to common-sense. > among them easy mapping of MAC addresses for transition purposes and the > security that discourages malefactors from quickly enumerating active > devices in a subnet. I do get all those points. And by the way, try to explain the same to security people. > But that's not the main reason for /64 basic subsets. One of the guiding > principles of IPv6 was to not make the mistake of underestimating the > future applications of IP addresses. Thus your question "what hotel room ... so it went directly to over-estimating > has 65536 items in it?" has no meaning in terms of future applications. > As you point out, we're not talking about hotel rooms. We don't, by > definition, know what we're talking about for future applications. All this by forgetting today's applications. And no, you can't possibly treat the same way a hotel room and a 4 floor site with a server room. > I tell people in my IPv6 classes that we have to stop thinking of > ourselves in a spacesuit with a limited air supply that must be rationed, > and instead recognize that we're now in a wide-open planet-sized > atmosphere where we can breathe freely, and without apportionment. Well, by having 64 bits for each subnet, I start lacking bits for other things (like inter-devices connections, ). I'm not in a space-suit, but I'm on top of Kilimanjaro, where air pressure is only half of what we're used to. > That open atmosphere was by design. It's why IPv6 uses 128-bit addresses, That's for hosts. When you care more about subnets, it's shortened to 64 bits. > They're just integers. Not lumps of gold. Be careful, IPv4 got upgraded from numbers to gold a number of years ago. > And there's more where those came from :) Hopefully. I'm just curious if 8000::/4 will obey today's rules or not. Back to the original question, I find it delirious to treat a small entity the same as a big one, especially when the size difference between the two is several orders of magnitude. Even if we consider "future applications", there's still a very high chance that the size will still matter. Get "the IT guy" of a small company to get used with a /48 for his 20 people, 5 printers and 2-3 servers set-up, then imagine what happens with a design of a "site" 10 or 100 times bigger. This is something that you already see with VLAN ids and RFC1918 space. Even if you think you gave people "as much as they will ever need", they will still end up needing more.
Re: Some advice on IPv6 planning and ARIN request, please
On Sat, Jul 8, 2017, at 03:06, Owen DeLong wrote: > consider a /48 per guest room as well as a /48 per hotel for the hotel > itself. I think the classfull madness of "/48 everywhere" should stop at some point; the "every subnet is a /64" is enough already. A /48 is 65536 *subnets*, with each subnet having space for what can be considered "unlimited" number of devices. A /56 already is 256 *subnets*. Now please show be a hotel room that has close to 65536 items in it (also tell me how much does a night in such a room cost). Then how many rooms may host close to 256 devices that can transmit and receive data ? And then again, at the end of the day a hotel is *NOT* and ISP, a hotel is a hotel. Internet access is just an extra service that became mandatory lately in order to remain "competitive".
Re: IPv6 traffic percentages?
On Thu, Jun 22, 2017, at 08:18, Mukom Akong T. wrote: > > On 18 June 2017 at 17:36, Radu-Adrian Feurdean <nanog@radu- > adrian.feurdean.net> wrote:>> so for the record, business customers are much > more active in >> *rejecting* IPv6, either explictely (they say they want it >> disabled) or>> implicitly (they install their own router, not configured >> for >> IPv6). The>> bigger the business, the bigger the chance of rejection. > > > Did they per chance state their reasons for rejecting it? Not explicitly. But when we get something like "turn off that IPv6 crap !" we take it for: - they don't have a clearly defined need for it - they don't know how to deal with it - they don't want to deal with things they don't need (see the irst point)... usually all of them at the same time. To make it short : education. And we as as small ISP we have neither the resources, nor the motivation (because $$$ on the issue is negative) to do it (the education). -- R-A.F.
Re: IPv6 traffic percentages?
On Mon, Jun 19, 2017, at 14:17, f...@fhrnet.eu wrote: > I assume it means 60% of all their IPv6 traffic is reaching Google > services, ie GMail or YouTube. Exactly. Or otherwise said, more than 60% of the IPv6 bytes (NOT flow entries) accounted via Sflow (residential) or sampled Netflow (whole traffic) come from or go to 2a00:1450::/29. We had month with over 67%.
Re: IPv6 traffic percentages?
On Mon, Jun 5, 2017, at 14:51, Bajpai, Vaibhav wrote: > The v6 numbers from ^ NANOG post are now more than 1 year old. Thought > to re-bump this thread. Would it be possible to share updated numbers > of v6 traffic share within your network and % contribution by top apps. Hello, A little late and "out-of-geography", but still... On small-ish French ISP we have : - on the residential-only FTTH part, where all clients have IPv6 by default (unless they do something to avoid using it - and some do) : up to 30% of total is IPv6, and at least 60% of IPv6 is with Google. - globally (residential+business), the rate drops to 9% with peaks towards 20% on week-ends and public holidays. Same thing with Google doing most of IPv6. For the record, apart Google, there are less than 10 ASes that have more than 1% (but less than 10%) of the total IPv6 traffic. Everybody else is just traces Also for the record, business customers are much more active in *rejecting* IPv6, either explictely (they say they want it disabled) or implicitly (they install their own router, not configured for IPv6). The bigger the business, the bigger the chance of rejection. -- R-A.F.
Re: Cisco NCS5501 as a P Router
Hi, We didn't test any of those features. My understandig was that they all require extra licenses that would bring them "out of scope" ($$$-wise) and our need was for pure "P-routers"... actually being technically unable to perform as PE was kind of hidden requirement :) On Sat, May 27, 2017, at 21:14, Aaron Gould wrote: > Hi Radu-Adrian, have you done any MPLS PE functions on the NCS5001 ? > ...like MPLS/VPLS L2VPN, or L3VPN ? > > I'm asking because I tried a NCS5001 in my lab about a year or 2 ago and > it was pretty bad. At which point I was told to only try it as a P box > from a Cisco engineerat which point it dropped from my consideration > since I needed to replace lots of Cisco ME3600's with mpls edge > functions, and I ended up settling on the Juniper ACX5048. > > I'm wondering if Cisco improved that NCS5001 in more recent versions of > XR to included functional MPLS L2 and L3 vpn's. > > -Aaron > > >
Re: Cisco NCS5501 as a P Router
On Thu, May 18, 2017, at 15:21, Erik Sundberg wrote: > We're at the growing point where we need a dedicated P router for a core > device. We are taking a serious look at the NCS5501. Is there anyone else > using a NCS5501 as P Router or just general feedback on the NCS5501 if > you are using it? Hi, While we're not using the NCS5501, we do use the "previous version", NCS5001. We're not yet at a point to care about the minuscule buffers. Set-up : initially P-router in a very small BGP-free core (ISIS + LDP), then added route-reflector functionality too. As a P-router they usually behave correctly, except for the some cases where they start routing incorrectly (according to Cisco, the wrong label is programmed into hardware). That should have been fixed with 6.1.2, which we have deployed, until we recently had the same issue on 6.1.2, on the exact same box. We expect having some fun with the TAC about that. > The big downside is it's only has a single processor Yes, but: - it's powerful enough (we ended-up using them as RR too, and ~1.2M routes in RIB pose no problem) - ours being about half the price of a 5501, we have 2 of them on every site. If you can afford the same (2 / site) do it; If you don't - review the copy so that you can (Brocade SLX 9540 looks like a good alternative).
Re: Question about experiences with BGP remote-AS
On Fri, May 5, 2017, at 18:55, LF OD wrote: > of our existing ASNs and peerings. As it turns out, there are many > routers that can do VRFs but you cannot put a unique ASN on each VRF so > replicating the old environment isn't quite that straightforward. The BGP > remote-as looks to be a possible alternative solution, but we've never You mean *local-as*, right ? Otherwise, there was a vendor that allowed different ASN per VRF but only with non-MPLS vrfs, and that product line is both end-of-sale and major overkill for your set-up.
Re: CGNAT
On Fri, Apr 7, 2017, at 20:03, Mikael Abrahamsson wrote: > On Fri, 7 Apr 2017, Max Tulyev wrote: > > > BTW, does somebody check how implementing a native IPv6 decrease actual > > load of CGNAT? > > Reports are that 30-50% of traffic will be IPv6 when you enable dual > stack. This would be traffic that will not traverse your CGNAT. My data on customers supposed to be 100% dual-stack (unless they explicitely disable IPv6 on their side, which some of them do) says 25% on best days. It used to be up to 35% in late 2015. For reason unknown, it was going slightly down during 2016, with a sudden extra decrease in january this year.
Re: Facebook more specific via Level3 ?
On Wed, Mar 22, 2017, at 12:25, Mike Hammett wrote: > Are your DNS resolvers on your network? No DNS forwarding? Yes, DNS resolvers on our network. Forwarding only for facebook.com and fbcdn.com, in order to eliminate bad performance associated with "direct recursion".
Re: Facebook more specific via Level3 ?
On Tue, Mar 21, 2017, at 20:38, Jürgen Jaritsch wrote: > I understand that FB is using some type of DNS geo-loadbalancing and other > mechanism to redirect users to (possibly) nearer mirrors. The used DNS is > directly requesting the root DNS and not any other public DNS (e.g. not > 8.8.8.8). Running some requests within 3 minutes gives me the below > results: > > www.facebook.com => star-mini.c10r.facebook.com. => 31.13.77.36 > www.facebook.com => star-mini.c10r.facebook.com. => 157.240.2.35 > www.facebook.com => star-mini.c10r.facebook.com. => 31.13.93.36 > www.facebook.com => star-mini.c10r.facebook.com. => 31.13.76.68 Hi, the load-balancing definitely doesn't choose the *nearest* mirror. We are in France and unless we do dirty tricks, we *always* get directed to US sites (as far as LA), with horrible performance. Everything since end of December. As a consequence we let the dirty tricks in place (query facebook.com and fbcdn.com on 8.8.8.8 instead of regular recursive resolving) and we get directed to Frankfurt or Amsterdam (never London or Paris).
Re: One Year On: IPv4 Exhaust
On Mon, Sep 26, 2016, at 01:01, Mark Andrews wrote: > > In message > <1474840690.4107784.736591409.28e80...@webmail.messagingengine.com>, > "Radu-Adrian Feurdean" writes: > > > > I know, but for the "server guys" turning on IPv6 it's pretty low on > > priority list. > > Are those server guys interested in stopping attacks without > collateral damage? You can't say that a IPv4 address == 1 customer > today. Any protection measures you put in place based on IPv4 > addresses are likely to affect more than one customer. To put in context, I live and work in France, where NO mobile operator provides IPv6, but they do use CGN. Wired-line operators (some, not all) barely start deploying CGNAT on some of the new customers. Pro/business access operators MUST provide IPv4 in order to be able to survive. Things will probably change, but this is the situation today. So "1 IPv4 = several customers" it's either mobile (with no alternative and separate abuse handling process) or negligible. > > My customers are eyeballs. Residential ones have dual-stack by default, > > business - some have, some don't and some explicitly refuse (or ask for > > v6 to be disabled). > > Lots of residentual customers don't have a unshared IPv4 address. > The only reason you are seeing IPv4 from them is that the ISP has > had to spend money working around the sheer lazyness of content > providers in not providing IPv6. Lots of residential customers still do here. > > > Is somewhere between 11-14% worldwide enough for you to invest the > > > time to turn on IPv6 enough? It should be. > > > > Since they (the 11-14% worldwide) do have IPv4 anyway, some consider > > it's not worth; at least not yet. > > Actually almost all of the world does not have complete IPv4, they > have a subset of IPv4. You have just got used to not having complete > IPv4. > > > The issue with IPv6 deployment it's not as simple as some people > > suggest. It's not a technical problem either, but it's a big one. > > In most cases it is just a matter of turning it on. ... and in some of those cases turning it on is subject to a "change request" that requires validation from some level of management that requests the answers to questions similar to following : "What do we gain from this ? What does it cost to turn on ? What does it cost to support the new feature ?". Giving acceptable answers to people that don't necessarily understand IPv6 (some of them having spent their entire life in "IPv4-only, behind NAT" environments) is not that obvious, and this is the core of the "non-technical problem". You probably don't have to deal a lot with this kind of people
Re: One Year On: IPv4 Exhaust
On Sun, Sep 25, 2016, at 23:27, Mark Andrews wrote: > But it shows that if you turn on IPv6 on the servers you will get > IPv6 traffic. We are no longer is a world where turning on IPv6 > got you a handful of connections. There are billions of devices > that can talk IPv6 to you today the moment you allow them to. I know, but for the "server guys" turning on IPv6 it's pretty low on priority list. > Can all your customers talk IPv6 to you? No. > It the proportion of customers that can talk IPv6 to you increasing? > Yes. My customers are eyeballs. Residential ones have dual-stack by default, business - some have, some don't and some explicitly refuse (or ask for v6 to be disabled). > Is somewhere between 11-14% worldwide enough for you to invest the > time to turn on IPv6 enough? It should be. Since they (the 11-14% worldwide) do have IPv4 anyway, some consider it's not worth; at least not yet. The issue with IPv6 deployment it's not as simple as some people suggest. It's not a technical problem either, but it's a big one.
Re: One Year On: IPv4 Exhaust
On Sun, Sep 25, 2016, at 19:40, Seth Mattinen wrote: > ARIN's last /8 was run to zero last year. > > Anything since then has been randomness from the waiting list such as: > https://www.arin.net/announcements/2016/20160902.html and a slightly more restricted "really last" /10 : 23.128.0.0/10 (so-called "to facilitate IPv6 deployment")
