44net

44net@mailman.ampr.org

1 participants
3194 discussions

Re: [44net] 44.192/10 route looping observation
by Rob Janssen 19 Jul '19

19 Jul '19

> I just noticed that traceroutes from my home to, e.g., 44.192.0.1, get > stuck in a routing loop within the rr.com network. Apparently they have some default routes in a loop... My ISP returns a !N Rob

1 0

44.192/10 route looping observation
by Phil Karn 19 Jul '19

19 Jul '19

I just noticed that traceroutes from my home to, e.g., 44.192.0.1, get stuck in a routing loop within the rr.com network. (I'm on Spectrum Cable, formerly Time Warner Cable which branded its service as "roadrunner" (rr.com). I suppose this means Amazon isn't BGP advertising these addresses yet. Traces to, e.g, 44.0.0.1, 44.64.0.1 and 44.128.0.1 all behave as expected. Just an observation. Phil

2 1

Re: [44net] 44/8
by Bryan Fields 19 Jul '19

19 Jul '19

This is a below an email I sent to the NANOG list. On 7/18/19 10:57 PM, Majdi S. Abbas wrote: > > What's interesting about this is it was not an ARIN allocation, > and the ARDC folks are not the original registrant. This IANA /8 was > initially delegated to a community, not an organization. > > So, to the individuals listed in the blog, that I've excerpted > below, what do you have to say about this? > > Brian Kantor > kc claffy > Phil Karn > Paul Vixie This is par for the course with ARDC. I was a TAC committee member (I resigned in disgust just 15 min ago), and the board has failed to inform anyone this was happening. I discussed this prior as we could lease it, do something with it, make some money from it, and was 100% shot down. This has always been Brian Kantor's private little thing ever since he took over administration of it. This take over was before ARDC existed, and ARDC was never structured to be a proper community focused organization. I'd addressed this at TAPR meetings and NANOG with Brian and KC before. This also over looked the huge conflict of interest in KC being a board member of ARDC and Network Telescope getting a feed of 44/8 direct at no cost. This 44/8 announcement and UCSD routing broke connectivity to directly connected BGP subnets for years. My concern as an ARDC supporter an member is now no planning in the community for this, many people assume 44/8 is going to be licensed amateurs (I have many firewalls with permit 44/8 in them), and no accountability of what ARDC is doing. I believe with Brian retiring from UCSD he's looking for a job and being a board member of a well funded 501(c)3 can be a lucrative job. Also it's 100% broken reverse DNS for all of 44/8. :golf clap: This was theft from the community it was meant to serve. -- Bryan Fields, W9CR Former ARDC TAC member 727-409-1194 - Voice http://bryanfields.net

2 1

Reverse DNS broken
by Michael Fox - N6MEF 19 Jul '19

19 Jul '19

Folks, I'm sure folks will want to express their outrage about the address sale for months. In the meantime, let's focus on what we can control. How do we get reverse DNS working again for the part of 44/8 that wasn't sold? Michael, N6MEF

6 9

Re: [44net] Time to restructure the network?
by Rob Janssen 19 Jul '19

19 Jul '19

> But setting up Marius' script on Mikrotik is easy as pie and it > configures the rest "automagically" whereas configuring BGP on a tik, > although easy for those of us that do such things daily, is not that > easy for non network-technical folks Actually, when you think that setting up Marius' script on Mikrotik is easy, you already know enough about MikroTik to make setting up your router as a VPN client to one or a couple of routers on internet and configuring BGP on those VPN links much easier than that. It would be very easy to write a howto for doing that which includes sample configuration where you only need to fill in some fields like the username and password of your VPN, the AS number assigned to you, and the AS number and net-44 address of your peer. Probably even a script could be written that performs the configuration itself based on the few variables it requires, similar to what Marius' script does when installing it. Rob

1 0

Re: [44net] Time to restructure the network?
by Rob Janssen 19 Jul '19

19 Jul '19

> it's still possible to setup a VPN to a remote host and interface with > the IPIP mesh there. It's not idea, but it's a solution. As long as all > the nearby sites have a route over VPN, it can work. By tuning the VPN > parameters, latency can be kept down. That is what we have operating right now. Our 44.137.0.0/16 network is now BGP announced from a datacenter where we have a MikroTik CCR1009 router that has many users connected via different kinds of VPN (L2TP/IPsec, GRE, GRE/IPsec, GRE6 (GRE over IPv6)) and the users run BGP to announce their subnets and receive our subnet. They can (and do) inter-connect using radio links and setup BGP peering over there as well, so the routing between users can be over radio and towards internet over the VPN. We have some BGP communities to steer the routing, e.g. to prefer a multihop radio path over a path via VPN which is always two hops at most. This router is on the IPIP mesh as well, but when that mesh were to be taken down we only would need to setup some similar VPNs and BGP peerings, of course one to UCSD where a router would be for the space not announced separately (44.0.0.0/9 and 44.128.0.0/10), and anyone in the world would have the possibility to setup a VPN server for some subnet (be it BGP announced or not, that does not matter) and serve their local users from it. Users in a region not covered by such a service could connect to UCSD and have similar performance to what it is now. Those VPN servers do not need to peer with ALL others, but they can peer with a couple of them and we still have redundancy. In addition to this, we also offer OpenVPN VPNs without BGP, for users that are endpoints only. A single fixed address is routed to the VPN client when it is connected. This all is really easy for the users to setup, and when the L2TP/IPsec VPN is used it works over all internet connections even when they have dynamic address, are behind CGNAT, have agressive firewalls, or whatever. Should it prove necessary, an SSL based VPN like SSTP could easily be added (it uses TCP port 443 so it always works, but of course VPNs using TCP transport are to be avoided when possible) BGP in the MikroTik routers is configured in a few mouseclicks or a cut-and-paste of a small text fragment. Set the local AS and ID, add a peer with remote address and AS, set 2 or 3 options, and it works. For best operation, use a small routing filter that can be cut-and-paste. Rob

1 0

Re: [44net] Reverse DNS broken
by Rob Janssen 19 Jul '19

19 Jul '19

> I think this is resolved now. Yes it looks like it is. Can you explain how this affects the content of the 44.rev zone file and the configuration of a DNS server that serves that zone? I now have the 44.in-addr.arpa configured in a local DNS server and loaded with that zonefile as downloaded from the FTP server. Rob

2 1

Re: [44net] Time to restructure the network?
by Borja Marcos 19 Jul '19

19 Jul '19

> On 19 Jul 2019, at 12:13, Marc Williams via 44Net <44net(a)mailman.ampr.org> wrote: > > > From: Marc Williams <monsieurmarc(a)btinternet.com> > Subject: Re: [44net] Time to restructure the network? > Date: 19 July 2019 at 12:13:06 CEST > To: Borja Marcos via 44Net <44net(a)mailman.ampr.org> > > > It seems like a an idea worth exploring I agree. Apart from a slight learning curve, with less "auto configured magic" BGP is actually easier to manage. I think it's worth the slight effort. 73, Borja / EA2EKH

1 0

AMPRNet Address Sale
by Rob Janssen 19 Jul '19

19 Jul '19

>No. >https://portal.ampr.org/networks.php <https://portal.ampr.org/networks.php> > 44.224.0.0 / 15 GERMANY > ..with currently ~9500 assignments. > But that's no unresolvable problem. Just answering here to state that there is a large allocation and we do our best to move. > There's no direct bgp announcement for 44.224/15, and connectivity is done ampr-internal via ipip-mesh. Thus except for the dns reverse resolution, we expect no impact and can move step by step to 44.148/15. > The sold of the /10 netblock we are in is not a showstepper, it just makes (a lot of) work. But we also see the chance to configure things better during the renumbering. That was already going on for a while, wasn't it? Of course I saw this coming, by observing changes in the network assignments... But I wonder if the 44.224.0.0 network wouldn't have been better renumbered to 10.224.0.0, that better reflects the nature of the internet connectivity of that network and probably would solve some problems... You could then setup the new 44.148 space with true routing. Rob

1 0

ARDC and AMPR Reform
by Bryan Fields 19 Jul '19

19 Jul '19

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 It's clear we will need to engage with legal counsel regarding the corruption inside ARDC and perpetuated by the board. The people involved in this must be called to answer for their treachery. I have created and email list for strategizing and organizing this: http://lists.keekles.org/cgi-bin/mailman/listinfo/44-reform I also call on the community to not be won over by promises of money and grants from ARDC. The leaders think they will buy the community off. This is tainted money and I call on the community to reject it when offered and expose those who take it. 73's - -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEaESdNosUjpjcN/JhYTmgYVLGkUAFAl0xjNoACgkQYTmgYVLG kUARDA//WJ06KmrXkTiWVsP3osUyEX2HKvJaqGwXYlioEnYHBpeaKYM3wzZRdaO9 /ps9ENc5lSGouKA2Zd9SBUjsKu40VWOT0FUi+CXe49XOL7GZ5X6k75X+hZ4PCsCP 5w+1RUXHOtT3SWIOyVXh0l5uwSOW6azKdVeTFcSGYeyE/lxgsOPwz49CtK6K7DvO O7MxHFbQI2rGCnWmcABuAoz6AImcAFzgGpxe3RwdjWLw+/j7StGyjDT1nEY58cxz AQZParzz/i/eQVZyLI3mBoHfNlKxJvyyeQ0qVbS6phfash2t9I3vnC1NeU6y1JTp yJ5q2B72N2e5cwcVfdtZJzBNIXPmd57LkXr0NijNyzl5cr+OSFwbpYvBa49+hzVR zO4F2RQRvCr1p+i5XZYhH1r+MxaisvcctVzeuMF9Aolz1WoU65AQRqPs/Ek7eefA pXlGd+RAmVlCeoYzhmyzJSqMP0sGneKWH3JmL9xrFhE7jBBLHPEd1TyJxW+mpWLC SSVqTZRVG9Oc7AsQ7DZOtk0GnkW9R5qZTEG0Lnjq/9eTpAaeSZ/viXJYMD/4Kahd QX4Ec21smcw4v7npmGhxAtGvkv//zQsZnMEni51sPdeTa5eZ6+08aEDYvxfRrP8Z W3L3Q6Lw+/LIbgocSu4P73WCAjiS4LAsBCz3Dl0aeHob1V4GQW0= =wmG1 -----END PGP SIGNATURE-----

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net