Overblog Suivre ce blog
Editer l'article Administration Créer mon blog
1 octobre 2013 2 01 /10 /octobre /2013 17:00

uRPF allows anti-spoofing embedded at forwarding plane level. Junos provides this feature for many years with several modes and options:

  • Loose or Strict mode
  •  Active or Feasible paths uRPF data base 
  • Discard or not supported in the uRPF data base

I carried out several tests on MX960 version 12.3R2 with DPC or MPC cards to test all the possible combinations of uRPF options.

   
1/ Explanations of Modes & options

Modes for DPC:

Strict mode:

  •  Default mode
  •  Accept a packet if the source of the packet (@IP src of the datagram) is known in the FIB and reachable by the interface that receives the packet.
  •  For ECMP paths where several interfaces can be used to reach a destination, this case is by default supported by strict mode. (IGP ECMP or BGP multipath)
  •  Default route with a valid NH is taken into account by default

Loose Mode:

  •  Configurable mode (interface based config)
  •  Accept a packet if the source of the packet (@IP src of the datagram) is known in the FIB
  • Default route with a valid NH is taken into account by default


Modes for MPC:

Strict mode:

  • Default mode
  • Accept a packet if the source of the packet (@IP src of the datagram) is known in the FIB and reachable by the interface that receives the packet.
  • For ECMP paths where several interfaces can be used to reach a destination, this case is by default supported by strict mode. (IGP ECMP or BGP multipath)
  • Default route with a valid NH is taken into account by default

Loose Mode:

  • Configurable mode (interface based config)
  • Accept a packet if the source of the packet (@IP src of the datagram) is known in the FIB
  • Default route with a valid NH is treated as unknown route


Option 1 (for DPC and MPC):

By default uRPF uses only the best path. Indeed, within the FIB only the best paths are available except if you use features like FRR (Fast ReRoute) LFA (Loop Free Alternate). Otherwise, there is no backup path in the FIB, only the RIB keeps those information.

This default behavior is called “active-paths”. To take into account the backup paths at FIB level, known in the RIB, you need to activate the option “feasible-paths”. This feature pushes in the FIB uRPF database, the active path but also the backup path(s) .

Note: this feature requests a little bit more memory at PFE level (adds ifl-list-nh entries)

Option 2 (only for MPC):

Routes with a next-hop set to DISCARD are by default not used on DPC and MPC. But for MPC only you can add to the uRPF database the “discard” routes by using a knog called rpf-loose-mode-discard. This is a global knob that has only a meaning in Loose Mode. (No effect in Strict mode)

Option 3 (for DPC and MPC):

The third option concerns the action applied to packets failing uRPF check. By default those packets are silently discarded but on Junos you can also apply a specific firewall filter to manage those packets (ex. Modify Forwarding Class, rate-limiting, are anything else allowed by a Firewall Filter).

As we can see, there are a lot of combinations. I tried to establish a matrix of tests to cover the entire combinations of Modes, Options, and type of Cards.

2/ uRPF configuration

Modes configuration: This is a per-interface statement.
 
Strict mode configuration:


edit exclusive
  set interfaces aeXX.0 family inet rpf-check
or
  set interfaces xe-x/x/x.0 family inet rpf-check
commit


 

Loose mode configuration:


edit exclusive
  set interfaces aeXX.0 family inet rpf-check mode loose
or
  set interfaces xe-x/x/x.0 family inet rpf-check mode loose
commit



uRPF failure action: This is a per-interface statement.


edit exclusive
  set interfaces aeXX.0 family inet rpf-check fail-filter <MyFilter>
or
  set interfaces xe-x/x/x.0 family inet rpf-check fail-filter <MyFilter>
commit



Options configuration: Global configuration.

Take into account only Active Path (default):


edit exclusive
  set routing-options forwarding-table unicast-reverse-path active-paths
commit


 

Take into account Active Path and Backup paths (pushes backup paths to the FIB – actually create new ifl-list-nh):


edit exclusive
  set routing-options forwarding-table unicast-reverse-path feasible-paths
commit


 

For MPC only ; take into account also routes with a Discard NH; (here for inet routes):


