It's probably an old problem which was already debated here.
We (130.79/16, AS2259) can't reach 143.104/16 (AS20252).
Actually, all packets are dropped on their way back to our network.
The probable cause is a conjunction of routing asymetry and uRPF check :
- 143.104/16 is behind a US university network. Packets sent
*from 143.104/16* to the rest of the Internet are going through National
Lambda Rail (NLR), a US. research and education network,
- but, as 143.104/16 does not belong to the university but to a hospital
(the network has only a couple of hosts related to public research),
this prefix is not announced to NLR. So packets from the Internet
*to 143.104/16* go through the university commodity Internet link
(a mix of different providers). Thus, there is a routing asymetry.
- on the other side of the Atlantic, 130.79/16 is behind another research
network, RENATER (AS2200). Renater is connected to GEANT, which
federates mots of the European research and education networks.
GEANT peers with NLR.
So the path from 143.104/16 is :
- when a packet arrives from 143.104/16 on a specific RENATER router in
Geneva, geneve-rtr-021.noc.renater.fr, it is dropped.
- On this router, geneve-rtr-021.noc.renater.fr, RENATER peers with GEANT.
- RENATER lookings glass (https://portail.noc.renater.fr/lookingglass/v2/)
tells me that the prefix 143.104/16 is not present in this router's
routing table (this prefix is not learnt by NLR, and not learnt by GEANT).
Moreover, this router seems not to have a full routing table.
- On this router, unicast Reverse Path Forwarding check (unsure if it's
strict or loose) is enabled on the interface between RENATER
and GEANT (PortChannel4.160 to ae14.160 of rt1.gen.ch.geant.net or
mx1.gen.ch.geant.net, see https://tools.geant.net/portal/links/lg/)
The packets with source IP address 143.104/16 are dropped because the
uRPF check fails.
So, what do you think should be done ?
Thanks for your advice,
traceroute_from_143.104_to_130.79.txt (1.07 KB)