VTY access-class Behavior With VRFs

Over the past few weeks, I have posted several introductory articles that deal with the concept of VRFs. One behavior that is modified when VRFs are introduced is the VTY access-class command. A router that is configured for VRFs will actually allow incoming VTY (telnet and ssh) sessions from any VRF or from connections arriving in the global IP instance.

To demonstrate this, we will use the VRF topology we have been working from for the past few weeks.

To test a VTY session establishment from a VRF, we will connect to R1 from R2.

Trying ... Open

User Access Verification


[Connection to closed by foreign host]

To demonstrate the behavior with an access-class, we will build an ACL on R1 that permits R2. Then we will apply it as an access-class in the VTY section.

R1(config)#access-list 1 permit host
R1(config)#line vty 0 15
R1(config-line)#access-class 1 in

Now if we run our original test again, we find that the telnet session fails. This is true even though the IP address from R2 is permitted by the access-list.

Trying ...
% Connection refused by remote host


//by default all VRFs are blocked by access-class

If it is truly our desire to allow VTY sessions from traffic arriving in a VRF instance, we can modify the behavior of the access-class. This is done using the “vrf-also” option.

R1(config-line)#access-class 1 in ?
  vrf-also  Same access list is applied for all VRFs

R1(config-line)#access-class 1 in 

R1(config-line)#access-class 1 in vrf-also
R1(config-line)#do show run | sec vty
line vty 0 4
 access-class 1 in vrf-also
 password cisco

Now if we test our connection from a source in a VRF, we see that the VTY connection is permitted (assuming it matches the acl identified in the access-class command).


Trying ... Open

User Access Verification



From this example, we can see that IOS devices will accept all VTY connections by default. However, if an access-class is used, the assumption is that connections should only arrive from the global IP instance. If there is truly a need and a desire to control the IP source while allowing VTY connections from VRF instances, we have a configuration option. However, due to the fact that the same IP source may exist in multiple VRFs, this option might not give the desired granularity of control.

About Paul Stewart, CCIE 26009 (Security)

Paul is a Network and Security Engineer, Trainer and Blogger who enjoys understanding how things really work. With over 15 years of experience in the technology industry, Paul has helped many organizations build, maintain and secure their networks and systems.
This entry was posted in How-To and tagged . Bookmark the permalink.

5 Responses to VTY access-class Behavior With VRFs

  1. Manjunath K P says:

    Thanks Paul..:)

  2. akjol says:


  3. Hani says:

    Thanks for the tips

  4. Luis Fernando says:

    Thank you very much for the information; I have worked for many years with CiscoSwitch 3750 in STACKING, and for access via console I have never used the “# access-class 1 in vrf-also” command, now for the new Switch 3850 in STACKING for access via console on the SWITCH STANDBAY this mode you have to put this command.

Comments are closed.