All,
ASNs 64,512 to 65,534 of the original 16-bit AS range, and 4,200,000,000 to 4,294,967,294 of the 32-bit range are commonly used amongst persons on the same network to coordinate routing, etc.
While, it's not yet feasible, there is much research into technologies (e.g. space elevators), willingness of sponsors for satellites/availability/etc., and availability of machines, embedded devices, network cards, etc. tinkering into consumer-grade hardware capable of multi homing and routing. Also, lets recall, some of our operators have access to carrier-grade devices as well.
Considerations:
- those on BGP'd islands of the Public Internet (announcing their allocations with LOAs/Public ASNs,etc.) would still be so (this is no different than stations with allocations that use their allocations in a manner that would not route back to AMPR anyway), they must be considered as those taking allocations to use without AMPR connection, but there are more options for current and future connectivity with BGP
- RIP44 can still remain in use. In addition, there are multiple methods to remove your own routes and those of others. You simply remove the route of those you peer with, change metrics, etc.
- My router (and, I would assume those of many others that have been flashed, etc.) are capable of forwarding packets, regardless of source/destination IP. We could test the possibility of switching from a star (reliance on AMPRGW's 100% uptime for 'real-time' route updates) to a mesh, where we peer with those who choose, have a large connection, are physically interconnected to one another, etc.
- (in the future) anyone, including those on the Public Internet, could volunteer to announce more specific routes for IPIP allocations (with the proper authorization requested by the allocation holder) and then maintain a tunnel, RF link, etc. - could connect to someone who could provide the AMPRGW.
- there is a movement in many areas to establish HSMM in many regions of the world, but there have been many hindrances to their ability to a.) interconnect beyond their island-of-connectivity and 2.) not rely on the same factor/conditions that could cause a loss of commodity Internet connectivity in order to reach other subnets
- in these considerations, AMPRNet's 100% reliance on AMPRGW and not devising methods not to rely on the commodity Internet for Islands of interconnectivity could cause issues in a real emergency scenario
Goal:
- to attempt to alleviate load/reliance on AMPRGW
- provide redundancy
- test the possibility to geographical alternatives to AMPRGW
- consider test the need of issuance of private ASN space for these purposes
TEST:
I'm looking for anyone currently using IPIP only that's GEOGRAPHICALLY CLOSER (I am connected to the Internet through Verizon via Ashburn/Wash.DC) to me than AMPRGR, AND/OR a BGP's station willing to coordinate establishment of a point-to-point VPN tunnel, over which we will announce our own allocations and/or those in the AMPR test subnet.
I am willing to assist with documentation, graphing etc.
To-do:
- Establish sessions
- setup test hosts
- test multihoming, availability, etc.
- test route prioritization, etc.
- lastly, test (with permission) loss of a stations default route via tunl0 and using the other session
- test with stations who may be located physically nearby (fiber, RF, etc.)
***Please let me know your thoughts, opinions, etc.***
73,
- Lynwood KB3VWG
This sounds nice in theory.
But you still need an initial database of peers to start the connections. And that means a single point of failure and you are back to square 1.
The only way I see this feasible is to use IPv6 which offers global multicast groups. The nodes have only to send out some announcement of presence on that address, and everyone worldwide which is subscribed to that multicast group will get the announcements. But since IPv6 is inaccessible to most of the internet users (due to "not available", "I do not care if I have it" or "I don't want it"), it will have to wait.
Marius, YO2LOJ
-----Original Message----- From: lleachii--- via 44Net Sent: Friday, March 25, 2016 14:37 To: 44net@hamradio.ucsd.edu Cc: lleachii@aol.com Subject: [44net] Testers/Consideration/Inquiry - Coordinating the Private ASNumbers
(Please trim inclusions from previous messages) _______________________________________________ ...
- My router (and, I would assume those of many others that have been flashed, etc.) are capable of forwarding packets, regardless of source/destination IP. We could test the possibility of switching from a star (reliance on AMPRGW's 100% uptime for 'real-time' route updates) to a mesh, where we peer with those who choose, have a large connection, are physically interconnected to one another, etc.
- (in the future) anyone, including those on the Public Internet, could volunteer to announce more specific routes for IPIP allocations (with the proper authorization requested by the allocation holder) and then maintain a tunnel, RF link, etc. - could connect to someone who could provide the AMPRGW.
...
Hmm, there are also global IPv4 multicast addresses :-) Maybe it is worth some testing: 233.0.0.0/8 per RFC2770 - and here AMPR has its own 16 bit AS number, so 256 addresses could be available 234.0.0.0/8 per RFC 6034 - we could use 234.44.x.x in this scheme, even split to country level.
If this would work, that would be great. But it depends on the ISP.
-----Original Message----- From: Marius Petrescu Sent: Friday, March 25, 2016 20:58 To: AMPRNet working group Subject: Re: [44net] Testers/Consideration/Inquiry - Coordinating thePrivate ASNumbers
(Please trim inclusions from previous messages) _______________________________________________ This sounds nice in theory.
But you still need an initial database of peers to start the connections. And that means a single point of failure and you are back to square 1.
The only way I see this feasible is to use IPv6 which offers global multicast groups. The nodes have only to send out some announcement of presence on that address, and everyone worldwide which is subscribed to that multicast group will get the announcements. But since IPv6 is inaccessible to most of the internet users (due to "not available", "I do not care if I have it" or "I don't want it"), it will have to wait.
Marius, YO2LOJ
-----Original Message----- From: lleachii--- via 44Net Sent: Friday, March 25, 2016 14:37 To: 44net@hamradio.ucsd.edu Cc: lleachii@aol.com Subject: [44net] Testers/Consideration/Inquiry - Coordinating the Private ASNumbers
(Please trim inclusions from previous messages) _______________________________________________ ...
- My router (and, I would assume those of many others that have been flashed, etc.) are capable of forwarding packets, regardless of source/destination IP. We could test the possibility of switching from a star (reliance on AMPRGW's 100% uptime for 'real-time' route updates) to a mesh, where we peer with those who choose, have a large connection, are physically interconnected to one another, etc.
- (in the future) anyone, including those on the Public Internet, could volunteer to announce more specific routes for IPIP allocations (with the proper authorization requested by the allocation holder) and then maintain a tunnel, RF link, etc. - could connect to someone who could provide the AMPRGW.
...
_________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
Though Multicast is a fantastic concept, it's far from ubiquitous and not reliable to depend on. So few ISPs route it, so few home routers properly support it, so few hosts allow IGMP, etc. to pass, etc. It's actually quite sad but it's been this way for many many years. If you'd like to see if YOUR system can receive multicast traffic, here is one of the few test streams I could find:
https://support.bbc.co.uk/multicast/streams.html
--David KI6ZHD
On 03/25/2016 12:24 PM, Marius Petrescu wrote:
(Please trim inclusions from previous messages) _______________________________________________ Hmm, there are also global IPv4 multicast addresses :-) Maybe it is worth some testing: 233.0.0.0/8 per RFC2770 - and here AMPR has its own 16 bit AS number, so 256 addresses could be available 234.0.0.0/8 per RFC 6034 - we could use 234.44.x.x in this scheme, even split to country level.
If this would work, that would be great. But it depends on the ISP.
Tnx for the list.
If those are multicasts, I assume I should set up some kind of PIM to be able to route thatin my local network.
-----Original Message----- From: David Ranch Sent: Friday, March 25, 2016 22:26 To: AMPRNet working group Subject: Re: [44net] Testers/Consideration/Inquiry - Coordinating thePrivate ASNumbers
(Please trim inclusions from previous messages) _______________________________________________
Though Multicast is a fantastic concept, it's far from ubiquitous and not reliable to depend on. So few ISPs route it, so few home routers properly support it, so few hosts allow IGMP, etc. to pass, etc. It's actually quite sad but it's been this way for many many years. If you'd like to see if YOUR system can receive multicast traffic, here is one of the few test streams I could find:
https://support.bbc.co.uk/multicast/streams.html
--David KI6ZHD
On 03/25/2016 12:24 PM, Marius Petrescu wrote:
(Please trim inclusions from previous messages) _______________________________________________ Hmm, there are also global IPv4 multicast addresses :-) Maybe it is worth some testing: 233.0.0.0/8 per RFC2770 - and here AMPR has its own 16 bit AS number, so 256 addresses could be available 234.0.0.0/8 per RFC 6034 - we could use 234.44.x.x in this scheme, even split to country level.
If this would work, that would be great. But it depends on the ISP.
a.) then how would a new or offline IPIP station connect if AMPRGW were DOWN at the time? b.) then how do I get routes from AMPRNet without a DIRECT CONNECTION tunl0 connection to AMPRGW? c.) what if I can directly reach 2 or more AMPR subnets (but not the Internet)?
-----Original Message----- I don't understand your consideration of "moving from a star to a mesh". We ALREADY have a mesh! -----------------------------------
a.) AMPRGW is currently the only route announcer (but you address that elsewhere) b.) Next, it's not the ideal route to all subnets c.) this solution addresses the possibility of redundancy to other subnets, as well as AMPRGW
I surmise the response to be more opinion than technical observations.
-----Original Message----- There is no load to be removed from AMPRGW other than the routing from/to internet for those that are not directly BGP routed on internet. -----------------------------------
a.) Your statement is based off the premise the goal is to solve a 'single point of failure for RIP announcements...' such is inaccurate b.) If I conceded that we're in-fact a Mesh topology currently, I likewise concede that we only route in a Star topology
-----Original Message----- When you want a solution for the "single point of failure" for RIP announcements -----------------------------------
In planning, it would probably be an alternative to IPIP, and not a replacement. Ideally, there could be a few regional gateways, other stations connecting to one or more regional gateway and to other end-user gateways.
-----Original Message----- your solution of doing BGP over tunnels instead has such information embedded in the static configuration of all the peers, which is even more difficult to manage. -----------------------------------
It is our intention in Washington Dc to have AMPRNet address in our wireless domain. We do not intend to mesh over the planned infrastructure; it will work like a standard Access Point. I cannot speak for implementation in other areas
-----Original Message----- What is the status of usage of AMPRnet addresses in HSMM? In the past they used RFC1918 addresses that were automatically allocated. I believe newer versions can use static addresses that could als well be from NET-44. Is this already in wide use? -----------------------------------
Rob,
- I'm not certain how one can reach portal.ampr.org before establishing an Internet connection first
- You stated: "This is not a task of AMPRGR but of portal.ampr.org..." The Portal is simply a backend to configure AMPRGW itself; and specifically in the case of IPIP tunnels using RIP44. In the future it plans to add DNS functionality, but keep in mind, this is just merely a website
- I'm not sure how a DNS zone file relates to real-time connectivity to a network
- AMPRGW is not the ideal route to all subnets because it is not the most geographically closest AMPRNet node with an Internet connection. If other nodes were setup in the manner I'd like to test, any node willing to establish a session could potentially be a closer node
- You note again "we have a full mesh:" ***Then please test by pinging MY gateway VIA N1URO's***. In your testing, do not connect directly to me or use AMPRGW. I will DOWN my tunl0 interface and only connect to another AMPR station with AMPRGW connectivity - via RF or over a VPN connection.
+ it's my understanding this would fail - STAR + you imply that it should work - MESH
73,
- KB3VWG
On Fri, Mar 25, 2016 at 2:45 PM, lleachii--- via 44Net 44net@hamradio.ucsd.edu wrote:
- You note again "we have a full mesh:" ***Then please test by pinging MY
gateway VIA N1URO's***. In your testing, do not connect directly to me or use AMPRGW. I will DOWN my tunl0 interface and only connect to another AMPR station with AMPRGW connectivity - via RF or over a VPN connection.
Help me out here. I tried your callsign .ampr.org and I'm not getting any responses:
$ ping KB3VWG.ampr.org PING www.kb3vwg.info (74.96.94.31) 56(84) bytes of data. ^C --- www.kb3vwg.info ping statistics --- 18 packets transmitted, 0 received, 100% packet loss, time 17112ms
Doesn't even appear to be an AMPR address. What should I ping for the test you suggest?
Tom KD7LXL
All,
I also wanted to note, that solves all issues, it simply holds us to something Marius, Tom and myself were discussing:
- We in-fact have a 'physical' mesh network, but our routing scheme has us beholden to a star topology where the AMRGW is its 'logical master'. I actually LIKE this scheme, and it could lend to 'slave/hot-standby logical masters.' In an emergency with our master server/router, another is ready to take over should it go offline.
- I think all other schemes should be voluntary. I do agree we should work on a good logical mesh routing protocol, while embracing our current, working and 100% operational network.
- Lynwood KB3VWG
My gateway is 44.60.44.1
Its hostname is kb3vwg-001.ampr.org (this is a non *nos naming convention, as my gateway never ran *nos)
At this time, tunl0 is still up and running - in normal AMPR IPIP mode - with RIP44 as the routing protocol
- KB3VWG
Marius,
This is just a TEST.
I do not wish to 'abolish' IPIP with RIP44. In fact, it's an excellent solution for us; and Rob's suggestion of simply making other RIP44 announcers is good too (but how do people subscribe/subscribe if they are across another non-point-to-point tunnel (another multicast scheme?).
I am just SEEKING INTEREST in testing another concept. That's all. I have an idea, that needs other willing testers. I'm seeking all comments.
Thanks as always Sir,
KB3VWG
Richard,
Your suggestion is also excellent!
I've suggested something similar years ago.
In fact, we can all keep second metrics for the additional gateway(s)...!
But this GW must have permission to announce 44/8 in-whole on the Public Internet.
- KB3VWG
Rob,
I forgot to include you in my thanks, I appreciate your comments as well.
- I'm not proposing that the Portal be ran on a 44 address. I'm stating that the Portal is not a necessary physical component for all possible networking solutions, albeit a logical one. In fact, the Portal is a Great help, but not NEEDED physically to ensure network connectivity (i.e. in comparison to a fiber cable extending to AMPRGW's NIC, or AMPRGW's CPU(s)). I also pose that if you consider the Portal in this manner, then both AMPRGW and the Portal must be online to maintain the AMPRNet "mesh." * - Solutions to simply make a hot-standby GW or a second RIP44 announcer could help here
- Unless I don't understand the premise - I not grasping your premise that the Portal website somehow ensures [physical] connectivity of the nodes, AMPRGW (and our individual GWs) physically provide this, the Portal - their logical connection. Were AMPRGW or the Portal down/unavailable (or its email counterpart), no new nodes could join the 'AMPRNet mesh' dynamically. Likewise, in an IPENCAP tunnel mode using RIP44, AS Numbers don't apply (I agree). Again, I am proposing a test of another, second, routing schematic entirely (this would REQUIRE some ASN coordination amongst participants in the test or implementation, now or in the future - as there's many scenarios where the the Number couldn't be duplicated). * - Solutions include saving copies of the route table geographically local, this again is not 'real-time' nor dynamic.
- Available DNS servers are listed on the Wiki, there are quite a few on AMPRNet. I'm not proposing that we not have 'some Internet tunnel.' I am proposing a TEST of something additional to IPENCAP tunnels w/ RIP44.
- You stated: "I advise you to study the network topology before proposing to change it. Traffic to another amprnet node does NOT flow through AMPRGW." I'm aware of this; but you insist, that somehow, we're a full mesh (physically), despite not being able to send traffic in that manner without some master first bootstrapping the nodes (logically). Again, I'm just suggesting test of an alternative.
- "This is not what defines a star versus a mesh...The pings I send to your gateway directly travel from my Internet connection to yours, NOT via AMPRGW." Correct again, I'm aware of this...so if we're a full mesh...I'm proposing a method where AMPRGW is not necessary (or not the single point of failure) for: a.) 'bootstrapping', b.) route announcements, c.) route updates, and d.) possibly even connection to the Internet AND e.) BGPed nodes. In fact, my proposal could eventually provide Internet without need for: i.) a single [point-of-failure] master GW and its logical 'network assembler' (the Portal), ii.) a multi-level subnet, or iii.) connection to Commercial Internet
- "We use a multi-level subnet system here. We route the entire country subnet to a single gateway which has radio and VPN connectivity to users in the country. Those users can also have their own IPIP gateway when they like." That's really cool!!! This is also a very good solution!!! I don't think any regions in my area have a setup in that manner!
- Lynwood KB3VWG
All,
I wish to test a remote site from the QTH via Ethernet. The remote location has its own Internet connection I'd also like to utilize. I intend to set it up in the following manner:
tunl0 <<>> 44.60.44.128/25 ROUTER-X <<ETHERNET>> ROUTER-Y 44.60.44.1/25 <<>> **AMPR tunl0**
- router Y will be connected to router X by [Wireless] Ethernet. I'd like to deliver the RIP 44 announcements to this machine from current router Y, so it may use its own commercial Internet connection (on another carrier) to transmit
- through Dynamic DNS, and a local hot-standby script, I intend to have router X to Dynamically possess high availability for my AMPRNet connection
- I understand all replies come through my Portal-registered GW until a standby switchover were to take place
- I understand the delay may be 5 min - 1 hour
* - If I were to do so, would there be any filtering on some of your gateways if the second device transmitted the originating IPENCAP packet for an IP in my registered /24 subnet, instead of my actively registered portal? (If so, what filter are you using? I may be interested in implementing it myself.)
* - Would this filter restriction persist if I were to register a subnet to that device?
* - Would there be a problem if I possessed 2 GWs in the portal with the same IP, but holding 2 different allocations (in case of fail-over)?
Thanks and 73,
- Lynwood KB3VWG
I would say this is a good opportunity to test some rarely used features built into ampr-ripd.
Main site 1 - gateway: - both subnets have this site set as gateway (ignore both subnets via -a option using their 44 subnet) - ampr-ripd running, with RIP forward to site 2 (unicast via -f and -e options)
Secondary site 2: - ampr-ripd running (ignore only site 2 subnet via -a option, with a high metric) - run quagga with RIP on the link interface
On the secondary site, quagga RIP routes will take precedence over the 44net routes, and all ampr traffic will be routed to site B via the direct link. If the link goes down, the quagga routes will time out (in a few minutes) and the direct backup links via ampr tunnel will take over if available, as a backup.
The actual switch could be set up via a script which changes a dynamic dns entry. If the link is active, it should point to site 1, on link failure it should point to site 2. This could be even implemented on site 2 using its local DNS if one manages his own dns server.
In such scenario, no change in the portal data is needed and the switch will happen automagically.
Marius, YO2LOJ
-----Original Message----- From: lleachii--- via 44Net Sent: Saturday, March 26, 2016 13:57 To: 44net@hamradio.ucsd.edu Cc: lleachii@aol.com Subject: [44net] Local Hot-Standby Question
(Please trim inclusions from previous messages) _______________________________________________ All,
I wish to test a remote site from the QTH via Ethernet. The remote location has its own Internet connection I'd also like to utilize. I intend to set it up in the following manner:
tunl0 <<>> 44.60.44.128/25 ROUTER-X <<ETHERNET>> ROUTER-Y 44.60.44.1/25 <<>> **AMPR tunl0**
- router Y will be connected to router X by [Wireless] Ethernet. I'd like to deliver the RIP 44 announcements to this machine from current router Y, so it may use its own commercial Internet connection (on another carrier) to transmit
- through Dynamic DNS, and a local hot-standby script, I intend to have router X to Dynamically possess high availability for my AMPRNet connection
- I understand all replies come through my Portal-registered GW until a standby switchover were to take place
- I understand the delay may be 5 min - 1 hour
* - If I were to do so, would there be any filtering on some of your gateways if the second device transmitted the originating IPENCAP packet for an IP in my registered /24 subnet, instead of my actively registered portal? (If so, what filter are you using? I may be interested in implementing it myself.)
* - Would this filter restriction persist if I were to register a subnet to that device?
* - Would there be a problem if I possessed 2 GWs in the portal with the same IP, but holding 2 different allocations (in case of fail-over)?
Thanks and 73,
- Lynwood KB3VWG
_________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
Marius,
That's excellent!
I think your note added an extra step of complexity (using standard RIP) to solve the issue of devices at Site 2 using the outbound while in Hot-Standy Mode (before entering Hot-Active-Failover).
...Let's assume then (since two portal entries are not needed):
***STANDBY tunl0*** <<>> 44.60.44.128/24 ROUTER-X <<ETHERNET>> ROUTER-Y 44.60.44.1/24 <<>> **AMPR tunl0**
(kept as a flat /24's and a common LAN)
Could the failover take place, thus allowing me to setup (e.g.) a standby http://44.60.44.10 at Site 2?
- Lynwood KB3VWG
(this could also be done with /25's and changing the DNS entry of the hostnames to the 44.60.44.128/25 ranges...if everyone contacts my servers using DNS names)
On 03/26/2016 10:31 AM, lleachii@aol.com wrote:
Could the failover take place, thus allowing me to setup (e.g.) a standby http://44.60.44.10 at Site 2?
This can not be done with a flat LAN, because there would be a need to change gateways for participating machines, which is not possible. And on the other hand, a router has to be able to distinguish between the 2 half, unless you want to bridge the 2 segments.
So the necessary first step would be:
Site A: - standby tunnel endpoint on machine 44.60.44.129 - 44.60.44.128/25 with default gw 44.60.44.129 - route to 44.60.44.0/25 via ethernet - ampr-ripd on 44.60.44.129 - quagga on 44.60.44.129
Site B: - tunnel endpoint on machine 44.60.44.1 - 44.60.44.0/25 with default gw 44.60.44.1 - route to 44.60.44.128/25 via ethernet - ampr-ripd on 44.60.44.1 with RIP forward to 44.60.44.129 via ethernet
The ethernet link can use any private addresses, or, to keep it hamish, 44.128.0.0/24. There is also a possibility to set ethernet link to 44.60.44.0/24 and use proxy arp. This would allow you not to use specific routes.
Marius, YO2LOJ
-----Original Message----- From: lleachii--- via 44Net Sent: Saturday, March 26, 2016 16:31 To: 44net@hamradio.ucsd.edu Cc: lleachii@aol.com Subject: Re: [44net] Local Hot-Standby Question
(Please trim inclusions from previous messages) _______________________________________________ Marius,
That's excellent!
I think your note added an extra step of complexity (using standard RIP) to solve the issue of devices at Site 2 using the outbound while in Hot-Standy Mode (before entering Hot-Active-Failover).
...Let's assume then (since two portal entries are not needed):
***STANDBY tunl0*** <<>> 44.60.44.128/24 ROUTER-X <<ETHERNET>> ROUTER-Y 44.60.44.1/24 <<>> **AMPR tunl0**
(kept as a flat /24's and a common LAN)
Could the failover take place, thus allowing me to setup (e.g.) a standby http://44.60.44.10 at Site 2?
- Lynwood KB3VWG
_________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
All,
I considered that since we:
- have a full mesh - and all those who use RIP44 will have a TRUE copy of all routes
Perhaps consider ways that RIP44 could be updated:
- to bootstrap one another in the case of a failure of AMPRGW (election of a master to send RIP44 announcements, participation in elections disabled by default)
- allow possibility for addition of routes while 'acting AMPRGW' is offline (re-elections with time-stamping/flagging)?
- ability to resume normal operations (AMPRGW is automatically elected/flagged/timestamps-recognized as master/signals send end of elections)
Ideas?
- KB3VWG
Just to be the critic here...
How do you know which peers to contact for elections if you do not have the list yet? Where do you get the peer list from if there is no designated acting AMPRGW yet? The IP protocol has (almost) no way to create a common media access channel to exchange data without knowing your peers first. So you still need the portal.
And with such acting GWs... There has to be a gateway on the internet for 44.0.0.0/24 through which any external source could access any resource on 44net. That means that if that gateway changes, there has to be a BGP update in the global internet BGP table so that every router in the world would know the route. And this takes time. And at some point, half the public internet knows agout one gateway, the other half about another one. And that new gateway is probably in another AS. Which complicates things.
So let me have my doubt about such dynamic gateway assignments from an external point of view. And from the internal one: Most hams have a hard time setting up our current IPIP implementation. Now let's assume they have to setup dynamic gatewaying in addition to that...
Just to circumvent a possible gateway failure, which only manifests itself as the inability of non-ham users accessing a 44net ham resource. (And for important resources, we can always host them on BGP announced subnets if it is really necessary).
I wonder if this is worth the effort. I would rather try to secure the portal and concentrate on a secondary RIP source. AMPRGW is not the weak spot. Missing RIP/encap updates is.
Marius, YO2LOJ
-----Original Message----- From: lleachii--- via 44Net Sent: Saturday, March 26, 2016 17:26 To: 44net@hamradio.ucsd.edu Cc: lleachii@aol.com Subject: [44net] RIP44... v 2???
(Please trim inclusions from previous messages) _______________________________________________ All,
I considered that since we:
- have a full mesh - and all those who use RIP44 will have a TRUE copy of all routes
Perhaps consider ways that RIP44 could be updated:
- to bootstrap one another in the case of a failure of AMPRGW (election of a master to send RIP44 announcements, participation in elections disabled by default)
- allow possibility for addition of routes while 'acting AMPRGW' is offline (re-elections with time-stamping/flagging)?
- ability to resume normal operations (AMPRGW is automatically elected/flagged/timestamps-recognized as master/signals send end of elections)
Ideas?
- KB3VWG
_________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
All,
(just thoughts)...
Perhaps we can run OLSR in addition to RIP44...
- AMPRGW bootstraps all true nodes and the mesh runs in RIP44 Mode
- once routes are received, those wishing to also run OLSR44 could then HELLO those nodes (using a different broadcast address)
- these nodes of course must configure themselves to not filter, and forward traffic for all 44.0.0.0/8
- nodes (unless some layer 2.5/3 filter is running on IPENCAP) should properly receive their traffic, regardless if they run OLSR44, or not.
Thoughts?
- KB3VWG
All,
Thanks!
*Ronen,
"Im not a Network guru (although i worked at ISP 20 years ago But forgot most of the knowledge)... I tend to agree that currently when i now go to any Israeli commercial site from the 44 net ip the packet travel to UCSD and then back to UCSD and by tunnel to me again and this is a long trip...the only thing I can think off is to put a secondary portal for redundancy. Im willing to cooperate..."
"If i do NAT I loose the ability the gain acess the 44 Net Hosts from commercial IP..."
I agree! Let' s also agree on a...(Ethernet?) tunnel...and establish BGP initallty discuss concept and to test... - a few days after this Holy season.
In theory (or my RIP44v2 and testing considerations), you should not need to NAT, we would use another protocol (lower priority, etc.) to route. Therefore, if you have connectivity, you would operate multihomed. When a packets enters a node vias IPIP or tome other tunnel via fail over/receivig route announcements.
*Assi,
"Im willing to cooperate There is a mechanism, it's the point to point tunnels. Most gateways support that..."
Some 'RIP44v2'??? using another port? Another method?
*Rob,
"Please note you will have a constant traffic of several Mbit/s from only the bad guys that are portscanning and the reflection from the bad guys using your addresses as spoofed source address, and this is increasing all the time.
So don't do this from your home, put your router in a datacenter where you have 100 Mbit/s or more."
Agreed!
Marius,
"...There is really no need to access commercial sites using a 44net addresses via the US."
Agreed.
Thanks,
KB3VWG
Sorry, but I think there was an misunderstanding.
I'm not against abolishing anything, if that means progress. But every time something comes up it lingers on a theoretical level.
Let's do it for real, one step at a time. Let's try new things and see how it works. But let's start something. Anything. Personally I am open to ANY test...
Sooo, anyone into direct peering with private BGP routing? Or MPLS, or OSPF or whatever?
Marius, YO2LOJ
-----Original Message----- From: lleachii--- via 44Net Sent: Saturday, March 26, 2016 01:44 To: 44net@hamradio.ucsd.edu Cc: lleachii@aol.com Subject: Re: [44net] Testers/Consideration/Inquiry - Coordinating the Private AS Numbers
(Please trim inclusions from previous messages) _______________________________________________ Marius,
This is just a TEST.
I do not wish to 'abolish' IPIP with RIP44. In fact, it's an excellent solution for us; and Rob's suggestion of simply making other RIP44 announcers is good too (but how do people subscribe/subscribe if they are across another non-point-to-point tunnel (another multicast scheme?).
I am just SEEKING INTEREST in testing another concept. That's all. I have an idea, that needs other willing testers. I'm seeking all comments.
Thanks as always Sir,
KB3VWG
_________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
Yes Marius, ready to start tests with you
F1SCA - Jean-Marc
-----Message d'origine----- De : 44Net [mailto:44net-bounces+f1sca=numericable.fr@hamradio.ucsd.edu] De la part de Marius Petrescu Envoyé : samedi 26 mars 2016 03:03 À : AMPRNet working group 44net@hamradio.ucsd.edu Objet : Re: [44net] Testers/Consideration/Inquiry - Coordinating the Private AS Numbers
(Please trim inclusions from previous messages) _______________________________________________ Sorry, but I think there was an misunderstanding.
I'm not against abolishing anything, if that means progress. But every time something comes up it lingers on a theoretical level.
Let's do it for real, one step at a time. Let's try new things and see how it works. But let's start something. Anything. Personally I am open to ANY test...
Sooo, anyone into direct peering with private BGP routing? Or MPLS, or OSPF or whatever?
Marius, YO2LOJ
-----Original Message----- From: lleachii--- via 44Net Sent: Saturday, March 26, 2016 01:44 To: 44net@hamradio.ucsd.edu Cc: lleachii@aol.com Subject: Re: [44net] Testers/Consideration/Inquiry - Coordinating the Private AS Numbers
(Please trim inclusions from previous messages) _______________________________________________ Marius,
This is just a TEST.
I do not wish to 'abolish' IPIP with RIP44. In fact, it's an excellent solution for us; and Rob's suggestion of simply making other RIP44 announcers is good too (but how do people subscribe/subscribe if they are across another non-point-to-point tunnel (another multicast scheme?).
I am just SEEKING INTEREST in testing another concept. That's all. I have an idea, that needs other willing testers. I'm seeking all comments.
Thanks as always Sir,
KB3VWG
_________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
_________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
Im willing to cooperate I have Cisco 2851 running for our network (44.138.1.x) willing to do anything needed Unfortunately im not so expert (specially in non standard Routing protocols ) But im willing to add any command as needed and willing to give the router Enable password to whenever needed to treat it from remote (i have config backup ) Ronen- 4Z4ZQ http://www.ronen.org
________________________________________ From: 44Net 44net-bounces+ronenp=hotmail.com@hamradio.ucsd.edu on behalf of Marius Petrescu marius@yo2loj.ro Sent: Friday, March 25, 2016 7:03 PM To: AMPRNet working group Subject: Re: [44net] Testers/Consideration/Inquiry - Coordinating the Private AS Numbers
(Please trim inclusions from previous messages) _______________________________________________ Sorry, but I think there was an misunderstanding.
Let's do it for real, one step at a time. Let's try new things and see how it works. But let's start something. Anything. Personally I am open to ANY test...
Sooo, anyone into direct peering with private BGP routing? Or MPLS, or OSPF or whatever?
Marius, YO2LOJ
Im not a Network guru (although i worked at ISP 20 years ago But forgot most of the knowledge) I tend to agree that currently when i now go to any Israeli commercial site from the 44 net ip the packet travel to UCSD and then back to UCSD and by tunnel to me again and this is a long trip If there was a mechanism to allow the traffic to go to any local 44 gateway and then the packet will go to the local Internet the trip would be much shorter but i dont know how it can be done these days that every IPS block Source 44 Net address from passing through as for 44 net to 44 net trafic it look ok because it tunnel direct to the gateway and not passing through AMPRGW the only thing I can think off is to put a secondary portal for redundancy . Ronen - 4Z4ZQ http://www.ronen.org
________________________________________ From: 44Net 44net-bounces+ronenp=hotmail.com@hamradio.ucsd.edu on behalf of lleachii--- via 44Net 44net@hamradio.ucsd.edu Sent: Friday, March 25, 2016 4:44 PM To: 44net@hamradio.ucsd.edu Cc: lleachii@aol.com Subject: Re: [44net] Testers/Consideration/Inquiry - Coordinating the Private AS Numbers
(Please trim inclusions from previous messages) _______________________________________________ Marius,
This is just a TEST.
I do not wish to 'abolish' IPIP with RIP44. In fact, it's an excellent solution for us; and Rob's suggestion of simply making other RIP44 announcers is good too (but how do people subscribe/subscribe if they are across another non-point-to-point tunnel (another multicast scheme?).
I am just SEEKING INTEREST in testing another concept. That's all. I have an idea, that needs other willing testers. I'm seeking all comments.
Thanks as always Sir,
KB3VWG
_________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
Yes there is.
Use your local gateway to NAT the internet traffic to it and access the internet like any other local user. There is really no need to access commercial sites using a 44net addresses via the US.
Marius, YO2LOJ
-----Original Message----- From: R P Sent: Saturday, March 26, 2016 18:17 To: AMPRNet working group Subject: Re: [44net] Testers/Consideration/Inquiry - Coordinating the Private AS Numbers
(Please trim inclusions from previous messages) _______________________________________________ Im not a Network guru (although i worked at ISP 20 years ago But forgot most of the knowledge) I tend to agree that currently when i now go to any Israeli commercial site from the 44 net ip the packet travel to UCSD and then back to UCSD and by tunnel to me again and this is a long trip If there was a mechanism to allow the traffic to go to any local 44 gateway and then the packet will go to the local Internet the trip would be much shorter but i dont know how it can be done these days that every IPS block Source 44 Net address from passing through as for 44 net to 44 net trafic it look ok because it tunnel direct to the gateway and not passing through AMPRGW the only thing I can think off is to put a secondary portal for redundancy . Ronen - 4Z4ZQ http://www.ronen.org
________________________________________ From: 44Net 44net-bounces+ronenp=hotmail.com@hamradio.ucsd.edu on behalf of lleachii--- via 44Net 44net@hamradio.ucsd.edu Sent: Friday, March 25, 2016 4:44 PM To: 44net@hamradio.ucsd.edu Cc: lleachii@aol.com Subject: Re: [44net] Testers/Consideration/Inquiry - Coordinating the Private AS Numbers
(Please trim inclusions from previous messages) _______________________________________________ Marius,
This is just a TEST.
I do not wish to 'abolish' IPIP with RIP44. In fact, it's an excellent solution for us; and Rob's suggestion of simply making other RIP44 announcers is good too (but how do people subscribe/subscribe if they are across another non-point-to-point tunnel (another multicast scheme?).
I am just SEEKING INTEREST in testing another concept. That's all. I have an idea, that needs other willing testers. I'm seeking all comments.
Thanks as always Sir,
KB3VWG
_________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
_________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
If i do NAT I loose the ability the gain acess the 44 Net Hosts from commercial IP (example from my work) and that is not what i would like to do Ronen - 4Z4ZQ http://www.ronen.org
________________________________________ From: 44Net 44net-bounces+ronenp=hotmail.com@hamradio.ucsd.edu on behalf of Marius Petrescu marius@yo2loj.ro Sent: Saturday, March 26, 2016 10:13 AM To: AMPRNet working group Subject: Re: [44net] Testers/Consideration/Inquiry - Coordinating the Private AS Numbers
(Please trim inclusions from previous messages) _______________________________________________ Yes there is.
Use your local gateway to NAT the internet traffic to it and access the internet like any other local user.
I am talking about doing NAT only for sources in your local 44net with destinations that are not 44.0.0.0/8, not for the whole traffic. You will/can keep inbound access to your 44 network via UCSD.
Marius, YO2LOJ
-----Original Message----- From: R P Sent: Saturday, March 26, 2016 19:26 To: AMPRNet working group Subject: Re: [44net] Testers/Consideration/Inquiry - Coordinating the Private AS Numbers
(Please trim inclusions from previous messages) _______________________________________________ If i do NAT I loose the ability the gain acess the 44 Net Hosts from commercial IP (example from my work) and that is not what i would like to do Ronen - 4Z4ZQ http://www.ronen.org
________________________________________ From: 44Net 44net-bounces+ronenp=hotmail.com@hamradio.ucsd.edu on behalf of Marius Petrescu marius@yo2loj.ro Sent: Saturday, March 26, 2016 10:13 AM To: AMPRNet working group Subject: Re: [44net] Testers/Consideration/Inquiry - Coordinating the Private AS Numbers
(Please trim inclusions from previous messages) _______________________________________________ Yes there is.
Use your local gateway to NAT the internet traffic to it and access the internet like any other local user.
_________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
Really people, every month there is some proposal to change the routing, the announcement system, to build up BGP networks and other such proposals. Especially the star versus mesh issue, that obviously a lot don't understand, and still assume that amprgw is the central gateway...
I state the questions over and over again: - What is stopping you to do alternative connections between subnets? - What is stopping you from implementing BGP, OSPF, ISIS, MPLS or whatever you like over direct links with other peers? - What is stopping you to create a secondary RIP deployment on a group of peers, or whatever other route deployment protocol you would like?
Do it and present results, not "what if" discussions. You can do all those things you want, and you don't need the blessing of the group to do it. Unless of course it's all theory and everyone wants someone else to do it first.
There are a lot of network location implementing this kind of techniques, all you have to do is look for them. But try to look across the pond, because in the US you seem to be stuck in plain text 1200baud mode for quite some time, and I really don't understand why.
But please start doing it! If it is wrong, it can be corrected. If it's right, it's a step ahead. But just do it!
Marius, YO2LOJ
-
David Ranch -
f1sca -
lleachii＠aol.com -
Marius Petrescu -
R P -
Tom Hayward