- NANOG - lists.nanog.org

Re: Yet another BGP hijacking towards AS16509
by Siyuan Miao 23 Aug '22

23 Aug '22

Just noticed another thing: ➜ ~ whois -h whois.ripe.net -- "--list-versions AS1299" | tail -n10 2862 2022-07-11T14:44:49Z ADD/UPD 2863 2022-07-27T11:17:25Z ADD/UPD 2864 2022-08-02T08:43:02Z ADD/UPD 2865 2022-08-10T12:11:29Z ADD/UPD *2866 2022-08-17T10:47:43Z ADD/UPD2867 2022-08-18T12:53:37Z ADD/UPD* % This query was served by the RIPE Database Query Service version 1.103 (WAGYU) ➜ ~ whois -h whois.ripe.net -- "--show-version 2865 AS1299" | grep 209243 ➜ ~ whois -h whois.ripe.net -- "--show-version 2866 AS1299" | grep 209243 import: from AS209243 accept AS209243 mp-import: afi ipv6 from AS209243 accept AS209243 *➜ ~ whois -h whois.ripe.net <http://whois.ripe.net> -- "--show-version 2867 AS1299" | grep 209243import: from AS209243 accept AS-SET209243mp-import: afi ipv6 from AS209243 accept AS-SET209243* Looks like the first thing that AS209243 had done after they got AS1299 transit is ... hijacking an Amazon prefix ..? On Tue, Aug 23, 2022 at 1:51 AM Siyuan Miao <siyuan(a)misaka.io> wrote: > Hi folks, > > Recently I read a post regarding the recent incident of Celer Network and > noticed a very interesting and successful BGP hijacking towards AS16509. > > The attacker AS209243 added AS16509 to their AS-SET and a more specific > route object for the /24 where the victim's website is in ALTDB: > (Below is our IRRd4 server NRTM logging, UTC timezone) > > irrd.log-20220817.gz:31106270-ADD 96126 > > irrd.log-20220817.gz:31106280- > > irrd.log-20220817.gz:31106281-as-set: AS-SET209243 > > irrd.log-20220817.gz:31106306-descr: quickhost set > > irrd.log-20220817.gz:31106332-members: AS209243, AS16509 > > irrd.log-20220817.gz:31106362:mnt-by: MAINT-QUICKHOSTUK > > irrd.log-20220817.gz:31106392-changed: crussell(a)quickhostuk.net > 20220816 > > irrd.log-20220817.gz:31106438-source: ALTDB > > irrd.log-20220817.gz:31147549-ADD 96127 > > irrd.log-20220817.gz:31147559- > > irrd.log-20220817.gz:31147560-route: 44.235.216.0/24 > > irrd.log-20220817.gz:31147588-descr: route > > irrd.log-20220817.gz:31147606-origin: AS16509 > > irrd.log-20220817.gz:31147626:mnt-by: MAINT-QUICKHOSTUK > > irrd.log-20220817.gz:31147656-changed: crussell(a)quickhostuk.net > 20220816 > > irrd.log-20220817.gz:31147702-source: ALTDB > > > Then they started announcing the prefix ... under another AWS ASN (AS14618) > I guess AS1299 Arelion doesn't check if the origin AS of an announcement > is in the customer's AS-SET but it's pretty normal and understandable. > > > https://stat.ripe.net/widget/bgplay#w.resource=44.235.216.0/24&w.ignoreRean… > > > Type: A > announce Involving: 44.235.216.0/24 > Short description: The new route 34854 1299 209243 14618 has been > announced > Path: 34854, 1299, 209243, 14618, > Community: 1299:35000,34854:3001 > Date and time: 2022-08-17 19:39:50 Collected by: 00-2.56.11.1 > > Hjacking didn't last too long. AWS started announcing a more specific > announcement to prevent hijacking around 3 hours later. Kudos to Amazon's > security team :-) > > Type: A > announce Involving: 44.235.216.0/24 > Short description: The new route 58057 34549 5511 1299 16509 has been > announced > Path: 58057, 34549, 5511, 1299, 16509, > Community: 5511:521,5511:666,5511:710,5511:5511,34549:100,34549:5511 > Date and time: 2022-08-17 23:08:47 Collected by: 00-194.50.92.251 > > The attacker cleaned up the IRR objects on 17 Aug and surprisingly no one > seems to notice them ... > > irrd.log-20220819.gz:26517714-ADD 96196 > > irrd.log-20220819.gz:26517724- > > irrd.log-20220819.gz:26517725:as-set: AS-SET209243 > > irrd.log-20220819.gz:26517750-descr: quickhost set > > irrd.log-20220819.gz:26517776-members: AS209243, AS35437, AS37497 > > irrd.log-20220819.gz:26517815-mnt-by: MAINT-QUICKHOSTUK > > irrd.log-20220819.gz:26517845-changed: crussell(a)quickhostuk.net > 20220817 > > irrd.log-20220819.gz:26517891-source: ALTDB > > > > irrd.log-20220819.gz:26517910-DEL 96197 > > irrd.log-20220819.gz:26517920- > > irrd.log-20220819.gz:26517921-route: 44.235.216.0/24 > > irrd.log-20220819.gz:26517949-descr: route > > irrd.log-20220819.gz:26517967-origin: AS16509 > > irrd.log-20220819.gz:26517987-mnt-by: MAINT-QUICKHOSTUK > > irrd.log-20220819.gz:26518017-changed: crussell(a)quickhostuk.net > 20220816 > > irrd.log-20220819.gz:26518063-source: ALTDB > > > > Nowadays hijacking a service by forging AS path is pretty easy and RPKI > won't be able to solve this (as it validates origin AS and prefixes only) > :-( > > Regards, > Siyuan > > >

