Re: Blueprint: 6.03 Implement Unicast Reverse Path Forwarding

From: Johnny B CCIE <jbccie_at_gmail.com>
Date: Thu, 22 Oct 2009 22:39:26 -0400

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
Received on Thu Oct 22 2009 - 22:39:26 ART

This archive was generated by hypermail 2.2.0 : Sun Nov 01 2009 - 07:51:00 ART