Some problems never go away, just reappear periodically -- strict uRPF (and even loose uRPF) on transit provider peering interfaces are going to have unintended consequences as long as their is routing asymmetry on the Internet (pretty much guaranteed to be forever): http://www.nanog.org/mailinglist/mailarchives/old_archive/1999-03/msg00125.h... Adi On 2013-12-09, Jean Benoit <jean@unistra.fr> wrote:

--KdquIMZPjGJQvRdI Content-Type: text/plain; charset=utf-8 Content-Disposition: inline

Hello,

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 : Hospital,University(20252),NLR(19401),GEANT(20965),RENATER(2200),Our site(2259)

- 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,

-- Jean Benoit University of Strasbourg

--KdquIMZPjGJQvRdI Content-Type: text/plain; charset=utf-8 Content-Disposition: attachment; filename="traceroute_from_143.104_to_130.79.txt"

----------------------------------------------------------------------

Traceroute from 143.103 to 130.79 :

1 143.104.11.49 0 msec 0 msec 0 msec 2 143.104.11.34 0 msec 0 msec 0 msec 3 10.174.255.146 0 msec 0 msec 0 msec 4 10.174.1.138 0 msec 0 msec 0 msec 5 te-7-1-nydc1-1300-d-core02.med.cornell.edu (10.10.100.6) 0 msec 0 msec 0 msec 6 gi-3-2-nydc1-1300-fw01.med.cornell.edu (157.139.0.129) 0 msec 0 msec 0 msec 7 vl-10-nydc1-1300-ingw01.med.cornell.edu (157.139.0.65) 0 msec 0 msec 4 msec 8 157.139.255.9 0 msec 0 msec 4 msec 9 * * * 10 216.24.184.86 84 msec 84 msec 84 msec 11 ae3.mx1.ams.nl.geant.net (62.40.98.115) 92 msec 84 msec 84 msec 12 ae0.mx1.fra.de.geant.net (62.40.98.128) 84 msec 84 msec 88 msec 13 ae1.mx1.gen.ch.geant.net (62.40.98.108) 108 msec 104 msec 96 msec 14 ae2.rt1.gen.ch.geant.net (62.40.112.13) 92 msec 92 msec 92 msec 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * *

----------------------------------------------------------------------

--KdquIMZPjGJQvRdI--

--