I am curious to understand the specific differences between "standard" RIPv2 and the "RIP44" used by AMPR. I read on the wiki that 44net uses a "modified RIP advertisements".
I find that tcpdump can decode these packets, showing the destination nextwor and next hop address. Why is a standard ripd unable to process these?
Not complaining - just curious :)
Thanks, Aaron, M6PIU
A standard ripd won't ever see the RIP44 packets because they're encapsulated in an IPIP tunnel packet. The standard ripd doesn't know how to de-encapsulate them first. - Brian
On Mon, Oct 01, 2018 at 07:33:37PM +0100, Aaron Jackson wrote:
I am curious to understand the specific differences between "standard" RIPv2 and the "RIP44" used by AMPR. I read on the wiki that 44net uses a "modified RIP advertisements".
I find that tcpdump can decode these packets, showing the destination nextwor and next hop address. Why is a standard ripd unable to process these?
Not complaining - just curious :)
Thanks, Aaron, M6PIU _________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Ah - seems obvious now. Thanks!
On 1 October 2018 at 19:37 BST, Brian Kantor wrote:
A standard ripd won't ever see the RIP44 packets because they're encapsulated in an IPIP tunnel packet. The standard ripd doesn't know how to de-encapsulate them first.
- Brian
On Mon, Oct 01, 2018 at 07:33:37PM +0100, Aaron Jackson wrote:
I am curious to understand the specific differences between "standard" RIPv2 and the "RIP44" used by AMPR. I read on the wiki that 44net uses a "modified RIP advertisements".
I find that tcpdump can decode these packets, showing the destination nextwor and next hop address. Why is a standard ripd unable to process these?
Not complaining - just curious :)
Thanks, Aaron, M6PIU _________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Hi,
There is a big difference in how the packets are processed.
The regular RIPv2 sets a route to a specific subnet via the sender and interface where the RIP broadcast was received on. The gateway information is used only as an optimization element, in case a route with to that gateway already exists so that the one with the lower metric gets chosen.
In our case, we use the RIP announcements to transport the subnet AND gateway information.
So, assuming a point to multipoint interface, if there is let's say an announcement 44.128.0.0/24 via 1.2.3.4 coming from 44.0.0.1 on the ipip0 interface, regular RIPv2 would translate this to:
44.128.0.0/24 via 44.0.0.1 if ipip0
while ampr rip would translate this to:
44.128.0.0/24 via 1.2.3.4 if ipip0
In the first case, traffic to 44.128.0.0/24 is sent directly to the gateway (the RIP sender), while in the second case it is encapsulated to 1.2.3.4.
On a mikrotik router it even goes a step further: it creates a ipip tunnel interface, ampr-1.2.3.4 to 1.2.3.4 and creates a route
44.128.0.0/24 via ampr-1.2.3.4
This is the processing in the usual case, for 44 subnets having a 44net gateway we assume that the gateway is published by BGP and is directly reachable, so for a announcement like 44.128.0.0/24 via 44.128.0.1 there are 2 route set:
44.128.0.1 via default-gw (which is autodetected), and 44.128.0.0/24 via 44.128.0.1 if ipip0 to do the encapsulation
So, while the information structure in both cases conforms to the RIPv2 specifications, its usage is completely different.
Marius, YO2LOJ
I see - thanks for that. It makes much more sense. It would be great if this was described on the Wiki. I'm also interested in updating the Ubiquti EdgeRouter page as I have gotten rip44d running on it. Getting this running is not currently described on the Wiki.
Thanks again for the explanation of how the routing is carried out.
Aaron, M6PIU.
On 1 October 2018 at 22:29 BST, Marius Petrescu wrote:
Hi,
There is a big difference in how the packets are processed.
The regular RIPv2 sets a route to a specific subnet via the sender and interface where the RIP broadcast was received on. The gateway information is used only as an optimization element, in case a route with to that gateway already exists so that the one with the lower metric gets chosen.
In our case, we use the RIP announcements to transport the subnet AND gateway information.
So, assuming a point to multipoint interface, if there is let's say an announcement 44.128.0.0/24 via 1.2.3.4 coming from 44.0.0.1 on the ipip0 interface, regular RIPv2 would translate this to:
44.128.0.0/24 via 44.0.0.1 if ipip0
while ampr rip would translate this to:
44.128.0.0/24 via 1.2.3.4 if ipip0
In the first case, traffic to 44.128.0.0/24 is sent directly to the gateway (the RIP sender), while in the second case it is encapsulated to 1.2.3.4.
On a mikrotik router it even goes a step further: it creates a ipip tunnel interface, ampr-1.2.3.4 to 1.2.3.4 and creates a route
44.128.0.0/24 via ampr-1.2.3.4
This is the processing in the usual case, for 44 subnets having a 44net gateway we assume that the gateway is published by BGP and is directly reachable, so for a announcement like 44.128.0.0/24 via 44.128.0.1 there are 2 route set:
44.128.0.1 via default-gw (which is autodetected), and 44.128.0.0/24 via 44.128.0.1 if ipip0 to do the encapsulation
So, while the information structure in both cases conforms to the RIPv2 specifications, its usage is completely different.
Marius, YO2LOJ
It would be nice if you would make a post in here how you managed to install ripd44 on the edgerouter. Then the manager of the wiki could also post it on the wiki.
Le 1 oct. 2018 à 18:09, Aaron Jackson aaron@aaronsplace.co.uk a écrit :
I see - thanks for that. It makes much more sense. It would be great if this was described on the Wiki. I'm also interested in updating the Ubiquti EdgeRouter page as I have gotten rip44d running on it. Getting this running is not currently described on the Wiki.
Thanks again for the explanation of how the routing is carried out.
Aaron, M6PIU.
On 1 October 2018 at 22:29 BST, Marius Petrescu wrote:
Hi,
There is a big difference in how the packets are processed.
The regular RIPv2 sets a route to a specific subnet via the sender and interface where the RIP broadcast was received on. The gateway information is used only as an optimization element, in case a route with to that gateway already exists so that the one with the lower metric gets chosen.
In our case, we use the RIP announcements to transport the subnet AND gateway information.
So, assuming a point to multipoint interface, if there is let's say an announcement 44.128.0.0/24 via 1.2.3.4 coming from 44.0.0.1 on the ipip0 interface, regular RIPv2 would translate this to:
44.128.0.0/24 via 44.0.0.1 if ipip0
while ampr rip would translate this to:
44.128.0.0/24 via 1.2.3.4 if ipip0
In the first case, traffic to 44.128.0.0/24 is sent directly to the gateway (the RIP sender), while in the second case it is encapsulated to 1.2.3.4.
On a mikrotik router it even goes a step further: it creates a ipip tunnel interface, ampr-1.2.3.4 to 1.2.3.4 and creates a route
44.128.0.0/24 via ampr-1.2.3.4
This is the processing in the usual case, for 44 subnets having a 44net gateway we assume that the gateway is published by BGP and is directly reachable, so for a announcement like 44.128.0.0/24 via 44.128.0.1 there are 2 route set:
44.128.0.1 via default-gw (which is autodetected), and 44.128.0.0/24 via 44.128.0.1 if ipip0 to do the encapsulation
So, while the information structure in both cases conforms to the RIPv2 specifications, its usage is completely different.
Marius, YO2LOJ
I can edit pages on the wiki. Give me the info, and I’ll add it in. On Mon, Oct 1, 2018 at 6:29 PM pete M petem001@hotmail.com wrote:
It would be nice if you would make a post in here how you managed to install ripd44 on the edgerouter. Then the manager of the wiki could also post it on the wiki.
Le 1 oct. 2018 à 18:09, Aaron Jackson aaron@aaronsplace.co.uk a écrit
:
I see - thanks for that. It makes much more sense. It would be great if this was described on the Wiki. I'm also interested in updating the Ubiquti EdgeRouter page as I have gotten rip44d running on it. Getting this running is not currently described on the Wiki.
Thanks again for the explanation of how the routing is carried out.
Aaron, M6PIU.
On 1 October 2018 at 22:29 BST, Marius Petrescu wrote:
Hi,
There is a big difference in how the packets are processed.
The regular RIPv2 sets a route to a specific subnet via the sender and interface where the RIP broadcast was received on. The gateway information is used only as an optimization element, in case a route with to that gateway already exists so that the one with the lower metric gets chosen.
In our case, we use the RIP announcements to transport the subnet AND gateway information.
So, assuming a point to multipoint interface, if there is let's say an announcement 44.128.0.0/24 via 1.2.3.4 coming from 44.0.0.1 on the
ipip0
interface, regular RIPv2 would translate this to:
44.128.0.0/24 via 44.0.0.1 if ipip0
while ampr rip would translate this to:
44.128.0.0/24 via 1.2.3.4 if ipip0
In the first case, traffic to 44.128.0.0/24 is sent directly to the gateway (the RIP sender), while in the second case it is encapsulated to 1.2.3.4.
On a mikrotik router it even goes a step further: it creates a ipip tunnel interface, ampr-1.2.3.4 to 1.2.3.4 and creates a route
44.128.0.0/24 via ampr-1.2.3.4
This is the processing in the usual case, for 44 subnets having a 44net gateway we assume that the gateway is published by BGP and is directly reachable, so for a announcement like 44.128.0.0/24 via 44.128.0.1
there
are 2 route set:
44.128.0.1 via default-gw (which is autodetected), and 44.128.0.0/24 via 44.128.0.1 if ipip0 to do the encapsulation
So, while the information structure in both cases conforms to the RIPv2 specifications, its usage is completely different.
Marius, YO2LOJ
I'm happy to post here now. Although, I'm not sure everything is working correctly yet. The routes are definitely setup via rip44d:
# ip route | grep ^44 | head 44.0.0.1 via 169.228.34.84 dev tun0 onlink window 840 44.2.0.1 via 191.183.136.1 dev tun0 onlink window 840 44.2.2.0/24 via 216.218.207.198 dev tun0 onlink window 840 44.2.7.0/30 via 98.208.73.100 dev tun0 onlink window 840 ...
Here's what you need to do to get rip44d running:
curl -O https://raw.github.com/hessu/rip44d/master/rip44d chmod u+x rip44d configure set system package repository wheezy components 'main contrib non-free' set system package repository wheezy distribution wheezy set system package repository wheezy url http://http.us.debian.org/debian commit save sudo apt-get install libio-socket-multicast-perl sudo ./rip44d -i tun0 -p <the password>
** Definitely do not run apt-get upgrade - warned on the Ubiquti Wiki **
I still do not have my routing working properly though. I am unable to ping any anything in 44/8. Still trying to figure this out, but having fun in the process. It is probably something obvious, although they are definitely going out the right interface.
$ ping 44.0.0.1 PING 44.0.0.1 (44.0.0.1) 56(84) bytes of data. ^C --- 44.0.0.1 ping statistics --- 206 packets transmitted, 0 received, 100% packet loss, time 205183ms
$ sudo tcpdump -i tun0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes 23:59:13.362459 IP 44.139.48.22 > gw.ampr.org: ICMP echo request, id 12976, seq 200, length 64 23:59:14.362442 IP 44.139.48.22 > gw.ampr.org: ICMP echo request, id 12976, seq 201, length 64 23:59:15.362404 IP 44.139.48.22 > gw.ampr.org: ICMP echo request, id 12976, seq 202, length 64 23:59:16.362477 IP 44.139.48.22 > gw.ampr.org: ICMP echo request, id 12976, seq 203, length 64
$ ip route get 44.0.0.1 44.0.0.1 via 169.228.34.84 dev tun0 src 44.139.48.22 cache expires 509sec mtu 1472 window 840
Hopefully the above to get rip44d will be of some use to someone anyway.
Thanks, Aaron, M6PIU
On 1 October 2018 at 23:28 BST, pete M wrote:
It would be nice if you would make a post in here how you managed to install ripd44 on the edgerouter. Then the manager of the wiki could also post it on the wiki.
Le 1 oct. 2018 à 18:09, Aaron Jackson aaron@aaronsplace.co.uk a écrit :
I see - thanks for that. It makes much more sense. It would be great if this was described on the Wiki. I'm also interested in updating the Ubiquti EdgeRouter page as I have gotten rip44d running on it. Getting this running is not currently described on the Wiki.
Thanks again for the explanation of how the routing is carried out.
Aaron, M6PIU.
On 1 October 2018 at 22:29 BST, Marius Petrescu wrote:
Hi,
There is a big difference in how the packets are processed.
The regular RIPv2 sets a route to a specific subnet via the sender and interface where the RIP broadcast was received on. The gateway information is used only as an optimization element, in case a route with to that gateway already exists so that the one with the lower metric gets chosen.
In our case, we use the RIP announcements to transport the subnet AND gateway information.
So, assuming a point to multipoint interface, if there is let's say an announcement 44.128.0.0/24 via 1.2.3.4 coming from 44.0.0.1 on the ipip0 interface, regular RIPv2 would translate this to:
44.128.0.0/24 via 44.0.0.1 if ipip0
while ampr rip would translate this to:
44.128.0.0/24 via 1.2.3.4 if ipip0
In the first case, traffic to 44.128.0.0/24 is sent directly to the gateway (the RIP sender), while in the second case it is encapsulated to 1.2.3.4.
On a mikrotik router it even goes a step further: it creates a ipip tunnel interface, ampr-1.2.3.4 to 1.2.3.4 and creates a route
44.128.0.0/24 via ampr-1.2.3.4
This is the processing in the usual case, for 44 subnets having a 44net gateway we assume that the gateway is published by BGP and is directly reachable, so for a announcement like 44.128.0.0/24 via 44.128.0.1 there are 2 route set:
44.128.0.1 via default-gw (which is autodetected), and 44.128.0.0/24 via 44.128.0.1 if ipip0 to do the encapsulation
So, while the information structure in both cases conforms to the RIPv2 specifications, its usage is completely different.
Marius, YO2LOJ
44.0.0.1 can not be pinged via the tunnel, only via internet.
You need to try other tunnel endpoints, but really need to find a live one :-)
You could try 44.182.21.1...
On 02.10.2018 02:07, Aaron Jackson wrote:
I'm happy to post here now. Although, I'm not sure everything is working correctly yet. The routes are definitely setup via rip44d:
# ip route | grep ^44 | head 44.0.0.1 via 169.228.34.84 dev tun0 onlink window 840 44.2.0.1 via 191.183.136.1 dev tun0 onlink window 840 44.2.2.0/24 via 216.218.207.198 dev tun0 onlink window 840 44.2.7.0/30 via 98.208.73.100 dev tun0 onlink window 840 ...Here's what you need to do to get rip44d running:
curl -O https://raw.github.com/hessu/rip44d/master/rip44d chmod u+x rip44d configure set system package repository wheezy components 'main contrib non-free' set system package repository wheezy distribution wheezy set system package repository wheezy url http://http.us.debian.org/debian commit save sudo apt-get install libio-socket-multicast-perl sudo ./rip44d -i tun0 -p <the password> ** Definitely do not run apt-get upgrade - warned on the Ubiquti Wiki **I still do not have my routing working properly though. I am unable to ping any anything in 44/8. Still trying to figure this out, but having fun in the process. It is probably something obvious, although they are definitely going out the right interface.
$ ping 44.0.0.1 PING 44.0.0.1 (44.0.0.1) 56(84) bytes of data. ^C --- 44.0.0.1 ping statistics --- 206 packets transmitted, 0 received, 100% packet loss, time 205183ms $ sudo tcpdump -i tun0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes 23:59:13.362459 IP 44.139.48.22 > gw.ampr.org: ICMP echo request, id 12976, seq 200, length 64 23:59:14.362442 IP 44.139.48.22 > gw.ampr.org: ICMP echo request, id 12976, seq 201, length 64 23:59:15.362404 IP 44.139.48.22 > gw.ampr.org: ICMP echo request, id 12976, seq 202, length 64 23:59:16.362477 IP 44.139.48.22 > gw.ampr.org: ICMP echo request, id 12976, seq 203, length 64 $ ip route get 44.0.0.1 44.0.0.1 via 169.228.34.84 dev tun0 src 44.139.48.22 cache expires 509sec mtu 1472 window 840Hopefully the above to get rip44d will be of some use to someone anyway.
Thanks, Aaron, M6PIU
You might try n1uro.ampr.org on 44.88.0.9. It is usually there. Another AMPRNet host which is reliably there day in and day out seems to be kb3vwg-010 on 44.60.44.10. And as Marius says, yo2tm.ampr.org on 44.182.21.1.
Many AMPRNet hosts do not respond to pings (probably out of some mistaken idea that somehow enhances security) but do respond to telnet to their web servers on port 80.
A large number of bots seem to scan for port 80 responders rather than waste time doing ping scans these days. The popular 'nmap' utility does this too. I regularly see scans of the entire 44/8 address space probing for port 80. - Brian
On Tue, Oct 02, 2018 at 09:04:19AM +0300, Marius Petrescu wrote:
44.0.0.1 can not be pinged via the tunnel, only via internet.
You need to try other tunnel endpoints, but really need to find a live one :-)
You could try 44.182.21.1...
On 02/10/18 18:31, Brian Kantor wrote:
You might try n1uro.ampr.org on 44.88.0.9. It is usually there. Another AMPRNet host which is reliably there day in and day out seems to be kb3vwg-010 on 44.60.44.10. And as Marius says, yo2tm.ampr.org on 44.182.21.1.
Many AMPRNet hosts do not respond to pings (probably out of some mistaken idea that somehow enhances security) but do respond to telnet to their web servers on port 80.
44.136.76.1, 44.136.76.2, 44.136.76.3 and 44.136.76.4 should all respond to pings, if you want to test.
Thanks Aaron! Will definitly test that this week.
Le 1 oct. 2018 à 19:09, Aaron Jackson aaron@aaronsplace.co.uk a écrit :
I'm happy to post here now. Although, I'm not sure everything is working correctly yet. The routes are definitely setup via rip44d:
# ip route | grep ^44 | head 44.0.0.1 via 169.228.34.84 dev tun0 onlink window 840 44.2.0.1 via 191.183.136.1 dev tun0 onlink window 840 44.2.2.0/24 via 216.218.207.198 dev tun0 onlink window 840 44.2.7.0/30 via 98.208.73.100 dev tun0 onlink window 840 ...
Here's what you need to do to get rip44d running:
curl -O https://raw.github.com/hessu/rip44d/master/rip44d chmod u+x rip44d configure set system package repository wheezy components 'main contrib non-free' set system package repository wheezy distribution wheezy set system package repository wheezy url http://http.us.debian.org/debian commit save sudo apt-get install libio-socket-multicast-perl sudo ./rip44d -i tun0 -p <the password>
** Definitely do not run apt-get upgrade - warned on the Ubiquti Wiki **
I still do not have my routing working properly though. I am unable to ping any anything in 44/8. Still trying to figure this out, but having fun in the process. It is probably something obvious, although they are definitely going out the right interface.
$ ping 44.0.0.1 PING 44.0.0.1 (44.0.0.1) 56(84) bytes of data. ^C --- 44.0.0.1 ping statistics --- 206 packets transmitted, 0 received, 100% packet loss, time 205183ms
$ sudo tcpdump -i tun0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes 23:59:13.362459 IP 44.139.48.22 > gw.ampr.org: ICMP echo request, id 12976, seq 200, length 64 23:59:14.362442 IP 44.139.48.22 > gw.ampr.org: ICMP echo request, id 12976, seq 201, length 64 23:59:15.362404 IP 44.139.48.22 > gw.ampr.org: ICMP echo request, id 12976, seq 202, length 64 23:59:16.362477 IP 44.139.48.22 > gw.ampr.org: ICMP echo request, id 12976, seq 203, length 64
$ ip route get 44.0.0.1 44.0.0.1 via 169.228.34.84 dev tun0 src 44.139.48.22 cache expires 509sec mtu 1472 window 840
Hopefully the above to get rip44d will be of some use to someone anyway.
Thanks, Aaron, M6PIU
On 1 October 2018 at 23:28 BST, pete M wrote:
It would be nice if you would make a post in here how you managed to install ripd44 on the edgerouter. Then the manager of the wiki could also post it on the wiki.
Le 1 oct. 2018 à 18:09, Aaron Jackson aaron@aaronsplace.co.uk a écrit :
I see - thanks for that. It makes much more sense. It would be great if this was described on the Wiki. I'm also interested in updating the Ubiquti EdgeRouter page as I have gotten rip44d running on it. Getting this running is not currently described on the Wiki.
Thanks again for the explanation of how the routing is carried out.
Aaron, M6PIU.
On 1 October 2018 at 22:29 BST, Marius Petrescu wrote:
Hi,
There is a big difference in how the packets are processed.
The regular RIPv2 sets a route to a specific subnet via the sender and interface where the RIP broadcast was received on. The gateway information is used only as an optimization element, in case a route with to that gateway already exists so that the one with the lower metric gets chosen.
In our case, we use the RIP announcements to transport the subnet AND gateway information.
So, assuming a point to multipoint interface, if there is let's say an announcement 44.128.0.0/24 via 1.2.3.4 coming from 44.0.0.1 on the ipip0 interface, regular RIPv2 would translate this to:
44.128.0.0/24 via 44.0.0.1 if ipip0
while ampr rip would translate this to:
44.128.0.0/24 via 1.2.3.4 if ipip0
In the first case, traffic to 44.128.0.0/24 is sent directly to the gateway (the RIP sender), while in the second case it is encapsulated to 1.2.3.4.
On a mikrotik router it even goes a step further: it creates a ipip tunnel interface, ampr-1.2.3.4 to 1.2.3.4 and creates a route
44.128.0.0/24 via ampr-1.2.3.4
This is the processing in the usual case, for 44 subnets having a 44net gateway we assume that the gateway is published by BGP and is directly reachable, so for a announcement like 44.128.0.0/24 via 44.128.0.1 there are 2 route set:
44.128.0.1 via default-gw (which is autodetected), and 44.128.0.0/24 via 44.128.0.1 if ipip0 to do the encapsulation
So, while the information structure in both cases conforms to the RIPv2 specifications, its usage is completely different.
Marius, YO2LOJ
No worries - I had another look last night but for some reason cannot figure out why I can't get a response back from the gateway. The Pings go out of the right tun interface and I can receive the routes from RIP - so bidirectional communication should be possible. Not sure!
I think I'll leave it for the weekend
Aaron
On 3 October 2018 at 00:15 BST, pete M wrote:
Thanks Aaron! Will definitly test that this week.
Le 1 oct. 2018 à 19:09, Aaron Jackson aaron@aaronsplace.co.uk a écrit :
I'm happy to post here now. Although, I'm not sure everything is working correctly yet. The routes are definitely setup via rip44d:
# ip route | grep ^44 | head 44.0.0.1 via 169.228.34.84 dev tun0 onlink window 840 44.2.0.1 via 191.183.136.1 dev tun0 onlink window 840 44.2.2.0/24 via 216.218.207.198 dev tun0 onlink window 840 44.2.7.0/30 via 98.208.73.100 dev tun0 onlink window 840 ...
Here's what you need to do to get rip44d running:
curl -O https://raw.github.com/hessu/rip44d/master/rip44d chmod u+x rip44d configure set system package repository wheezy components 'main contrib non-free' set system package repository wheezy distribution wheezy set system package repository wheezy url http://http.us.debian.org/debian commit save sudo apt-get install libio-socket-multicast-perl sudo ./rip44d -i tun0 -p <the password>
** Definitely do not run apt-get upgrade - warned on the Ubiquti Wiki **
I still do not have my routing working properly though. I am unable to ping any anything in 44/8. Still trying to figure this out, but having fun in the process. It is probably something obvious, although they are definitely going out the right interface.
$ ping 44.0.0.1 PING 44.0.0.1 (44.0.0.1) 56(84) bytes of data. ^C --- 44.0.0.1 ping statistics --- 206 packets transmitted, 0 received, 100% packet loss, time 205183ms
$ sudo tcpdump -i tun0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes 23:59:13.362459 IP 44.139.48.22 > gw.ampr.org: ICMP echo request, id 12976, seq 200, length 64 23:59:14.362442 IP 44.139.48.22 > gw.ampr.org: ICMP echo request, id 12976, seq 201, length 64 23:59:15.362404 IP 44.139.48.22 > gw.ampr.org: ICMP echo request, id 12976, seq 202, length 64 23:59:16.362477 IP 44.139.48.22 > gw.ampr.org: ICMP echo request, id 12976, seq 203, length 64
$ ip route get 44.0.0.1 44.0.0.1 via 169.228.34.84 dev tun0 src 44.139.48.22 cache expires 509sec mtu 1472 window 840
Hopefully the above to get rip44d will be of some use to someone anyway.
Thanks, Aaron, M6PIU
On 1 October 2018 at 23:28 BST, pete M wrote:
It would be nice if you would make a post in here how you managed to install ripd44 on the edgerouter. Then the manager of the wiki could also post it on the wiki.
Le 1 oct. 2018 à 18:09, Aaron Jackson aaron@aaronsplace.co.uk a écrit :
I see - thanks for that. It makes much more sense. It would be great if this was described on the Wiki. I'm also interested in updating the Ubiquti EdgeRouter page as I have gotten rip44d running on it. Getting this running is not currently described on the Wiki.
Thanks again for the explanation of how the routing is carried out.
Aaron, M6PIU.
On 1 October 2018 at 22:29 BST, Marius Petrescu wrote:
Hi,
There is a big difference in how the packets are processed.
The regular RIPv2 sets a route to a specific subnet via the sender and interface where the RIP broadcast was received on. The gateway information is used only as an optimization element, in case a route with to that gateway already exists so that the one with the lower metric gets chosen.
In our case, we use the RIP announcements to transport the subnet AND gateway information.
So, assuming a point to multipoint interface, if there is let's say an announcement 44.128.0.0/24 via 1.2.3.4 coming from 44.0.0.1 on the ipip0 interface, regular RIPv2 would translate this to:
44.128.0.0/24 via 44.0.0.1 if ipip0
while ampr rip would translate this to:
44.128.0.0/24 via 1.2.3.4 if ipip0
In the first case, traffic to 44.128.0.0/24 is sent directly to the gateway (the RIP sender), while in the second case it is encapsulated to 1.2.3.4.
On a mikrotik router it even goes a step further: it creates a ipip tunnel interface, ampr-1.2.3.4 to 1.2.3.4 and creates a route
44.128.0.0/24 via ampr-1.2.3.4
This is the processing in the usual case, for 44 subnets having a 44net gateway we assume that the gateway is published by BGP and is directly reachable, so for a announcement like 44.128.0.0/24 via 44.128.0.1 there are 2 route set:
44.128.0.1 via default-gw (which is autodetected), and 44.128.0.0/24 via 44.128.0.1 if ipip0 to do the encapsulation
So, while the information structure in both cases conforms to the RIPv2 specifications, its usage is completely different.
Marius, YO2LOJ
If you are attempting to ping 44.0.0.1, you will not get a response. This is due to a bug in the tunneling code at the gateway. Try a tcp connection to port 80 or one of the other common ports to see if you have connectivity to the gateway. - Brian
On Wed, Oct 03, 2018 at 02:00:20PM +0100, Aaron Jackson wrote:
No worries - I had another look last night but for some reason cannot figure out why I can't get a response back from the gateway. The Pings go out of the right tun interface and I can receive the routes from RIP
- so bidirectional communication should be possible. Not sure!
I think I'll leave it for the weekend
Aaron
I thought that bug was fixed some time back...
[kb9mwr@kb9mwr ~]$ ping 44.0.0.1 PING 44.0.0.1 (44.0.0.1) 56(84) bytes of data. 64 bytes from 44.0.0.1: icmp_seq=2 ttl=61 time=62.3 ms
And even from outside 44net:
C:\Users\user>ping 44.0.0.1
Pinging 44.0.0.1 with 32 bytes of data: Reply from 44.0.0.1: bytes=32 time=72ms TTL=48 Reply from 44.0.0.1: bytes=32 time=71ms TTL=48 On Wed, Oct 3, 2018 at 10:00 AM Brian Kantor Brian@bkantor.net wrote:
If you are attempting to ping 44.0.0.1, you will not get a response. This is due to a bug in the tunneling code at the gateway. Try a tcp connection to port 80 or one of the other common ports to see if you have connectivity to the gateway. - Brian
On Wed, Oct 03, 2018 at 02:00:20PM +0100, Aaron Jackson wrote:
No worries - I had another look last night but for some reason cannot figure out why I can't get a response back from the gateway. The Pings go out of the right tun interface and I can receive the routes from RIP
- so bidirectional communication should be possible. Not sure!
I think I'll leave it for the weekend
Aaron
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Pinging 44.0.0.1 from outside 44net has always worked, as far as I know.
I believed the problem with pinging from tunneled hosts was still there, but if it works for you, I must have forgotten.
Sorry for the misinformation. - Brian
On Wed, Oct 03, 2018 at 01:58:58PM -0500, Steve L wrote:
I thought that bug was fixed some time back...
[kb9mwr@kb9mwr ~]$ ping 44.0.0.1 PING 44.0.0.1 (44.0.0.1) 56(84) bytes of data. 64 bytes from 44.0.0.1: icmp_seq=2 ttl=61 time=62.3 ms
And even from outside 44net:
C:\Users\user>ping 44.0.0.1
Pinging 44.0.0.1 with 32 bytes of data: Reply from 44.0.0.1: bytes=32 time=72ms TTL=48 Reply from 44.0.0.1: bytes=32 time=71ms TTL=48
On 04/10/18 05:41, Brian Kantor wrote:
Pinging 44.0.0.1 from outside 44net has always worked, as far as I know.
I believed the problem with pinging from tunneled hosts was still there, but if it works for you, I must have forgotten.Works for me too
Brian, just checked now, and I am getting a ping back from 44.0.0.1. Traceroute confirms it's going via the tunnel.
Yes, it's going via the tunnel. But is it coming back via the tunnel? traceroute won't show assymetric routing. - Brian
On Thu, Oct 04, 2018 at 07:45:51AM +1000, Tony Langdon wrote:
On 04/10/18 05:41, Brian Kantor wrote:
Pinging 44.0.0.1 from outside 44net has always worked, as far as I know.
I believed the problem with pinging from tunneled hosts was still there, but if it works for you, I must have forgotten.Works for me too
Brian, just checked now, and I am getting a ping back from 44.0.0.1. Traceroute confirms it's going via the tunnel.
-- 73 de Tony VK3JED/VK3IRL http://vkradio.com
On 04/10/18 07:52, Brian Kantor wrote:
Yes, it's going via the tunnel. But is it coming back via the tunnel? traceroute won't show assymetric routing.
I can't see how the packet can get back without the tunnel. This site is not BGP connected, only on the IPIP mesh.
It would be interesting to see if tcpdump shows the ping response arriving encapsulated in a tunnel packet or not. - Brian
On Thu, Oct 04, 2018 at 08:08:58AM +1000, Tony Langdon wrote:
I can't see how the packet can get back without the tunnel. This site is not BGP connected, only on the IPIP mesh. -- 73 de Tony VK3JED/VK3IRL http://vkradio.com
To:
22:21:35.179766 IP tenty.ca > amprgw.ucsd.edu: IP ve3tok. > gw.ampr.org: ICMP echo request, id 24603, seq 97, length 64 (ipip-proto-4)
Return:
22:21:35.258376 IP amprgw.ucsd.edu > tenty.ca: IP gw.ampr.org > ve3tok.: ICMP echo reply, id 24603, seq 97, length 64 (ipip-proto-4)
Bob VE3TOK
On 2018-10-03 06:14 PM, Brian Kantor wrote:
It would be interesting to see if tcpdump shows the ping response arriving encapsulated in a tunnel packet or not.
- Brian
On Thu, Oct 04, 2018 at 08:08:58AM +1000, Tony Langdon wrote:
I can't see how the packet can get back without the tunnel. This site is not BGP connected, only on the IPIP mesh. -- 73 de Tony VK3JED/VK3IRL http://vkradio.com
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
I think I'm going to have to draw a diagram of the amprgw setup and trace the journey a packet takes going to and from it before I understand exactly what's going on. I'm no longer sure.
In my copious free time, of course. - Brian
. On Wed, Oct 03, 2018 at 06:31:21PM -0400, Boudewijn (Bob) Tenty wrote:
To:
22:21:35.179766 IP tenty.ca > amprgw.ucsd.edu: IP ve3tok. > gw.ampr.org: ICMP echo request, id 24603, seq 97, length 64 (ipip-proto-4)
Return:
22:21:35.258376 IP amprgw.ucsd.edu > tenty.ca: IP gw.ampr.org > ve3tok.: ICMP echo reply, id 24603, seq 97, length 64 (ipip-proto-4)
Bob VE3TOK
Yes, that is what I see too..
Bob VE3TOK
On 2018-10-03 05:45 PM, Tony Langdon wrote:
On 04/10/18 05:41, Brian Kantor wrote:
Pinging 44.0.0.1 from outside 44net has always worked, as far as I know.
I believed the problem with pinging from tunneled hosts was still there, but if it works for you, I must have forgotten.Works for me too
Brian, just checked now, and I am getting a ping back from 44.0.0.1. Traceroute confirms it's going via the tunnel.
Well much like Tony reported. I am running ampr-ripd (1.16) I use multiple routing tables
I have no specific route for 44.0.0.1, just the default route:
ip route add default dev tunl0 via 169.228.34.84 onlink table 44
And I can ping 44.0.0.1 from my subnet.
I recall some talk about this last summer (July 2017)
But it has been working for me for quite some time (more than 3 years I'd say). I do recall a time when it did not work though. Thinking back to that, there was a time when once and a while there would be packet loss thru the ucsd gateway to my subnet. I seem to recall after Brian Kantor fixed that, that the ping to 44.0.0.1 has worked ever since for me. Sorry that's about as good as I can remember.
Steve, KB9MWR
On Wed, Oct 3, 2018 at 2:43 PM Brian Kantor Brian@bkantor.net wrote:
Pinging 44.0.0.1 from outside 44net has always worked, as far as I know.
I believed the problem with pinging from tunneled hosts was still there, but if it works for you, I must have forgotten.
Sorry for the misinformation. - Brian
On Wed, Oct 03, 2018 at 01:58:58PM -0500, Steve L wrote:
I thought that bug was fixed some time back...
[kb9mwr@kb9mwr ~]$ ping 44.0.0.1 PING 44.0.0.1 (44.0.0.1) 56(84) bytes of data. 64 bytes from 44.0.0.1: icmp_seq=2 ttl=61 time=62.3 ms
And even from outside 44net:
C:\Users\user>ping 44.0.0.1
Pinging 44.0.0.1 with 32 bytes of data: Reply from 44.0.0.1: bytes=32 time=72ms TTL=48 Reply from 44.0.0.1: bytes=32 time=71ms TTL=48
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
-
Aaron Jackson -
Boudewijn (Bob) Tenty -
Brian Kantor -
Marius Petrescu -
Miguel Rodriguez -
pete M -
Steve L -
Tony Langdon