Routing asymetry and RPF check

Mon Dec 9 20:19:20 UTC 2013

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
-------------- next part --------------

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

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

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