RE: possible Bug on 3550, ip access-group ??? UPDATE UPDATE -

From: Adam Crisp (adam.crisp@totalise.co.uk)
Date: Thu Nov 07 2002 - 14:14:05 GMT-3


Hi,

I have received a lot of emails that say "What happens if you apply the
access-lists to the vlan interface rather that the physical port"

If the access-list is applied to the Vlan interface, rather that the
pbysical interface, this denyies access to the "vlan management interface"
but not other ports on the switch, which is what I was trying to acheive,

I have "interface vlan 254" defined on the 3550, with the IP address
192.168.200.250
There is another PC on VLAN 254, with ip address 192.168.200.251
thus:
!
!
interface Vlan254
 ip address 192.168.200.250 255.255.255.0
 ip access-group 1 in
end
!

the access-group is NOT applied to port 0/6 (where the PC 192.168.200.2 is
plugged in)

If I ping from the pc then:
"
C:\Documents and Settings\Adam>ping 192.168.200.251

Pinging 192.168.200.251 with 32 bytes of data:

Reply from 192.168.200.251: bytes=32 time<1ms TTL=255
Reply from 192.168.200.251: bytes=32 time<1ms TTL=255
Reply from 192.168.200.251: bytes=32 time<1ms TTL=255
Reply from 192.168.200.251: bytes=32 time<1ms TTL=255

Ping statistics for 192.168.200.251:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

C:\Documents and Settings\Adam>ping 192.168.200.250

Pinging 192.168.200.250 with 32 bytes of data:

Reply from 192.168.200.250: Destination net unreachable.
Reply from 192.168.200.250: Destination net unreachable.
Reply from 192.168.200.250: Destination net unreachable.
Reply from 192.168.200.250: Destination net unreachable.

Ping statistics for 192.168.200.250:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

C:\Documents and Settings\Adam>
"

-----Original Message-----
From: Todd.Reagan@nokia.com [mailto:Todd.Reagan@nokia.com]
Sent: 07 November 2002 16:42
To: adam.crisp@totalise.co.uk
Subject: RE: possible Bug on 3550, ip access-group ??? UPDATE UPDATE -
I'VE FOUND THE WORKAROUND!!!

What happens if you use a vlan interface rather than a port on the
switch to apply the access-list?

Todd

-----Original Message-----
From: ext Adam Crisp [mailto:adam.crisp@totalise.co.uk]
Sent: 07 November, 2002 09:50
To: Ccielab
Subject: FW: possible Bug on 3550, ip access-group ??? UPDATE UPDATE -
I'VE FOUND THE WORKAROUND!!!

Group,
I am really sorry about by sending repetative emails on the trott - BUT
I have found a workaround to the problem.

I really do think this is a bug now.

According to the documentation:
"You can only apply one IP ACL and one MAC ACL per interface."

Ah ha I thought!
At the moment the PC 192.168.200.2 is plugged into fast 0/6 - but the
"ip access-group 1" on fast 0/2 is also blocking on 0/6

so, if you can only apply ONE IP ACL per interface then what happens if
I apply a NEW "Permit any" access-list to fa0/6

The config now look like this:
access-list 1 deny 192.168.200.2
access-list 1 permit any
access-list 2 permit any
!
interface FastEthernet0/2
 switchport access vlan 254
 switchport mode access
 no ip address
 ip access-group 1 in
 spanning-tree portfast
!
interface FastEthernet0/6
 switchport access vlan 254
 switchport mode access
 no ip address
 ip access-group 2 in
 spanning-tree portfast
!

Guess what - it works

Any comments please, I would hate to come accross this in the LAB!!!!

cheers

Adam

-----Original Message-----
From: Adam Crisp [mailto:adam.crisp@totalise.co.uk]
Sent: 07 November 2002 15:42
To: Ccielab
Subject: FW: possible Bug on 3550, ip access-group ??? UPDATE UPDATE
Importance: High

Hi
I notices that Cisco have, as of 24th Oct released a new IOS
version: 12.1.11.EA1a

I instal the this release, but the behavour is the same:
!
show ip interface
<...
FastEthernet0/1 is up, line protocol is up
  Inbound access list is not set
FastEthernet0/2 is administratively down, line protocol is down
  Inbound access list is 1
FastEthernet0/3 is up, line protocol is up
  Inbound access list is not set
FastEthernet0/4 is up, line protocol is up
  Inbound access list is not set
FastEthernet0/5 is down, line protocol is down
  Inbound access list is not set
FastEthernet0/6 is up, line protocol is up
  Inbound access list is not set
..>

Look I even shutdown int fast 0/2, the PC is in 0/6 - and the access
list still applies.

Assuming that this IS NOT a bug can anybody please explain how to
prevent access to the switch on selective ports. - using IP L3
infomation - ie ip address.

HELP

Adam

-----Original Message-----
From: Adam Crisp [mailto:adam.crisp@totalise.co.uk]
Sent: 07 November 2002 15:24
To: Ccielab
Subject: possible Bug on 3550, ip access-group ???

Hi,

I think I've found a bug on the 3550, but can't find any reference to it
on CCO.

Vlan 254 on my switch supports IP hosts on the subnet 192.168.200.0 /24
I am trying to prevent access on the switch, to a PC with IP address
192.168.200.2 This PC is plugged int Fast 0/2. According to the
documentation, you can use an ip access-lists to do the above
requirement.

hence:

!
access-list 1 deny 192.168.200.2
access-list 1 permit any
!
interface FastEthernet 0/2
 switchport access vlan 254
 switchport mode access
 no ip address
 ip access-group 1 in
 spanning-tree portfast
!

This works ok.

The problem is, is that the above configuration, not only blocks access
to port fast0/2, - but to any other port on the switch

If I move my PC from 0/2 to 0/6 and 0/6 is configured like:
!
interface FastEthernet0/6
 switchport access vlan 254
 switchport mode access
 no ip address
 spanning-tree portfast
!

then the PC still cannot access the switch. If I remove the "ip
access-group 1 in" command from fast 0/2 - everything is ok.

I am using the following ios release
"Cisco Internetwork Operating System Software
IOS (tm) C3550 Software (C3550-I5Q3L2-M), Version 12.1(11)EA1, "

This is the L3 feature set.

Anybody come across this?

Adam



This archive was generated by hypermail 2.1.4 : Tue Dec 03 2002 - 07:22:54 GMT-3