Page MenuHomePhabricator

Apply uRPF strict mode on Customer links
Closed, ResolvedPublic


In T244147 we deployed uRPF loose mode to drop traffic from bogon IPs.

Our borders filters prevent customers (external) to spoof our own IP space, as well as use private space.

As good internet citizen we should also ensure that they can't spoof any other public IPs.

That's what uRPF strict mode is for.
If the router receives a packet on an interface with uRPF strict mode configured, it will check if it has a route back to that IP through the same interface. If not, the packet will be dropped.

We're keeping unicast-reverse-path feasible-paths to also consider non-active paths.
And we will use fail-filter log-only first to make sure no legit traffic is being dropped.

Event Timeline

ayounsi created this task.
Restricted Application added a subscriber: Aklapper. · View Herald Transcript

Change 636653 had a related patch set uploaded (by Ayounsi; owner: Ayounsi):
[operations/homer/public@master] Add uRPF strict mode to Customers links

Mentioned in SAL (#wikimedia-operations) [2020-10-28T11:46:30Z] <XioNoX> configure urpf strict log-only on cr3-ulsfo:et-0/0/1.501 - T266561

Pushed the following:

[edit interfaces et-0/0/1 unit 501 family inet]
+       rpf-check {
+           apply-groups-except external-links;
+           fail-filter log-only4;
+       }
[edit firewall family inet]
      filter vrrp-in4 { ... }
+     filter log-only4 {
+         term default {
+             then {
+                 syslog;
+                 accept;
+             }
+         }
+     }
      filter sample-drop4 { ... }

rpf-check mode strict is not a valid keyword (the Juniper doc is incorrect, I sent them feedback).
So I had to replaced it with rpf-check apply-groups-except external-links;
To prevent the mode loose of the group to be applied automatically.

Example of logs that would be blocked so far:
Oct 28 11:54:39 cr4-ulsfo fpc0 PFE_FW_SYSLOG_ETH_IP: FW: et-0/0/1.501 D 01f5:0800 f0:4b:3a:ef:7a:4f -> ec:38:73:75:34:cf tcp 194.x.x.x 55765 51200 (1 packets)

f0:4b:3a:ef:7a:4f is cr3-ulsfo, so those seem to be packets to cr4-ulsfo:et-0/0/1.501's IP, arriving on cr3-ulsfo where the same vlan is present.
cr4 not expecting packets from the internet coming in through that interface, it is "dropping" them.
This is a side effect of having a /29 vlan as interco instead of point to point links.
However we're not expecting to see any such traffic (from the internet to the interco IPs) so it's fine do discard it.

Another one:
Oct 28 12:08:13 cr4-ulsfo fpc0 PFE_FW_SYSLOG_ETH_IP: FW: et-0/0/1.501 A 01f5:0800 ac:1f:6b:c4:38:c8 -> ec:38:73:75:34:cf tcp 64.x 202.y 30799 54744 (1 packets)

64.x is a Zayo IP, most likely in use on the 2nd office uplink. Packet comes from

Change 636653 merged by jenkins-bot:
[operations/homer/public@master] Add uRPF strict mode to Customers links

Mentioned in SAL (#wikimedia-operations) [2020-11-02T08:46:16Z] <XioNoX> add uRPF strict to ulsfo office links - T266561