1 0

DNS-OARC 39 Call for Contributions
by John Todd 22 Aug '22

22 Aug '22

OARC 39 will be a two-day hybrid meeting held on 22 & 23 October in Belgrade, Serbia at 10:00 AM (Local time - CEST (UTC+02:00)) The onsite part of the meeting will be colocated with RIPE 85. The Programme Committee is seeking contributions from the community. All DNS-related subjects and suggestions for discussion topics are welcome. For inspiration, we provide a non-exhaustive list of ideas: - Operations: Any operational gotchas, lessons learned from an outage, details/reasons for a recent outage (how to improve TTR, tooling). - Deployment: DNS config management and release process. - Monitoring: Log ingestion pipeline, analytics infrastructure, anomaly detection. - Scaling: DNS performance management and metrics. Increasing DNS Server Efficiency - Security/Privacy: DNSSEC signing and validation, key storage, rollovers, qname minimization, DoH/DoT As it is a hybrid workshop, we'd like to encourage brevity; presentations should not be longer than 20 minutes (with additional time for questions). Workshop Milestones: 2022-09-06 Deadline for submission (23:59 UTC) 2022-09-08 Preliminary list of contributions published 2022-09-20 Full agenda published 2022-10-03 Deadline for slideset submission and Rehearsal 2022-10-22 OARC 39 Workshop - Day1 2022-10-23 OARC 39 Workshop - Day2 The Registration page and details for presentation submission are published at: <https://www.dns-oarc.net/oarc39> To allow the Programme Committee to make objective assessments of submissions, so as to ensure the quality of the workshop, submissions SHOULD include slides. Draft slides are acceptable on submission. Additional information for speakers at OARC 39: - Your talk will be broadcast live and recorded for future reference - Your presentation slides will be available for delegates and others to download and refer to, before, during and after the meeting - Remote speakers have mandatory rehearsal on 2022-10-04 at 14:00 UTC. It would be very useful to have your slides (even if draft) ready for this. Note: DNS-OARC provides registration fee waivers for the workshop to support those who are part of underrepresented groups to speak at and/or attend DNS-OARC. More details will be provided when registration opens. If you have questions or concerns you can contact the Programme Committee: https://www.dns-oarc.net/oarc/programme via <submissions(a)dns-oarc.net> John Todd, for the DNS-OARC Programme Committee OARC depends on sponsorship to fund its workshops and associated social events. Please contact <sponsor(a)dns-oarc.net> if your organization is interested in becoming a sponsor. (Please note that OARC is run on a non-profit basis, and is not in a position to reimburse expenses or time for speakers at its meetings.) -- John Todd - jtodd(a)quad9.net General Manager - Quad9 Recursive Resolve