edit exclusive
  set forwarding-options rpf-loose-mode-discard family inet
commit



3/ uRPF troubleshooting

Verify the uRPF configuration and uRPF counters:


sponge@bob> show interfaces ae40.0 extensive | match rpf
      Flags: Sendbcast-pkt-to-re, uRPF, uRPF-loose, Sample-input
      RPF Failures: Packets: 9950, Bytes: 11745652



A little bit more info at PFE level:


sponge@bob> show interfaces ae41.0 | match Index
  Logical interface ae41.0 (Index 332) (SNMP ifIndex 833)

sponge@bob> start shell pfe network fpc4

NPC4(bob vty)# show route rpf loose-discard-mode proto ip
  RPF loose-discard mode for IPv4: Enabled
  Platform support: Yes, Walk RTT: No

NPC4(bob vty)# show route rpf iff ifl-index 332 proto ip
  RPF mode: Loose
  Fail filter index: 0
  Bytes: 0
  Pkts: 0



To know which RPF interfaces are used to perform Reverse Lookup, let’s take one simple example:

uRPF-netdiagram 

This route has 2 paths, one active path through ae40.0 and a backup path through ae41.0.

 


sponge@bob> show route 1.0.0.0/30
inet.0: 905188 destinations, 1351252 routes (905178 active, 13 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
1.0.0.0/30         *[BGP/170] 17:29:36, localpref 0, from 192.168.37.1
                      AS path: I, validation-state: unverified
                    > to 81.253.193.9 via ae40.0
                    [BGP/170] 16:35:47, localpref 0, from 192.168.37.2
                      AS path: I, validation-state: unverified
                    > to 81.253.193.18 via ae41.0



Strict mode is configured on each interface and only active paths are used by uRPF.


sponge@bob> show route forwarding-table destination 1.0.0.1/32 extensive table default
Routing table: default.inet [Index 0]
Internet:

Destination:  1.0.0.0/30
  Route type: user
  Route reference: 0                   Route interface-index: 0
  Flags: sent to PFE
  Next-hop type: indirect              Index: 1048584  Reference: 200001
  Nexthop: 81.253.193.9
  Next-hop type: unicast               Index: 595      Reference: 16
  Next-hop interface: ae40.0
  RPF interface: ae40.0


 

You can see that only ae40.0 is allowed to receive datagrams with @IP Source equal to 1.0.0.1/32. Now we configure the feasible-path feature. The 2 paths (active and backup) should be allowed to receive traffic coming from the 1.0.0.1/32. Let’s check :


sponge@bob> show route forwarding-table destination 1.0.0.1/32 extensive table default

Routing table: default.inet [Index 0]
Internet:

Destination:  1.0.0.0/30
  Route type: user
  Route reference: 0                   Route interface-index: 0
  Flags: sent to PFE
  Next-hop type: indirect              Index: 1048584  Reference: 200001
  Nexthop: 81.253.193.9
  Next-hop type: unicast               Index: 595      Reference: 16
  Next-hop interface: ae40.0
  RPF interface: ae40.0
  RPF interface: ae41.0



Cool, now the backup interface is also allowed to receive traffic coming from 1.0.0.1 (Nice for multi-homing )

4/ uRPF IPv4 test results

The 2 next tabs sumarize the tests carried out on MPC and DPC. Hereafter the explanation of each column:

  • Active or Feasible : active-paths or feasible-paths feature
  • Mode : loose or strict 
  • @Src known in FIB :  @Src known in FIB via a valid NH, or a Dicard NH or a default route or unknown in FIB
  • Packet is coming from : the right interface (to reach the source) or by a backup interface (only for feasible)
  • Default route case : Default points either to a Discard NH or to the right interface (to reach the source) or another interface
  • In loose mode and for MPC only: the routes with a Discard NH is also included within the RPF database.
  • Expected Result: the result expected and described in Juniper technical documentation/KB
  • Observed Result: the real result observed during tests.    

MPC test results:

matrix-mpc

 

DPC test results:

matrix-dpc

David.

Partager cet article

Repost 0
Published by junosandme - dans Posts
commenter cet article

commentaires