I can't see why you should use an extended acl to do that. "transport input telnet ssh" should allow access only through those two protocols, so filtering that through an ACL is a bit redundant in my opinion.
You should be able to use a standard acl like: ip access-list standard vty permit 10.0.0.0 0.0.0.255 permit 10.1.0.0 0.0.0.255 deny any log ! line vty 0 4 transport input telnet ssh access-class vty in ! That should do it. Best regards, Allan Eising On Fri, Sep 5, 2008 at 12:27 PM, Jay Hennigan <[EMAIL PROTECTED]> wrote: > Ang Kah Yik wrote: >> >> I think more specifically, he wanted to be able to permit a particular >> group >> of users to use telnet and another to use ssh. >> While I'm not sure why it'd be good to use telnet when ssh is available, I >> suppose it would be possible to apply an ACL on the VTYs to deny access to >> telnet/ssh as required. > > I haven't tried it, but it might be possible to use an extended ACL for > this. > > ip access-list extended vty-list > permit tcp 1.1.1.0 0.0.0.255 any eq 22 > permit tcp 2.2.2.0 0.0.0.255 any eq 23 > > line vty 0 4 > transport input telnet ssh > access-class vty-list in > > -- > Jay Hennigan - CCIE #7880 - Network Engineering - [EMAIL PROTECTED] > Impulse Internet Service - http://www.impulse.net/ > Your local telephone and internet company - 805 884-6323 - WB6RDV > _______________________________________________ > cisco-nsp mailing list cisco-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > _______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/