I have a pair of 1605 routers running IP/Firewall side by side between 2 LAN
environments:
LAN1 -------------------------
| |
|------| |------|
|1605A | |1605B |
|------| |------|
| |
LAN2 -------------------------
The Interfaces on LAN1 have Access Control Lists to allow specified traffic
through such as SMTP mail and deny everything else.
The Interfaces on LAN2 have a permit all access list used by CBAC to punch
holes in the LAN 1 ACL.
I am running HSRP on both LANs with 1605A as the main router and 1605B as
the standby. However, the routers cannot see the HSRP "hello"s on LAN1 when
the ACLs are in place and thus they both set the HSRP address as local.
Does anybody know how to configure the extended IP ACL to allow hsrp traffic
to pass through?
Many thanks,
Andy
-===============-
Andrew Stentiford
ICL, Electronic Business Services.
UK
an...@icl.net
Permit the multicast hellos and the HSRP protocol:
access-list 101 permit ip any 224.0.0.2
access-list 101 permit udp any any eq 1985
(You can also use the sending router's address as the source address - it
will be the physical interface address, not the standby address)
Wade
---------------------------------------------------------------------------
Wade Williams "Put your message in a modem, and throw
Systems Engineer, CCIE #3373 it in the cyber sea."
Cisco Systems, Inc. - N. Peart
Brentwood, TN
615-221-2918
wwil...@cisco.com
---------------------------------------------------------------------------
access-list 100 permit udp any 224.0.0.2 0.0.0.0 eq 1985
Kevin
// Does anybody know how to configure the extended IP ACL to allow hsrp traffic
// to pass through?
> Synopsis: Does anyone know how to allow HSRP "hello" traffic to pass through
> an IP extended ACL.
You have got an answer already from the list, AFAIR.
Just one more advice for future:
Always try to finish your access-lists with line -
access-list xxx deny ip any any log
In this case, all "fallen-through" trafiic will not be silently
discarded, but leave a trace in syslog, useful for analysis and
troubleshooting.
Disclaimer: There are situations, when presence of such clause can
cause some problems (like Syslog server DoS), but I found these
situations extremely rare, so I can consider them as exceptions from
good and useful rule ;)
--------------------------------------
Basil (Vasily) Dolmatov CCNA,CCDA
East Connection ISP, Moscow, Russia. (http://www.east.ru)
> > Just one more advice for future:
> >
> > Always try to finish your access-lists with line -
> > access-list xxx deny ip any any log
> >
> > In this case, all "fallen-through" traffic will not be silently
> > discarded, but leave a trace in syslog, useful for analysis and
> > troubleshooting.
> >
> > Disclaimer: There are situations, when presence of such clause can
> > cause some problems (like Syslog server DoS), but I found these
> > situations extremely rare, so I can consider them as exceptions from
> > good and useful rule ;)
> >
>
> I disagree with adding the deny any log to access lists unless 1) you are
> actually going to take the time to review the logged access list failures; 2)
> are trying to troubleshoot an access list problem or security breach.
1) Abscence of analysis of security breaking attempts means absence of
computer security service at enterprise or its total inability to work.
2) Absence of proper scheme of rotating and storing logged and audited
information means absence network administration or its total inability
to work.
>
> Add the logging indiscriminately without a good log rotation scheme can cause
> log files to grow to immense size with introduces other fun problems.
>
Definitely, if you stop log rotating you will be in trouble, but on *NIX
syslog servers this action should be done _explicitly_. Cannot say anything about
NT-based syslog servers, though, maybe it is the issue for it, but filters
installed to defend NT-based network need _daily_ and _thorough_ monitoring
if you want this network to remain alive for long.. ;)