MSFC - access-class with extended ACL

[pdostal]

One of our engineers had the following issue on a Cisco Catalyst 6500 MSFC card.

He configured an extended access-list permitting SSH from a specific source host IP to one of the interfaces (VLAN) on the MSFC. He applied the ACL to the VTYs through an access-class.

For some reason, he couldn’t SSH to the MSFC. The ACL dropped the packets. When the access-list was changed from a specific destination to ‘any’, he could SSH to the MSFC.

When we turned on logging on the ACL, we noticed that the destination IP address on the SSH packets was for some reason changed to: 0.0.0.0. so we tried logging incoming traffic on the VLAN interface on the MSFC, but the destination address there was correct.

Anybody had the same issue?

Thanks,

Peter

[rjackson]

show us the acl. It sounds like he might have the wildcard backwards.

[pdostal]

There is a host entry in the ACL only, no wildcard.

[Richard Burts]

I have had a similar experience. I have tested with extended access lists for access class and found that in many instances it would require defining an address as 0.0.0.0 to make it work.

In a class that I used to teach we showed a number of uses for access lists and how behavior changed depending on how the list was applied. We would talk about how to control telnet access to the router and the difference between using an access list with access-group on an interface versus an access list with access-class on the vty ports. With access-list/access group you would have to be very specific about destination addresses and would need a permit for every address on the router as a destination (and the access list would have to examine every packet coming into the interface - whether it was destination of the router or not). With access-list/access-class it only examines packets which the router has determined are destined for the router. My rationalization was that at that point it did not matter what the destination address had been, it only mattered that the target of the telnet was the router, so maybe the destination address has been stripped by the time the logic evaluates the access-class.

HTH

Rick