I thought those problems were fixed as well, or I would not have changed the submission address. I am not aware of any changes that would have affected the connectivity of 44.0.0.1. It should be working.
More details might be helpful, such as the actual IP addresses involved, or perhaps traceroutes showing where the routing stops working.
Yes, I think it worked but likely that was on the previous gateway. The system is 44.137.40.2 (89.18.172.156)
The route is:
44.0.0.1 via 169.228.34.84 dev tunl0 proto ampr-ripd onlink
A traceroute immediately fails. (only stars)
tshark dump of a "ping" (looks OK): Internet Protocol Version 4, Src: 89.18.172.156 (89.18.172.156), Dst: 169.228.34.84 (169.228.34.84) Version: 4 Header Length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport)) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00) Total Length: 104 Identification: 0x949e (38046) Flags: 0x02 (Don't Fragment) 0... .... = Reserved bit: Not set .1.. .... = Don't fragment: Set ..0. .... = More fragments: Not set Fragment offset: 0 Time to live: 64 Protocol: IPIP (4) Header checksum: 0xd40c [validation disabled] [Good: False] [Bad: False] Source: 89.18.172.156 (89.18.172.156) Destination: 169.228.34.84 (169.228.34.84) [Source GeoIP: Unknown] [Destination GeoIP: Unknown] Internet Protocol Version 4, Src: 44.137.40.2 (44.137.40.2), Dst: 44.0.0.1 (44.0.0.1) Version: 4 Header Length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport)) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00) Total Length: 84 Identification: 0x8f7f (36735) Flags: 0x02 (Don't Fragment) 0... .... = Reserved bit: Not set .1.. .... = Don't fragment: Set ..0. .... = More fragments: Not set Fragment offset: 0 Time to live: 64 Protocol: ICMP (1) Header checksum: 0x2a9e [validation disabled] [Good: False] [Bad: False] Source: 44.137.40.2 (44.137.40.2) Destination: 44.0.0.1 (44.0.0.1) [Source GeoIP: Unknown] [Destination GeoIP: Unknown] Internet Control Message Protocol Type: 8 (Echo (ping) request) Code: 0 Checksum: 0xbba6 [correct] Identifier (BE): 23938 (0x5d82) Identifier (LE): 33373 (0x825d) Sequence number (BE): 1 (0x0001) Sequence number (LE): 256 (0x0100) Timestamp from icmp data: Jul 12, 2017 20:30:58.200360000 CEST [Timestamp from icmp data (relative): 0.000371000 seconds] Data (48 bytes)
0000 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 ................ 0010 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 ........ !"#$%&' 0020 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 ()*+,-./01234567 Data: 08090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f... [Length: 48]
This system has our own gateway 213.222.29.194 as its default tunnel route but otherwise it is a standard ampr-ripd setup with 2 route tables.
Rob
Rob, it looks like the problem might be nearer to you...
Interestingly, when I traceroute to 44.137.40.2 with 169.228.34.84 as the source address, I get:
[...] 17 134.222.48.210 166.647 ms 171.325 ms 190.417 ms 18 134.222.93.145 170.079 ms 170.018 ms 166.474 ms 19 194.109.5.78 166.557 ms 166.552 ms 170.232 ms 20 213.222.29.194 170.381 ms 170.270 ms 170.219 ms 21 213.222.29.194 170.269 ms 166.322 ms 166.387 ms
When I repeat that traceroute with 44.0.0.1 as the source address, it gets nearly as far, but not quite:
[...] 17 134.222.48.210 189.100 ms 188.969 ms 188.970 ms 18 134.222.93.145 188.907 ms 188.889 ms 192.844 ms 19 194.109.5.78 188.831 ms 189.681 ms 194.109.5.58 189.231 ms 20 * * * 21 * * *
I can ping 213.222.29.194 from 169.228.34.84, but not from 44.0.0.1.
It looks, at first glance, like there's a 44 path problem in 213.222.29.194. - Brian