[61072] in North American Network Operators' Group
Re: Cisco filter question
daemon@ATHENA.MIT.EDU (Stephen J. Wilcox)
Fri Aug 22 13:02:15 2003
Date: Fri, 22 Aug 2003 17:59:48 +0100 (BST)
From: "Stephen J. Wilcox" <steve@telecomplete.co.uk>
To: Jack Bates <jbates@brightok.net>
Cc: Scott McGrath <mcgrath@fas.harvard.edu>,
"Geo." <georger@getinfo.net>, <nanog@merit.edu>
In-Reply-To: <3F464B13.20803@brightok.net>
Errors-To: owner-nanog-outgoing@merit.edu
point a route to null0 and set the next hop to be down that route
On Fri, 22 Aug 2003, Jack Bates wrote:
>
> Scott McGrath wrote:
>
> >
> > Geo,
> >
> > Look at your set interface Null0 command the rest is correct
> > you want to set the next hop to be Null0. How to do this is left as an
> > exercise for the reader.
> >
>
> Interface Null0 works fine. Here's a quick check.
>
> Inbound (from peers) policy matches
> route-map nachi-worm, permit, sequence 10
> Match clauses:
> ip address (access-lists): 199
> length 92 92
> Set clauses:
> interface Null0
> Policy routing matches: 10921 packets, 1048416 bytes
>
> Outbound (to internal network) accesslist matches
> Extended IP access list 181
> deny tcp any any eq 135 (1994 matches)
> permit icmp any any echo (757 matches)
> permit icmp any any echo-reply (381 matches)
> permit ip any any (381370 matches)
>
> I cleared 181 first, then cleared route-map counters. I then checked
> route-map counters first before checking access-list counters. This
> means the access-list has more time to accrue maches yet it is
> considerably smaller. The checks were a matter of seconds. I'd say the
> policy is working. The echo/echo-reply could easily be everyday pings
> which are up abit due to various networks having performance issues.
>
> IOS Versioning can sometimes have issues. There's also the question of
> if the packet came in the inbound interface that had the policy applied.
>
> -Jack
>
>
