- Test - lists.nanog.org

ZANOG@iweek 2024 - Call for Presentations
by Amreesh Phokeer 25 Jan '24

25 Jan '24

2024 Mar 12-14, Western Cape, ZA https://www.iweek.org.za CALL FOR PRESENTATIONS ====================== The ZANOG24 Programme Committee is now seeking contributions for presentations for the ZANOG24 Conference. Please submit online at: https://events.nog.net.za/event/48/abstracts/ Conference Milestones ------------------------------------------ Call for Papers Opens: Now Outline Programme Published: As Papers Confirmed Final Deadline for Submissions: 26 February 2024 Final Program Published: 29 February 2024 Final Slides Received: 5 March 2024 SLOTS ARE FILLED ON A FIRST-COME, FIRST-SERVED BASIS, REGARDLESS OF PUBLISHED DEADLINES Programme Content ------------------------------------------ Topics proposed must be relevant to Internet Operations and Technologies, for example: - IPv4 / IPv6 Routing and Operations - Routing Security, including RPKI and routing best practices - Internet backbone operations - Peering, Interconnects and IXPs - Content Distribution Network technology & operations - Research on Internet Operations and Deployment - Managing load shedding for network operations - Medium/Long term strategies for handling energy costs and supply - Network Virtualisation - Network Automation/Programming - Network Infrastructure security - IPv6 deployment on fixed and Wireless/Cellular networks - DNS / DNSSEC and DNS best practices - Access and Transport Technologies - Technical application of Web 3.0, public blockchains and cryptocurrency - Content & Service Delivery and "Cloud Computing" - Low Earth Orbit (LEO) satellite systems - Submarine Cable ecosystems - Large Generative AI Models in telecommunications CFP Submission ------------------------------------------ Draft slides MUST be provided with CFP submissions otherwise the submission will be rejected immediately. For work in progress, the most current information available at the time of submission is acceptable. All draft and complete slides must be submitted in PDF format only. Slides must be of original work, with all company confidential marks removed. Presentations with commercial/sales content will NOT be accepted. Final slides are to be provided by the specified deadline for publication on the ZANOG website. Any questions or concerns should be addressed to the Programme Committee Chairs by e-mail at: pc(a)nog.net.za Sponsor opportunities are still available for this event, please email info(a)nog.net.za for more details. We look forward to receiving your presentation proposals. ZANOG24 Programme Committee Chairs

1 0

N90 Agenda + Room Block Closing Tomorrow
by Nanog News 24 Jan '24

24 Jan '24

Good afternoon, The NANOG 90 agenda is now posted and can be found on the NANOG website, here <https://nanog.org/events/nanog-90/agenda/>! Please “heart” + download saved talks to your local calendar. Do not miss your favorite talks as they happen live; register <https://nanog.org/events/nanog-90/register/> today! Also, please note that the NANOG 90 room block at Le Méridien / Sheraton Charlotte will close tomorrow, Thursday, January 25. Links to online reservations can be found here <https://nanog.org/events/nanog-90/hotel-venue/>. Sincerely, NANOG Staff

1 0

Networks ignoring prepends?
by William Herrin 24 Jan '24

24 Jan '24

Howdy, Does anyone have suggestions for dealing with networks who ignore my BGP route prepends? I have a primary ingress with no prepends and then several distant backups with multiple prepends of my own AS number. My intention, of course, is that folks take the short path to me whenever it's reachable. A few years ago, Comcast decided it would prefer the 5000 mile, five-prepend loop to the short 10 mile path. I was able to cure that with a community telling my ISP along that path to not advertise my route to Comcast. Today it's Centurylink. Same story; they'd rather send the packets 5000 miles to the other coast and back than 10 miles across town. I know they have the correct route because when I withdraw the distant ones entirely, they see and use it. But this time it's not just one path; they prefer any other path except the one I want them to use. And Centurylink is not a peer of those ISPs, so there doesn't appear to be any community I can use to tell them not to use the route. I hate to litter the table with a batch of more-specifics that only originate from the short, preferred link but I'm at a loss as to what else to do. Advice would be most welcome. Regards, Bill Herrin -- William Herrin bill(a)herrin.us https://bill.herrin.us/

21 65

IPv4 address block
by KARIM MEKKAOUI 24 Jan '24

24 Jan '24

Hi Nanog Community Any idea please on the best way to buy IPv4 blocs and what is the price? Thank you KARIM

57 192

edgecast - lots of traffic at ~3:00 a.m.
by Aaron Gould 23 Jan '24

23 Jan '24

