From: deji500@hotmail.com
Date: Fri Apr 27 2007 - 05:23:21 ART
Hi Darby,
Thanks for your input.
Using a standard ACL, it works. Even using an extended ACL, it works. The
problem arises when I include an IP address in the destination field instead
of any. I am just trying to find out if it is an IOS issue (my routers are
running 12.3) or it is impossible to use an ACL with a source and
destination field set with the access-class command. I have workbooks from
two vendors but there are no labs like that.
Here is the ACL (changed it to a numbered ACL) with the log
*Mar 10 11:49:30.695: %SEC-6-IPACCESSLOGP: list 150 denied tcp
150.1.3.3(35021) -> 0.0.0.0(23), 1 packet
*Mar 10 11:49:32.938: %SEC-6-IPACCESSLOGP: list 150 denied tcp
150.1.3.3(52813) -> 0.0.0.0(23), 1 packet
*Mar 10 11:49:38.375: %SEC-6-IPACCESSLOGP: list 150 denied tcp
150.1.3.3(22178) -> 0.0.0.0(23), 1 packet
*Mar 10 11:49:48.279: %SYS-5-CONFIG_I: Configured from console by console
Rack1R1#sh ip access
Rack1R1#sh ip access-lists 150
Extended IP access list 150
10 permit tcp host 150.1.3.3 host 150.1.1.1 eq telnet log
20 permit ip host 150.1.3.3 host 150.1.1.1 log
30 deny ip any any log (3 matches)
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Darby Weaver
Sent: 27 April 2007 08:40
To: deji500@hotmail.com; ccielab@groupstudy.com
Subject: Re: Restrictive Access-Lists
Hmmm...
What does your show access-list output look like?
Is the access-list being interpretted by the router in
the order you are presenting it as listed below?
However, I usually interpret a standard ACL as a
numbered ACL like 1-99 for instance. Not necessarily
a named ACL which is standard.
I have heard a rumor that in the lab numbered lists
may be preferred over named access lists unless there
is no other way.
Of course, that may be a question for the proctor.
The reason being that some named ACLS may not work
properly with certain scripts used for grading.
Again a "rumor".
==================
Of course if you were to have created an ACL (the one
being matched) and then later edited it.
You may still be using the old one?
PER:
When you delete an access-list that is currently being
applied to an interface, all traffic that is to be
filtered through the specified access list will be
allowed until the access list is reinstated or a new
access-list is specified in the access-group command.
=========================================
Now if it were me, I do something like this:
access-list permit 23 permit host 150.1.3.3
line vty 0 4
transport input ssh telnet
transport output ssh telnet
In fact on my rack this works great. It's 3:30am in
the morning.
I think the problem is a matter of interpretation
(Definition of a standard ACL) and btw I think you'll
find you'll encounter similar problems on your SNMP
"standard" ACLs too.
=======================================
Little crazy troubleshooting tonight...
I actually had to fight a broadcast storm and it
caused a major uproar from route generator that I just
turned up - can you sat a demonstrated need for
storm-control.
It wiped out my eigrp and I could not even ping. Talk
about "broken arrow". My two routers were definately
overwhelmed.
My sh int were off the chart. And one of the two
routers was getting clobbered with EIGRP errors from
the neigh.
I had to debug ip packet to see what was going on.
CDP was not working, ICMP was not working, etc.
Funny since the 3550 could see the routers with CDP
but not the reverse. Of course the 3550 was not
overwhelmed.
Much less telnet or even my control plane traffic.
I created a monster with that new box.
--- deji500@hotmail.com wrote:
> Hi GS,
> I can not seem to use a restrictive access-list to
> restrict access to a router's vty lines. I want to
> be able to restrict access to only one interface on
> the router from selected interfaces on selected
> routers using either ssh OR TELNET. For example, I
> want to allow access on to R1's loopback interface
> from R3 and R6 but not any interface on R2,R4 or R5.
>
> Example using the loopback of just R3
> ip access-list extended TELNET
> permit ip host 150.1.3.3 host 150.1.1.1 log (does
> not match)
> permit tcp host 150.1.3.3 host 150.1.1.1 eq telnet
> log (does not match)
> permit tcp host 150.1.3.3 any log (this is
> matched)
>
> Is it the IOS on my routers (12.3)? oR the
> access-class command on the vty lines does not like
> restrictive ACLs? DocCD uses just a standard ACL or
> its not just possible.
>
> Thanks for your help
>
>
This archive was generated by hypermail 2.1.4 : Tue May 01 2007 - 08:28:38 ART