Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

VTY Access-class vrf-also question

hi everyone,

Can someone explain to me the usage of VRF-Also? 

I have a pair of CAT6880-X. I setup SSH and want to lock down access to management to only my management subnet. Since I have a lot of SVI, i don't want people on those VLAN access the management of the switch. 

I'm using the Management 0 port. 

Without putting any access-list to vty, any IP can SSH into the switch. 

Originally, I had the below config


ip access-list extended management-acl
 permit tcp any eq 22
 deny   tcp any any eq 22
 permit ip any any


line vty 0 4
 access-class management-acl in
 transport input ssh
line vty 5 15
 access-class management-acl in
 transport input ssh



When i tried to SSH in, i can see that the access-list got hit, but I couldn't SSH into the switch, from

Extended IP access list management-acl
    10 permit tcp any eq 22 (79 matches)
    20 deny tcp any any eq 22 (6 matches)
    30 permit ip any any


Then I saw a Cisco Document regarding vrf-also. so I applied it and it finally worked

line vty 0 4
 access-class management-acl in vrf-also
 transport input ssh
line vty 5 15
 access-class management-acl in vrf-also
 transport input ssh


My question is: I'm not using VRF. I'm basically using the Management port. I do not understand the purpose of vrf-also for my case, and I couldn't understand why it didn't work without "vrf-also".

Could you help me explain it?


  • LAN Switching and Routing
VIP Super Bronze

Hi,Management VRF for most


Management VRF for most Cisco devices is a new feature that was introduced a few years ago.

The reason for that is that most customers for security reasons don't want to see the management IP address in their global routing table.  And so therefore Cisco and other vendors came up with idea of VRF for the management interface. This way, the routing tables are not mixed (management VRF has its own routing table).




New Member

hi Reza, thank you for

hi Reza, 

thank you for answering my question. But that wasn't what i asked for. I know what is VRF. We are using VRF in our environment.

My question is: CAT6880-X management port is a seperate port (not like Nexus where the management port is in a management VRF). That's why I'm confused why do I need to use vrf-also when I apply the access-list to VTY.

According to document on CAT6880-X, or SUP2T in general, the management port has its own CPU and Memory, so there is no Management VRF.

New Member



Thanks for this - was driving me up the bend. Doesn't make sense why I'd need it (I do - same scenario as you, only I'm managing via explicitly-defined VRF) given the whole point of the "line vty" section is to apply to remote access of the box, regardless of interface it's via; otherwise surely I'd apply my ACL to the applicable interfaces themselves?

Anyway, aside from being "Cisco'd" again myself with this "feature", the reason it's applicable to your scenario is that you are actually using a VRF, even if you haven't defined it. The Management interface (Gi0) is implicitly mapped to a built-in VRF called "Mgmt-intf". IOS has a logic that won't allow you to map any other interface into VRF "Mgmt-intf" - this is the mechanism Cisco treat this as an Out of Band Management-only interface; because it has its own VRF, and IOS won't let you add/change that VRF. So, even though you didn't define it, access into the box from Gi0 (Mgmt interface) will appear to the "line vty" section to be coming from another VRF, hence the requirement for the "vrf-also" keyword at the end of the "access-class" statement.

Yet another gotcha to tattoo to some spare arm space :).