Anyone else see a lot of traffic inbound from the Internet last night (early this morning) at ~3:00 a.m. central time? I see an IP Address, (93.184.215.240 - EdgeCast), which I think is EdgIO (fka limelight). Any idea what this is related to? (something tells me it's a game update) -- -Aaron

4 3

Any clue as to when bgp.he.net will be back?
by Hank Nussbacher 23 Jan '24

23 Jan '24

Thanks, Hank

11 13

Mail to Microsoft being falsely marked as spam/bulk
by Christopher Hawker 23 Jan '24

23 Jan '24

Hi folks, I'm having an issue with Microsoft email filtering, where it is flagging messages from a private mail server as spam, with an SCL of 9 and a BCL of 7, resulting in it being sent to the Junk folder. We are not seeing this issue with Google's mail environment (being filtered to junk), confirmed that SPF, DMARC and DKIM are all correct and valid and that the domain and IP addresses are not on any block lists. If there is anyone from Microsoft around that can look into mail issues, could you please reach out to me off-list? Or if anyone has any ideas/suggestions as to how to resolve this, I'd be thankful to hear from you. Thanks, Christopher Hawker

4 7

IRR information & BYOIP (Bring Your Own IP) with Cloud Providers
by kubanowy 22 Jan '24

22 Jan '24

Hi, We have our own prefix assignment from ARIN. We have our infrastructure in GCP (Google Cloud Platform) where we started using BYOIP functionality (Google advertises our IPs). We followed their recommendation with ROA configuration in ARIN cloud.google.com https://cloud.google.com/vpc/docs/bring-your-own-ip#live-migration-recommen… but they don't mention if IRR (whois database) should be updated as well. I've checked with their support and they said no additional changes need to be done there. But currently we are in situation where ARIN's whois contains entry for our prefix with our own ASN and Google advertised to RADb entry for our prefixes with their own ASN. When we use online tools like irrexplorer.nlnog.net https://irrexplorer.nlnog.net/ or Cisco's CrossWork Cloud (former BGPmon), they mark our prefixes due to mismatch of ASN in those 2 databases. We haven't observed any routing issues so far (i.e. ISP not importing our prefixes), but we aim to sort this out for better credibility. I'm wondering what's community approach for updating whois databases when using BYOIP functionality with Cloud providers and if there is a risk of any potential impact if we were to change information in ARIN. Thanks

5 9

Odp: Re: IRR information & BYOIP (Bring Your Own IP) with Cloud Providers
by kubanowy 22 Jan '24

22 Jan '24

Dnia 21 stycznia 2024 21:07 Christopher Morrow <morrowc.lists(a)gmail.com> napisał(a): On Fri, Jan 19, 2024, 4:55 PM Owen DeLong via NANOG < nanog(a)nanog.org > wrote: Sounds like you’ve got a weird mix of route origination. Why wouldn’t you advertise to Google via BGP and have your prefix originate from your own ASN? I think in this case the customer has their own disconnected deployment, and they are asking 396982 to announce some subset of their prefixes such that gcp gets that traffic. Yes, this is the case. GCP is advertising our prefix on our behalf. Owen On Jan 19, 2024, at 02:39, kubanowy < kubanowy(a)o2.pl > wrote: Hi, We have our own prefix assignment from ARIN. We have our infrastructure in GCP (Google Cloud Platform) where we started using BYOIP functionality (Google advertises our IPs). We followed their recommendation with ROA configuration in ARIN cloud.google.com https://cloud.google.com/vpc/docs/bring-your-own-ip#live-migration-recommen… but they don't mention if IRR (whois database) should be updated as The roa is really for two reasons: 1) tell Google you actually control that asset. 2) tell the world that 396982 is permitted to originate that prefix. Use of irr data is nice, but not required here... This is understood, however due to missing entries in IRR those tools flag those prefixes as suspicious to mismatch between what's advertised and what's in ARIN database. My goal is to avoid it. I'm looking for information on what's community approach for this. How this should be handled? well. I've checked with their support and they said no additional changes need to be done there. But currently we are in situation where ARIN's whois contains entry for our prefix with our own ASN and Google advertised to RADb entry for our prefixes with their own ASN. I don't believe to robots at google are supposed to register irr data for byoip customers... Can you mail me off list and I can go do a.little digging? ;) I haven't seen info on that in their documentation, but we did notice a new entry in RADb for prefix that we added in GCP that had MAINT set to Google. When we use online tools like irrexplorer.nlnog.net https://irrexplorer.nlnog.net/ or Cisco's CrossWork Cloud (former BGPmon), they mark our prefixes due to mismatch of ASN in those 2 databases. We haven't observed any routing issues so far (i.e. ISP not importing our prefixes), but we aim to sort this out for better credibility. I'm wondering what's community approach for updating whois databases when using BYOIP functionality with Cloud providers and if there is a risk of any potential impact if we were to change information in ARIN. Thanks

2 1

Odp: Re: IRR information & BYOIP (Bring Your Own IP) with Cloud Providers
by kubanowy 22 Jan '24

22 Jan '24

We don't advertise our prefix anymore from any actual DataCenter, we still own prefixes and ASN and GCP is only place we want to advertise it. Dnia 21 stycznia 2024 23:39 Owen DeLong <owen(a)delong.com> napisał(a): On Jan 21, 2024, at 12:07, Christopher Morrow <morrowc.lists(a)gmail.com> wrote: On Fri, Jan 19, 2024, 4:55 PM Owen DeLong via NANOG < nanog(a)nanog.org > wrote: Sounds like you’ve got a weird mix of route origination. Why wouldn’t you advertise to Google via BGP and have your prefix originate from your own ASN? I think in this case the customer has their own disconnected deployment, and they are asking 396982 to announce some subset of their prefixes such that gcp gets that traffic. If that’s the case, IMHO, the better solution is to obtain a second ASN and announce that to GCP. Create ROAs (if you want to use RPKI) accordingly. Having Google originate prefixes on your behalf that are a subset of what you are announcing is just asking for difficulties you don’t need. Owen

1 0