Routing asymetry and RPF check

Mailman List Mirror (Read Only)
1

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,

traceroute_from_143.104_to_130.79.txt (1.07 KB)

2

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.html

Adi

3

I can't imagine why uRPF/loose would be problematic. If you're originating
traffic from prefix which you're not advertising to DFZ and you still expect
it to work, your expectation are at fault, not uRPF/loose.

However uRPF/strict feasible won't work, while occasionally some people seem
to think it does.