Re: Blueprint: 6.03 Implement Unicast Reverse Path Forwarding

Think about it for a moment and consider if you are being asked to
block spoofing from a given interface. Now consider if you are also
required to be able to ping all interfaces even your own interfaces.
Most of us think towards Frame Relay. And we lose points after we
complete the one liner. We lose the points in Frame, in Security, and
maybe even in general for overall connectivity. Triple loser. Is this
an example you are looking for? In production, think of your borders.

On Thu, Oct 22, 2009 at 10:56 PM, ALL From_NJ <all.from.nj_at_gmail.com> wrote:
> Many thanks for the tips. Yep, that is a pretty neat test too.
>
> The uRPF feature keeps this from being a problem ... nice feature for
> keeping spoofed (or mis-configured) addresses from causing problems. I would
> think this could be an administrative nightmare depending on where you
> enabled it.
>
> Thanks.
>
> Any other thoughts on placement or ways to test / learn?
>
>
> On Thu, Oct 22, 2009 at 10:43 PM, Johnny B CCIE <jbccie_at_gmail.com> wrote:
>>
>> Sorry, I answered too quickly. You are doing the example fine as it
>> is. If you can ping from the source or "spoofed" address then the
>> access-list is working as intended and if you remove it and it is
>> blocking the "spoofed" local interface then it is also working as
>> intended. To test further create a loop on the farside with a local
>> side address and then try to see what happens, either with or without
>> the acl you should see the results. You may want to debug ip packet to
>> watch the fun.
>>
>> On Thu, Oct 22, 2009 at 10:39 PM, Johnny B CCIE <jbccie_at_gmail.com> wrote:
>> > Don't filter yourself. Use the ? after the command and you will see
>> > you have options.
>> >
>> > On Thu, Oct 22, 2009 at 9:23 PM, ALL From_NJ <all.from.nj_at_gmail.com>
>> > wrote:
>> >> Team,
>> >>
>> >> Can I get a sanity check from you all? Pretty please with sugar? ;-)
>> >>
>> >> My test:
>> >>
>> >> R1 connected to SW1
>> >> R2 connected to SW1
>> >>
>> >> Can ping no problem, baseline looks good, no worries.
>> >>
>> >> Add the command on R2: ip ver unicast reverse-path
>> >>
>> >> Then I type the command: "show ip traffic | in drop"
>> >> 0 no route, 10 unicast RPF, 0 forced drop
>> >>
>> >> For every ping from R1, I see this RPF counter increasing, so I know
>> >> that
>> >> RPF is dropping packets after I add the command.
>> >>
>> >> When I add an access list permitting the 'spoofed source' then the RPF
>> >> counter does not increase, which is also how I test if I have this
>> >> configured right.
>> >>
>> >> Any additional thoughts on how to test this feature? Seems fairly easy
>> >> to
>> >> test, only 2 routers are needed w/ crossover or a switch in the middle.
>> >>
>> >> Question about the placement of this command: should I put this
>> >> anywhere in
>> >> my network that I think I might get spoofed addresses? As I understand
>> >> it,
>> >> as long as I have a route (default or specific) that the traffic will
>> >> pass
>> >> ok.
>> >>
>> >> If I do not have a route, I can either add a route or configure and
>> >> access
>> >> list and permit this seemingly 'spoofed' address.
>> >>
>> >> Appreciate your thoughts team!
>> >>
>> >> --
>> >> Andrew Lee Lissitz
>> >> all.from.nj_at_gmail.com
>> >>
>> >>
>> >> Blogs and organic groups at http://www.ccie.net
>> >>
>> >> _______________________________________________________________________
>> >> Subscription information may be found at:
>> >> http://www.groupstudy.com/list/CCIELab.html
>>
>>
>> Blogs and organic groups at http://www.ccie.net
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
>>
>>
>>
>>
>>
>>
>>
>
>
>
> --
> Andrew Lee Lissitz
> all.from.nj_at_gmail.com

Blogs and organic groups at http://www.ccie.net
Received on Fri Oct 23 2009 - 00:56:51 ART