From: ccie2be (ccie2be@nyc.rr.com)
Date: Mon Jun 28 2004 - 12:50:01 GMT-3
MessageHey Richard,
I used to trust my powers of deduction, but not anymore. Too many times, it
turned out that what I deduced ended up not working as I expected and then
biting me in the butt. Now, I don't have much of a butt anymore and lots of
gray hairs as well :-)
Apparently, my logic and that of the IOS developers don't always coincide.
Thanks for your help.
Tim
----- Original Message -----
From: Richard Dumoulin
To: ccie2be ; Group Study
Sent: Monday, June 28, 2004 11:26 AM
Subject: RE: Logging denied spoofed packets
"However, that doesn't really address the issue I'm trying to figure out"
--> I thought that by understanding how things work you would deduct the
solution. So if there are any errors in my undertsanding of RPF I would
appreciate the comments :)
If you don't know the spoofed ip addresses then just put a deny any with the
keyword log ?
--Richard
-----Original Message-----
From: ccie2be [mailto:ccie2be@nyc.rr.com]
Sent: lunes, 28 de junio de 2004 17:20
To: Richard Dumoulin; Group Study
Subject: Re: Logging denied spoofed packets
Thanks Richard for getting back to me. However, that doesn't really
address the issue I'm trying to figure out.
The key issue is how to LOG spoofed packets and, of course, deny them.
So, the question is what should the acl look like given the fact that I
don't know in advanced what source addresses are spoofed?
----- Original Message -----
From: Richard Dumoulin
To: ccie2be ; Group Study
Sent: Monday, June 28, 2004 10:57 AM
Subject: RE: Logging denied spoofed packets
With the acl mentioned below, only packets with source address not
present in the routing table or coming through the wrong interface will be
denied.
The RPF works like this:
If source present in the routing and coming from the right interface,
then pass
If source coming through the wrong interface then have a look at the
acl. If permitted by the acl, then pass. If not permitted then deny.
If source not present in the routing table, then check acl etc ...
This is how I think it works,
--Richard
-----Original Message-----
From: ccie2be [mailto:ccie2be@nyc.rr.com]
Sent: lunes, 28 de junio de 2004 16:21
To: Group Study
Subject: Logging denied spoofed packets
Hi guys,
When using the ip verify unicast reverse-path <acl> commands, I want to
deny only spoofed packet but also log the denied spoofed packets.
According to the documentation,
Enables Unicast RPF on the interface. Use the list option to identify an
access list. If the access list denies network access, spoofed packets are
dropped at the interface. If the access list permits network access, spoofed
packets are forwarded to the destination address. Forwarded packets are
counted in the interface statistics. If the access list includes the logging
option, information about the spoofed packets is logged to the log server.
Based on these requirements, what should the acl look like?
If I create an acl which denies all packets (ie. 0.0.0.0/32), does that
deny all packets or only spoofed packets?
TIA, Tim
_______________________________________________________________________
Please help support GroupStudy by purchasing your study materials from:
http://shop.groupstudy.com
Subscription information may be found at:
http://www.groupstudy.com/list/CCIELab.html
**********************************************************************
Any opinions expressed in the email are those of the individual and not
necessarily the company. This email and any files transmitted with it are
confidential and solely for the use of the intended recipient. If you are not
the intended recipient or the person responsible for delivering it to the
intended recipient, be advised that you have received this email in error and
that any dissemination, distribution, copying or use is strictly prohibited.
If you have received this email in error, or if you are concerned with
the content of this email please e-mail to: e-security.support@vanco.co.uk
The contents of an attachment to this e-mail may contain software
viruses which could damage your own computer system. While the sender has
taken every reasonable precaution to minimise this risk, we cannot accept
liability for any damage which you sustain as a result of software viruses.
You should carry out your own virus checks before opening any attachments to
this e-mail.
**********************************************************************
This archive was generated by hypermail 2.1.4 : Sat Jul 03 2004 - 19:40:51 GMT-3