From: Darby Weaver (darbyweaver@yahoo.com)
Date: Fri Apr 27 2007 - 05:41:41 ART
Might be a feature issue - all of my routers have 12.4
code installed at the moment on my primary rack.
My other routers are running 12.2 code
It looks like the acl is having an order of operations
issue by way of the way it is interpretting the rules
to me.
Anyone else care to comment?
Have you tried to delete the ACL, reload the router,
and recreate the ACL and then re-apply it to the
interface - exactly in this order?
I know you probably have already. But I'm thinking of
a scenario where we create a rule (or worse don't) and
apply the access-class command and THEN create the
ACL.
Now if this were the case I might expect to see what
you are seeing for results.
Otherwise you may have found an "intereesting issue or
bug" to keep you up at night.
:)
Let me know. Sounds interesting.
--- deji500@hotmail.com wrote:
> 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