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: 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: 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: 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: 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: 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: 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: 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: 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: 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.
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&endDate=2020-03-27&tab=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&endDate=2020-03-29&tab=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: 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)
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: 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: 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: 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: 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: 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: 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: 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: 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: 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 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 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: 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: [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: 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: 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: 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: 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 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: 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: 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: 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: 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: 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: 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: 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
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: 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: 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: 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: "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: 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: 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: 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: 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: 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: Netflix VPN detection - actual engineer needed
On Sun, Jun 5, 2016, at 23:55, jim deleskie wrote: > Damian, I HIGHLY doubt regular folks are running into issues with this, I > suspect its not even geeks in general having issues, I suspect 80% plus of > those having issues spend most of their time complaining about something > related to v6 and the rest of the geeks not loving them/it enough. You don't even need a HE tunnel in order to be blocked for "VPN reasons": 2 providers, both dual-stacked (2 different v6 prefixes on the home LAN, adresses from both /64s on each machine), only one used for IPv4 exit. With this set-up you DO get random messages about being on a VPN (at least on some devices).
Re: 1GE L3 aggregation
On Fri, Jun 17, 2016, at 12:43, Saku Ytti wrote: > Last I checked you can't commit/replace configuration in VRP. Has this > changed? Can you give it full new config and expect it to figure out > how to apply the new config without breaking existing? ... later... > Yeah it's best I've seen. 8-10k isn't anything special. I suppose that's the reason I didn't see the Brocade CER-RT (some time ago best-seller) listed. Probably the lack of need for full-table FIB also counts.
Re: One Year On: IPv4 Exhaust
On Sun, Sep 25, 2016, at 18:29, Ca By wrote: > Think it is fair to say big content and big eyeballs have moved to IPv6 > (notable exceptions exist) > > http://www.internetsociety.org/deploy360/blog/2016/08/facebook-akamai-pass-major-milestone-over-50-ipv6-from-us-mobile-networks/ Big, yes, many - not really. While looking in the flow logs I could see the same (bandwidth intensive) destinations again and again. It's like ~4-5 destinations doing at least half of the IPv6 traffic.
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")
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 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: 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: 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: 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: (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: 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: 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 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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 Thu, Jun 22, 2017, at 08:18, Mukom Akong T. wrote: > > On 18 June 2017 at 17:36, Radu-Adrian Feurdean 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: 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: 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: 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: 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: 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: 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: 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&C/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: 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: 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: 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).