1 0

dump of NOS config examples
by guardian.wheel9069＠fastmail.com 22 Aug '22

22 Aug '22

Hi, I am looking for a large dump of example, real but scrubbed, whatever, nx-os, junos, panos, ios, eos, hell any common NOS, configs. (Right now I really need nx-os but I'll get to the rest soon) To be clear, I am not looking for anyone's private config or network info. I just need a large sample of configs to test some config parsing code I have. Looking for every random ugly feature / config option out there. The bigger and uglier the better. (Files that still even have the horrid control chars ^M, \r\n and worse that come out of network devices are the best!!) Once again, not looking for hack dump of random company X(though I'll take anything legal). Hoping to not going fishing in malware infested waters for questionable zip files. While I cannot really think of what kind of source would give me what I am looking for on the up and up, that's what I am hoping for. Thanx for any help anyone can provide.

3 3

Anyone from Cloudflare peering about?
by Bryan Holloway 21 Aug '22

21 Aug '22

Trying to fix a peer and not getting much traction through peering@ ... Feel free to contact me off-list. Thanks!

1 1

if you make the peace today i will call mr.obama
by VOLKAN KIRIK 21 Aug '22

21 Aug '22

if you make the peace today i will call mr.obama i mean the biden. and shut down your operations both white house should call me immediately. ps. turkish translator is required. however i may correct him/her in case of bad translation isnt this list moderated or.. trolling allowed!??

2 3

Re: (off list) Re: cogent and henet not peering
by VOLKAN KIRIK 21 Aug '22

21 Aug '22

you can always be at my service. as i am the god. working 7/24 at no markup. +905520094078 god's hotline. IM always responded. calls maybe. i mean the allah. 21.08.2022 05:06 tarihinde jkinney23(a)yahoo.ca yazdı: > I am still all riled up. I can't get over him sending that message. > I'm glad I want to check out his linkedin profile. > > Happy I could be of service to you. :) > On Saturday, August 20, 2022, 07:00:15 p.m. PDT, VOLKAN KIRIK > <volkirik(a)gmail.com> wrote: > > > if you are happy i am happy. > > i dont care negative people much. > > > 21.08.2022 04:53 tarihinde jkinney23(a)yahoo.ca > <mailto:jkinney23@yahoo.ca> yazdı: > Hey Volkan, > > I just emailed the list moderator to let them know it was optional to > post my message to the list. As long as you know some twit with > three years experience running around calling himself executive > director just harassed you, I'm happy. > > Have a great day! > > Jason > On Saturday, August 20, 2022, 06:50:05 p.m. PDT, VOLKAN KIRIK > <volkirik(a)gmail.com> <mailto:volkirik@gmail.com> wrote: > > > lol > > 21.08.2022 04:28 tarihinde jkinney23(a)yahoo.ca > <mailto:jkinney23@yahoo.ca> yazdı: > Good thing they have someone with a dish washing skill-set to clean up > their inbox's for them. > On Saturday, August 20, 2022, 06:01:34 p.m. PDT, Peter Potvin via > NANOG <nanog(a)nanog.org> <mailto:nanog@nanog.org> wrote: > > > Hey all, > > Removing Cogent personnel and peering departments from this thread as > I'm sure they don't appreciate the nonsense coming from this list. > > Regards, > Peter Potvin | Executive Director > ------------------------------------------------------------------------------ > *Accuris Technologies Ltd.* > 11-300 Earl Grey Drive, Suite #124, Kanata, Ontario K2T1C1 Canada > Email: peter.potvin(a)accuristechnologies.ca > <mailto:peter.potvin@accuristechnologies.ca> > Office: +1 (877) 352-6105 > Network Operations Centre: +1 (877) 321-1662 > > > On Sat, Aug 20, 2022 at 8:51 PM VOLKAN KIRIK <volkirik(a)gmail.com > <mailto:volkirik@gmail.com>> wrote: > > yea whatever.. > > its upto mike leber and dave schaeffer to decide. they can either > accept or reject the solution > > I have been always believing content creator/provider should pay > expenses (at least excess traffic). > > because they put their server in some datacenter and reach all of > the internet.. their backbone expenses are less.. > > i can understand that todays datacenters including he.net > <http://he.net> are interested to participate in 200-300 IXPs. > > well that acceptable. it should be considered too > > so i would offer both companies 3 cent per mbps for excess traffic. > > ok bye > > > 21.08.2022 03:25 tarihinde Forrest Christian (List Account) yazdı: >> But that traffic was likely requested by and for the benefit of >> the person the traffic is being sent to. >> >> I've always found the argument that the quantity of traffic is >> the indicator of who should pay to be questionable. >> >> If I'm an end user on an eyeball user and request a big download >> or streaming from a provider, isn't it me that caused that >> traffic to flow? One could argue that I am the one that needs to >> pay. >> >> On the other hand, one could argue that it's the provider of the >> content that I requested that needs to pay, since it's their >> content which is being distributed. >> >> When you get to peering between two providers it's almost >> impossible to decide who needs to pay. As I mentioned above, >> passing that traffic is actually to the benefit of both providers. >> >> About the only settlement I could see is where one of the >> providers is bearing most of the transport costs. For example a >> regional provider only peering at one exchange point might expect >> some settlement costs with a big international provider that is >> effectively carrying their traffic both directions around the >> globe. But the quantity of that type of traffic is likely >> minimal in the grand scheme of things. Even then one might >> argue that connectivity to the small provider is still valuable >> to the customers of the large provider. >> >> On Fri, Aug 19, 2022, 9:32 AM VOLKAN KIRIK <volkirik(a)gmail.com >> <mailto:volkirik@gmail.com>> wrote: >> >> the more uploading side pays each month for the excess amount. >> >> as content networks are supposed to pay expenses. >> >> >> what do you think? >> >> >> 19.08.2022 18:28 tarihinde Mike Hammett yazdı: >>> The problem them becomes *who* pays? When do the tables turn >>> as to who pays? >>> >>> The alpha gets paid and the beta does the paying? >>> >>> The network with more POPs gets paid? >>> >>> The network with more downstream ASes gets paid? >>> >>> Is it the same for IPv4 as it is for IPv6? >>> >>> >>> >>> ----- >>> Mike Hammett >>> Intelligent Computing Solutions <http://www.ics-il.com/> >>> <https://www.facebook.com/ICSIL><https://plus.google.com/+IntelligentComputingSolutionsDeKalb><https://www.linkedin.com/company/intelligent-computing-solutions><https://twitter.com/ICSIL> >>> Midwest Internet Exchange <http://www.midwest-ix.com/> >>> <https://www.facebook.com/mdwestix><https://www.linkedin.com/company/midwest-internet-exchange><https://twitter.com/mdwestix> >>> The Brothers WISP <http://www.thebrotherswisp.com/> >>> <https://www.facebook.com/thebrotherswisp><https://www.youtube.com/channel/UCXSdfxQv7SpoRQYNyLwntZg> >>> ------------------------------------------------------------------------ >>> *From: *"VOLKAN KIRIK" <volkirik(a)gmail.com> >>> <mailto:volkirik@gmail.com> >>> *To: *"Rubens Kuhl" <rubensk(a)gmail.com> >>> <mailto:rubensk@gmail.com> >>> *Cc: *nanog(a)nanog.org <mailto:nanog@nanog.org>, >>> dschaeffer(a)cogentco.com <mailto:dschaeffer@cogentco.com>, >>> peering(a)cogentco.com <mailto:peering@cogentco.com> >>> *Sent: *Friday, August 19, 2022 10:22:00 AM >>> *Subject: *Re: cogent and henet not peering >>> >>> this is 50/50 situation. nobody has to peer for free. >>> >>> but everyone can. >>> >>> lets just say above 1:1 ratio he.net <http://he.net> pays >>> their own ip transit price to cogent for paid peering excess >>> amount and both sides monitor traffic >>> >>> we can solve this issue by becoming middlemen worldwide... >>> >>> both operators are cheap and they could all compete in quality. >>> >>> level3 pays comcast reasonable (cheap) price (under NDA >>> maybe?). why wouldnt mleber? >>> >>> but to make it fair, as he.net <http://he.net> becomes ww >>> tier-1 operator day-by-day, lets just limit pricing to >>> excess amount of traffic >>> >>> thanks for reading >>> >>> would appreciate your support >>> >>> >>> 19.08.2022 18:09 tarihinde Rubens Kuhl yazdı: >>> >>> OTOH, knowing that Cogent loves splitting the global Internet is onegood reason to not contract their services.I think they sell traffic to their private Intranet. Which is huge,but doesn't encompass the whole Internet.RubensOn Fri, Aug 19, 2022 at 12:04 PM VOLKAN KIRIK<volkirik(a)gmail.com> <mailto:volkirik@gmail.com> wrote: >>> >>> lets just say cogent gives 400GE in each pop they have in common withhe.net <http://he.net> for free.BUT they will rate-limithe.net <http://he.net> links to previous month's 95th percentile upload or download (which is minimum) rate (each month)to make ratio 1:1... to make downstream and upstream traffics fair...okay?fine?come on people,segmentation is bad. >>> >>> > > The information contained in this message may be privileged, > confidential and protected from disclosure. This message is intended > only for the designated recipient(s). It is subject to access, review > and disclosure by the sender's Email System Administrator. If you have > received this message in error, please advise by return e-mail so that > our address records can be corrected and please delete immediately > without reading, copying or forwarding to others. Any unauthorized > review, use, disclosure or distribution is prohibited. > Copyright © 2022 Accuris Technologies Ltd. All Rights Reserved. > > L'information contenue dans ce message pourrait être de nature > privilégiée, confidentielle et protégée contre toute divulgation. Ce > message est destiné à l'usage exclusif du(des) destinataire(s) > visé(s). Le gestionnaire de système du courrier électronique de > l'expéditeur pourrait avoir accès à ce message, l'examiner et le > divulguer. Si ce message vous est transmis par erreur, veuillez nous > en aviser par courrier électronique à notre adresse, afin que l'on > puisse corriger nos registres, puis veuillez le supprimer > immédiatement, sans le lire, le copier ou le transmettre à des tiers. > Tout examen, toute utilisation, divulgation ou distribution non > autorisé de cette information est interdit. > Droit d'auteur © 2022 Accuris Technologies Ltd. Tous droits réservés.

2 2

[correction fluid] if you make the peace today i will call mr.obama
by VOLKAN KIRIK 21 Aug '22

21 Aug '22

if you *dont* make the peace today i will call mr.obama i mean the biden. and shut down your operations both white house should call me immediately. ps. turkish translator is required. however i may correct him/her in case of bad translation isnt this list moderated or.. trolling allowed!?? why correction fluid: i am confused after i couldnt shutdown both nsps so i decided to shutdown both

1 0

Re: cogent and henet not peering
by VOLKAN KIRIK 21 Aug '22

21 Aug '22

lol 21.08.2022 04:28 tarihinde jkinney23(a)yahoo.ca yazdı: > Good thing they have someone with a dish washing skill-set to clean up > their inbox's for them. > On Saturday, August 20, 2022, 06:01:34 p.m. PDT, Peter Potvin via > NANOG <nanog(a)nanog.org> wrote: > > > Hey all, > > Removing Cogent personnel and peering departments from this thread as > I'm sure they don't appreciate the nonsense coming from this list. > > Regards, > Peter Potvin | Executive Director > ------------------------------------------------------------------------------ > *Accuris Technologies Ltd.* > 11-300 Earl Grey Drive, Suite #124, Kanata, Ontario K2T1C1 Canada > Email: peter.potvin(a)accuristechnologies.ca > Office: +1 (877) 352-6105 > Network Operations Centre: +1 (877) 321-1662 > > > On Sat, Aug 20, 2022 at 8:51 PM VOLKAN KIRIK <volkirik(a)gmail.com> wrote: > > yea whatever.. > > its upto mike leber and dave schaeffer to decide. they can either > accept or reject the solution > > I have been always believing content creator/provider should pay > expenses (at least excess traffic). > > because they put their server in some datacenter and reach all of > the internet.. their backbone expenses are less.. > > i can understand that todays datacenters including he.net > <http://he.net> are interested to participate in 200-300 IXPs. > > well that acceptable. it should be considered too > > so i would offer both companies 3 cent per mbps for excess traffic. > > ok bye > > > 21.08.2022 03:25 tarihinde Forrest Christian (List Account) yazdı: >> But that traffic was likely requested by and for the benefit of >> the person the traffic is being sent to. >> >> I've always found the argument that the quantity of traffic is >> the indicator of who should pay to be questionable. >> >> If I'm an end user on an eyeball user and request a big download >> or streaming from a provider, isn't it me that caused that >> traffic to flow? One could argue that I am the one that needs to >> pay. >> >> On the other hand, one could argue that it's the provider of the >> content that I requested that needs to pay, since it's their >> content which is being distributed. >> >> When you get to peering between two providers it's almost >> impossible to decide who needs to pay. As I mentioned above, >> passing that traffic is actually to the benefit of both providers. >> >> About the only settlement I could see is where one of the >> providers is bearing most of the transport costs. For example a >> regional provider only peering at one exchange point might expect >> some settlement costs with a big international provider that is >> effectively carrying their traffic both directions around the >> globe. But the quantity of that type of traffic is likely >> minimal in the grand scheme of things. Even then one might >> argue that connectivity to the small provider is still valuable >> to the customers of the large provider. >> >> On Fri, Aug 19, 2022, 9:32 AM VOLKAN KIRIK <volkirik(a)gmail.com> >> wrote: >> >> the more uploading side pays each month for the excess amount. >> >> as content networks are supposed to pay expenses. >> >> >> what do you think? >> >> >> 19.08.2022 18:28 tarihinde Mike Hammett yazdı: >>> The problem them becomes *who* pays? When do the tables turn >>> as to who pays? >>> >>> The alpha gets paid and the beta does the paying? >>> >>> The network with more POPs gets paid? >>> >>> The network with more downstream ASes gets paid? >>> >>> Is it the same for IPv4 as it is for IPv6? >>> >>> >>> >>> ----- >>> Mike Hammett >>> Intelligent Computing Solutions <http://www.ics-il.com/> >>> <https://www.facebook.com/ICSIL><https://plus.google.com/+IntelligentComputingSolutionsDeKalb><https://www.linkedin.com/company/intelligent-computing-solutions><https://twitter.com/ICSIL> >>> Midwest Internet Exchange <http://www.midwest-ix.com/> >>> <https://www.facebook.com/mdwestix><https://www.linkedin.com/company/midwest-internet-exchange><https://twitter.com/mdwestix> >>> The Brothers WISP <http://www.thebrotherswisp.com/> >>> <https://www.facebook.com/thebrotherswisp><https://www.youtube.com/channel/UCXSdfxQv7SpoRQYNyLwntZg> >>> ------------------------------------------------------------------------ >>> *From: *"VOLKAN KIRIK" <volkirik(a)gmail.com> >>> <mailto:volkirik@gmail.com> >>> *To: *"Rubens Kuhl" <rubensk(a)gmail.com> >>> <mailto:rubensk@gmail.com> >>> *Cc: *nanog(a)nanog.org, dschaeffer(a)cogentco.com, >>> peering(a)cogentco.com >>> *Sent: *Friday, August 19, 2022 10:22:00 AM >>> *Subject: *Re: cogent and henet not peering >>> >>> this is 50/50 situation. nobody has to peer for free. >>> >>> but everyone can. >>> >>> lets just say above 1:1 ratio he.net <http://he.net> pays >>> their own ip transit price to cogent for paid peering excess >>> amount and both sides monitor traffic >>> >>> we can solve this issue by becoming middlemen worldwide... >>> >>> both operators are cheap and they could all compete in quality. >>> >>> level3 pays comcast reasonable (cheap) price (under NDA >>> maybe?). why wouldnt mleber? >>> >>> but to make it fair, as he.net <http://he.net> becomes ww >>> tier-1 operator day-by-day, lets just limit pricing to >>> excess amount of traffic >>> >>> thanks for reading >>> >>> would appreciate your support >>> >>> >>> 19.08.2022 18:09 tarihinde Rubens Kuhl yazdı: >>> >>> OTOH, knowing that Cogent loves splitting the global Internet is onegood reason to not contract their services.I think they sell traffic to their private Intranet. Which is huge,but doesn't encompass the whole Internet.RubensOn Fri, Aug 19, 2022 at 12:04 PM VOLKAN KIRIK<volkirik(a)gmail.com> <mailto:volkirik@gmail.com> wrote: >>> >>> lets just say cogent gives 400GE in each pop they have in common withhe.net <http://he.net> for free.BUT they will rate-limithe.net <http://he.net> links to previous month's 95th percentile upload or download (which is minimum) rate (each month)to make ratio 1:1... to make downstream and upstream traffics fair...okay?fine?come on people,segmentation is bad. >>> >>> > > The information contained in this message may be privileged, > confidential and protected from disclosure. This message is intended > only for the designated recipient(s). It is subject to access, review > and disclosure by the sender's Email System Administrator. If you have > received this message in error, please advise by return e-mail so that > our address records can be corrected and please delete immediately > without reading, copying or forwarding to others. Any unauthorized > review, use, disclosure or distribution is prohibited. > Copyright © 2022 Accuris Technologies Ltd. All Rights Reserved. > > L'information contenue dans ce message pourrait être de nature > privilégiée, confidentielle et protégée contre toute divulgation. Ce > message est destiné à l'usage exclusif du(des) destinataire(s) > visé(s). Le gestionnaire de système du courrier électronique de > l'expéditeur pourrait avoir accès à ce message, l'examiner et le > divulguer. Si ce message vous est transmis par erreur, veuillez nous > en aviser par courrier électronique à notre adresse, afin que l'on > puisse corriger nos registres, puis veuillez le supprimer > immédiatement, sans le lire, le copier ou le transmettre à des tiers. > Tout examen, toute utilisation, divulgation ou distribution non > autorisé de cette information est interdit. > Droit d'auteur © 2022 Accuris Technologies Ltd. Tous droits réservés.

1 0

cogent and henet not peering
by VOLKAN KIRIK 21 Aug '22

21 Aug '22

lets just say cogent gives 400GE in each pop they have in common with he.net for free. *BUT* they will rate-limit he.net links *to* previous month's 95th percentile upload or download (which is minimum) rate (*each month*) to make ratio 1:1... to make downstream and upstream traffics fair... okay? fine? come on people, segmentation is bad.

5 9

Re: Read: IPv6 internet broken, cogent/hurricane not peering
by VOLKAN KIRIK 20 Aug '22

20 Aug '22

the lesson of (/for) the he.net kolayın tuzağına düşme do not fall into trap of the easy way. now tier1 league of them will take like forever for never

2 1