RE: Blueprint: 6.03 Implement Unicast Reverse Path Forwarding

Andrew,

If you have access to a Linux server and a couple minutes to configure it, you might want to try out http://nfsel.sourceforge.net/ . another option is the 30 day trial of manageengine's netflow analyzer, which is really easy to setup.

Btw, what's with all the questions lately, you act like you have some big exam coming up :)

-ryan

-----Original Message-----
From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of Johnny B CCIE
Sent: Saturday, October 24, 2009 1:31 AM
To: Cisco certification
Subject: Re: Blueprint: 6.03 Implement Unicast Reverse Path Forwarding (uRPF) --> good test? Command placement?

Andrew,

You inspire me and I am sure others. For Netflow take a look at
getting a collector to help view the results, allow me to recommend
AdventNet or PRTG as both have some limited free editions that can at
least monitor 2 interfaces.

I need to look on PfR/OER. I have some labs for this and I think they
might be helpful for you. also have some material for EEM but I have
to admit it is not fresh in my mind. Naturally I would be glad to
continue our conversations. I do enjoy your attitude towards learning
this material.

Johnny

On Fri, Oct 23, 2009 at 3:28 PM, ALL From_NJ <all.from.nj_at_gmail.com> wrote:
> Good afternoon Johnny and team,
>
> Additoinal items I am going to try and test tonight, tomorrow and Sunday
> are:
>
> 2.80 Implement Performance Routing (PfR) and Cisco Optimized Edge Routing
> (OER)
> 10.03 Implement NetFlow
> 10.06 Implement Cisco IOS Embedded Event Manager (EEM)
>
> Any thoughts on doing so?
>
> I am going through the blueprint and either making sure I understand / know
> how-to, or trying to lab up. I also want to make sure I can find these
> topics on the doc cd ... not always an easy task either. ;-)
>
> Andrew
>
>
> On Fri, Oct 23, 2009 at 1:54 PM, Johnny B CCIE <jbccie_at_gmail.com> wrote:
>>
>> 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
>>
>> _______________________________________________________________________
>> 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 Sat Oct 24 2009 - 10:22:42 ART