Link to home
Start Free TrialLog in
Avatar of rbnu
rbnu

asked on

ACL problem in Catalyst 3550 switch

Hello All,

I have configured RIP2 in catalyst 3550 swich with the following commands

router rip
 version 2
 network 172.16.0.0

I created the following acl and applied to the interfaces

access-list 111  deny udp any eq 137 any eq 137
access-list 111  permit udp any any
access-list 111 permit ip any any

But when this acl is activated the rip stops working. No updation about other switches and routes takes place in this switch. I tried giving

access-list 111 permit udp any eq 520 any eq 520

also. But this also didn't help.

When I applied the same acl to on Cisco 2621 router, it is working perfectly.  Inference is that if I apply an acl with even simple statements like

access-list 111  permit udp any any
access-list 111 permit ip any any

then als this rip updation does not happens. But other switches are able to get the routing information of this switch without problems.

What could be wrong ?

Thanks and regards,

Binu R.

Avatar of Don Johnston
Don Johnston
Flag of United States of America image

Just so we're starting on the same page...

Is this a 3550 SMI or EMI?

-dj
I just applied your original ACL 111 to a 3550-EMI configured for RIP version 2. Still getting updates and working fine.

Can you post your config? Maybe there's something else that's causing this behavior.

-Don
Avatar of rbnu
rbnu

ASKER

Thank you very much for the response. Our switch is SMI. As I told, I have applied the same configuration in Cisco-2621 router and is working fine. I am giving the current configuration for your reference.

!
version 12.1
service timestamps debug uptime
service timestamps log datetime
service password-encryption
service sequence-numbers
!
hostname RoomNo2-3550-24
!
clock timezone GMT 5 30
ip subnet-zero
ip routing
!
!
spanning-tree mode pvst
spanning-tree extend system-id
!
!
interface FastEthernet0/1
 no ip address
 ip access-group 109 in
!
interface FastEthernet0/2
 no ip address
 ip access-group 109 in
!
interface FastEthernet0/3
 no ip address
 ip access-group 109 in
!
interface FastEthernet0/4
 no ip address
 ip access-group 110 in
!
interface FastEthernet0/5
 no ip address
 ip access-group 109 in
!
interface FastEthernet0/6
 no ip address
 ip access-group 109 in
!
interface FastEthernet0/7
 no ip address
 ip access-group 109 in
!
interface FastEthernet0/8
 no ip address
 ip access-group 110 in
!
interface FastEthernet0/9
 no ip address
 ip access-group 109 in
!
interface FastEthernet0/10
 no ip address
 ip access-group 109 in
!
interface FastEthernet0/11
 no ip address
 ip access-group 110 in
!
interface FastEthernet0/12
 no ip address
 ip access-group 110 in
!
interface FastEthernet0/13
 no ip address
 ip access-group 109 in
!
interface FastEthernet0/14
 no ip address
 ip access-group 110 in
!
interface FastEthernet0/15
 no ip address
 ip access-group 111 in
!
interface FastEthernet0/16
 no ip address
 ip access-group 111 in
!
interface FastEthernet0/17
 no ip address
 ip access-group 110 in
!
interface FastEthernet0/18
 no ip address
 ip access-group 111 in
!
interface FastEthernet0/19
 no ip address
 ip access-group 110 in
!
interface FastEthernet0/20
 no ip address
 ip access-group 110 in
!
interface FastEthernet0/21
 no ip address
 ip access-group 110 in
!
interface FastEthernet0/22
 no ip address
 ip access-group 110 in
!
interface FastEthernet0/23
 no ip address
!
interface FastEthernet0/24
 no ip address
!
interface GigabitEthernet0/1
 no ip address
 ip access-group 111 in
 no cdp enable
!
interface GigabitEthernet0/2
 no ip address
 ip access-group 111 in
!
interface Vlan1
 ip address 172.16.128.2 255.255.255.0
!
interface Vlan401
ip address 172.16.138.126 255.255.255.128
!
interface Vlan402
ip address 172.16.138.254 255.255.255.128
!
router rip
 version 2
 network 172.16.0.0
 neighbor 172.16.128.254
!
ip classless
ip route 0.0.0.0 0.0.0.0 172.16.128.254
ip http server
!
!
logging facility local6
logging 172.16.10.249
access-list 109 deny   udp any any eq 135
access-list 109 deny   udp any any eq netbios-ns
access-list 109 deny   udp any any eq netbios-dgm
access-list 109 deny   udp any any eq netbios-ss
access-list 109 deny   udp any any eq 4444
access-list 109 deny   udp any any eq 34012
access-list 109 deny   udp any eq 1037 any
access-list 109 deny   udp any any eq 2301
access-list 109 permit ip any any
access-list 110 deny   udp any any eq 135
access-list 110 deny   udp any any eq 4444
access-list 110 deny   udp any any eq 34012
access-list 110 deny   udp any eq 1037 any
access-list 110 deny   udp any any eq 2301
access-list 110 permit ip any any
access-list 111 permit udp any any eq rip
access-list 111 permit ip any any
access-list 113 permit tcp any any eq domain
access-list 113 permit tcp any any eq smtp
access-list 113 permit tcp any any eq www
access-list 113 permit tcp host 203.197.150.87 any
access-list 113 permit icmp host 203.197.150.87 any
access-list 113 permit icmp any host 203.197.150.87
!
line con 0
line vty 0 4
 login
line vty 5 15
 login
!
end


Thanks and regards,

Binu R.
I think you want to apply your access-group comands to the vlan interfaces.  Think about it, if you put an access-list on an interface that doesn't have an ip address how is the device going to know what to do?  If you take the groups off of the physical interfaces and put them on the vlan interfaces I think you will be in good shape.
ASKER CERTIFIED SOLUTION
Avatar of Don Johnston
Don Johnston
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Yes, there is support for basic IP unicast routing via Static and RIPv1/v2 using the SMI. The EMI provides advanced IP unicast and multicast routing. These advanced routing protocols are Open Shortest Path Routing Protocol (OSPF), Interior Gateway Routing Protocol (IGRP), Enhanced Interior Gateway Routing Protocol (EIGRP), BGP version 4 (BGPv4), Protocol Independent Multicast (PIM), and PBR.
I think Stealth188 is right. You need to apply the access-group commands to the VLAN interfaces, not the physical interfaces.
Avatar of rbnu

ASKER


Thanks all for the response. I have been using access lists in physical interfaces for long time and was giving exact results as expected. Even if I write the same ACL in our CISCO 2621 router and apply to the physical interfaces, again, it is able to get RIP updates.

In Catalyst 3550, if I write acl, upd traffic to port 137/138 are shown properly if I enable upd debugging. But port 520 traffic are not at all seen, even when I write a two line acl like

access-list 111 permit udp any any
access-list 111 permit ip any any

Another point is, if  I write

access-list 111 deny udp any any eq 137

the udp traffic to port 137 are suppressed also. (With the ACL applied to the physical interfaces.) So I doubt  it cannot be a problem with applying the acl to the physical interface.

Any other clue ?

Thanks and regards,

Binu R.
If you remove the access-group from all the physical interfaces do you receive the updates?
Avatar of rbnu

ASKER

Yes Defenitely. I am getting the updates. Once I apply an ACL even with a single line upd permit, or ip permit, the updates stops working !!

Rds,

Binu R.
There used to be a nice clear difference between a switch PORT and a layer 3 router INTERFACE (be it physical or a logical VLAN). When IOS was put on to switches this was blurred somewhat.


ACLs should only be placed on Interfaces and not ports (trust us!).
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial