cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
43789
Views
48
Helpful
6
Replies

VTY Access-class vrf-also question

HIeu Phan
Level 1
Level 1

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?

 

6 Replies 6

Reza Sharifi
Hall of Fame
Hall of Fame

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

 

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.

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
Level 1
Level 1

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
Level 1
Level 1

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

Certainly! It seems like you've encountered a situation where using the "vrf-also" option in your access-class configuration made SSH access work as intended on your Cisco CAT6880-X switch. Let me explain the purpose of "vrf-also" and why it made a difference in your case.

In Cisco devices, "vrf-also" is used to apply an access control list (ACL) not only to the global routing table (the default VRF) but also to any virtual routing and forwarding (VRF) instances that may exist on the device. Even if you're not explicitly using VRFs, your device still operates within the default VRF, and that's why the "vrf-also" option can affect the behavior of your ACL.

Here's what likely happened in your scenario:

  1. Without "vrf-also": When you applied your access-class without the "vrf-also" option, it was only applied to the default VRF. If there were no VRFs configured on your device, this should have been sufficient. However, it seems like the default VRF alone wasn't enough to restrict SSH access as you intended.

  2. With "vrf-also": By adding "vrf-also" to your access-class, you instructed the device to apply the ACL not only to the default VRF but also to any VRFs that might exist. In your case, even though you're not explicitly using VRFs, the "vrf-also" option seemed to have the effect of covering all potential VRF instances, including the default VRF. This allowed SSH access to work as intended, restricting it to your management subnet.

In summary, while it might seem counterintuitive to use "vrf-also" when you're not explicitly working with VRFs, it appears to have resolved the issue by ensuring that your ACL is applied to the default VRF effectively. It's possible that the CAT6880-X switch architecture or software version you are using requires this option for proper ACL enforcement in your specific setup.

these setup works for me on my website.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: