VTY Access-class vrf-also question

[HIeu Phan]

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 172.16.20.0 0.0.0.255 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 172.16.20.10

Extended IP access list management-acl
    10 permit tcp 172.16.20.0 0.0.0.255 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?

[Reza Sharifi]

Hi,

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).

HTH

[HIeu Phan]

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.

[aroshak]

Hi,

The "vrf-also" at the end of access-class will allow you to telnet/ssh in or out sourcing the VRF configured on the router. In other words if you did not have vrf-also at the end of the statement you can only telnet/ssh to the stuff on the global routing table. vrf-also allows you to ssh/telnet to  hosts in vrf such as "#telnet 172.22.251.20 /vrf YYY"

hope this helps.

Cheers

[spoofneted]

Hieu,

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 :).

[aamisomnath]

If we want to negate the command to stop SSH under VRF (below command), will it disable it for the global routing table also or only access under the VRF will be impacted? Please suggest.

no access-class management-acl in vrf-also