Re: Blueprint: 6.03 Implement Unicast Reverse Path Forwarding

ALL From_NJ

i love these quick and short 2 router tests...sometimes short and sweet
really opens your eyes to what is going on, instead of always the BIG
PICTURE....

thanks..
garry..

On Fri, Oct 23, 2009 at 4:23 AM, 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
>
>
>
>
>
>
>
>

-- 
Garry L. Baker
"There is no 'patch' for stupidity." - www.sqlsecurity.com
Blogs and organic groups at http://www.ccie.net