Re: Blueprint: 6.03 Implement Unicast Reverse Path Forwarding

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