Task 6.1 URPF

Which part of the task wording suggests loose mode uRPF instead of strict mode uRPF?





  • I guess it's in the last sentence, where it says "...without a verifiable source IP..." - Verifiable is the key bit. It's not saying that it must come from the right interface, just that there must be a route for that IP.

    That's my take on it anyway

  • I agree,,,I have used strict mode as I've reasoned you need too verify source packets coming in the interface from BB2....


    if someone can shed light on this...please do...? SG suggests "loose" mode?


    "ip verify unicast source reachable-via rx"



    "ip verify unicast source reachable-via any.....?


  • Hi JJ,

      So the task says:"without a verifiable source IP address", which means you need to use loose mode, you don't care which interface the route points to as long as there is a route.

    Good luck with your studies!

  • I screwed this up too.  I answered it way too quickly -- and I concentrated on the topic at hand (Avoiding spoofed IP addresses -- as a practical matter they can still spoof your internal network addresses in "loose" mode) -- and almost every implementation of this command in commercial ISP networks is rx-only.

    But... it did say without a verfiable IP address. (which is loose mode).

    It did remain silent about a verifable return path (with is rx-only).

    (technically, RX-only does verify the IP address, it just also verifies the interface it came in on is the one to return the traffic on, making it not the best answer I suppose



    When administrators use Unicast RPF in strict mode, the packet must be
    received on the interface that the router would use to forward the return
    packet. Unicast RPF configured in strict mode may drop legitimate traffic
    that is received on an interface that was not the router's choice for sending
    return traffic. Dropping this legitimate traffic could occur when asymmetric
    routing paths are present in the network.

    When administrators use Unicast RPF in loose mode, the source address must
    appear in the routing table [not a default route]

  • I really have a hard time agreeing with the logic of using loose mode. The task specifically says "our security team has expressed concerns about the possibility of traffic sent from spoofed IP addresses being received inbound"

    That traffic could be a spoofed source of the victim host from any where in the world (smurf attack) or it could be a spoofed source from my internal network. My assumption was to address the later, which loose mode would not. Since my router has routes for my internal networks, it would still allow in traffic which has a source address that is internal to my network to come in that interface. Only strict mode would prevent that.

    I really don't think loose mode makes since based on the first bullet point of the task.

  • Hi, 

    Loose mode also protects the network from spoofing type of attack by allowing the router to check FIB table whether or not the entry exists for the particular source. If the source exists in the FIB table, it does forward the traffic. If not, it simply drop the traffic because it could be spoofed one.

    The major difference between Strict mode & Loose mode is the interface identification. In strict mode, it has to match the incoming & outgoing interface & it should match as well but in the case of loose mode, it does only check for the entry in the FIB table regardless of what was the incoming & outgoing interfaces.

    Hope this helps 

  • Hi Mikem


    I also configured this as strict but in a verification pass I noticed lack of connectivity from R3.  When I pinged from R3 it failed and the reason is becuase of how OSPF does its path selection and the strict uRPF check.


    R3 will have two equal cost paths to as it is being advertised from R1 and R2.  CEF will perform load balancing based on the source and destination pair.

    When I was pinging from R3 it just so happened that R3 selected the R3 to R1 serial link as the path and therefore the source of the ping. This meant the packets would come in via the BVI interface on R2.  R2 would then drop them for failing the RPF check.  The reason they fail RFP is because R2's path to the R1-R3 link is via its R3-R2 serial link, not the BVI.  This will always be the case becuase the route coming in the BVI would be an OSPF summary generated by R1 and R2 will not use any OSPF summaries received on a non backbone interface whilst it has an active adjacency in Area 0.  Also the LSA it recieves on the R3-R2 Serial link would be an Intra Area route which would always be preferred over an Inter-Area route.


    You can verify this by enabled "debug ip cef drop' and change the mode from RX to ANY.


    So whilst it doesn't say which mode to use by virtue of the fact that we must have full reachability then loose mode must be configured.


    EDIT: I think the thing to learn from this task is if it doesn't specifically say or hint that it should be strict then configure loose.  The logic being you are less likely to cause reachability issues that way and going for the real world "best" option is not the best option for the lab.



Sign In or Register to comment.