Re: Blueprint: 6.03 Implement Unicast Reverse Path Forwarding

What other things would you like to test?

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 - 13:54:25 ART