[afnog] mail problem

[Brian Candler]

On Thu, Apr 20, 2006 at 12:10:47PM +0300, Mike Barnard wrote:
>    Hi, ...Brian, couldnt get to anyone on the italy side to run a similar
>    process and get back to me with the results, but this is what i have
>    on my side
>    mail# tcpdump -i rl0 -n -s1500 -v host [1]81.208.64.123
>    tcpdump: listening on rl0
>    10:55:19.096574 41.220.14.11.3744 > 81.208.64.123.110: S [tcp sum ok]
>    666965989:666965989(0) win 65535 <mss 1460,nop,wscale
>    0,nop,nop,timestamp 101344 0> (DF) [tos 0x10]  (ttl 64, id 48385, len
>    60)
>    10:55:22.095482 41.220.14.11.3744 > 81.208.64.123.110: S [tcp sum ok]
>    666965989:666965989(0) win 65535 <mss 1460,nop,wscale
>    0,nop,nop,timestamp 101644 0> (DF) [tos 0x10]  (ttl 64, id 48638, len
>    60)

OK, SYNs are going out, but no SYN ACKs are coming back.

>    for sure the packets are not reaching his mail server at
>    all....tcptraceroute, tracepath, traceroute all end dead at the same
>    point.

Not necessarily. The SYNs might be arriving, but the SYN ACKs might be being
blackholed on the way back. It's very hard to tell for sure without doing
the corresponding dump at the far end.

>    Richard and i are on the same backbone, different blocks of ip
>    addresses. i use a /23 on [2]41.220.14.0 and i believe he is on the
>    [3]217.212.242.0 blocks. a traceroute from both networks takes
>    different paths yet we all exit through the same gateway router. he
>    can reach and i cannot. i noticed that at some point the paths we both
>    take differ...

Probably not relevant. Very few networks use "Policy Routing" - that is,
deciding where to send the packet based on where it came from.

I expect what's happening is there's "Equal Cost Multipath" - two equally
good paths to the same destination. In that case, the router is able to
choose either path, and often it will choose the path based on a hash of
source and destination IPs.

You may find if you traceroute from other machines on your own network (i.e.
from within the same netblock but different IPs) that some will go one way
and some will go another. You'll probably need to test from at least 5
machines to be sure of that.

(I'm assuming there's no NAT going on here, of course)

So what does this leave the problem as? My guess is that there is a routing
issue which means that the remote side can send packets to 217.212.242.0,
but not to 41.220.14.0

Looking at the BGP world from route-views.oregon-ix.net :

* 217.212.224.0/19 is announced by AS1299
* 41.220.0.0/20 is announced by AS29032 which is in turn behind AS1299

Now, AS1299 is Telia; AS29032 is Bushnet.

So there is definitely a difference in the way these two netblocks are
routed. It is possible that one is registered correctly in routing
databases, and the other is not; this could result in the 41.220.0.0/20
route being filtered out by some other ISPs, leading to the problem you
describe.

If on the Italy side you get them to do a traceroute to 41.220.14.11 this
will probably become apparent, as I expect one of the upstream routers will
drop the packet with !H or !N (host or network unreachable)

I'm not really familiar with the gory details of routing databases or
filtering policies on the Internet nowadays, but perhaps someone else on the
list can help you with this further.

Regards,

Brian.