IOS-XE 16.8.x line vty 'vrfname'

[johnlloyd_13]

hi,

i noticed the 'vrfname' under the line vty. i checked it was recently introduced in IOS-XE 16.8.x.

i usually use 'vrf-also' for our MGMT VRF and haven't seen anyone use 'vrfname' that much per my google search.

my question is, what's the difference between the 'vrf-also' and 'vrfname'? is 'vrfname' more secure?

what are some use case examples for the 'vrfname'?

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/bbdsl/configuration/xe-16-11/bba-xe-16-11-book/bba-xe-16-8-book_chapter_0100101.pdf

(config)#line vty 0 4

(config-line)#access-class acl_VTY_ACL in ?

  vrf-also  Same access list is applied for all VRFs

  vrfname   Access list is applied for given VRFs

  <cr>      <cr>

[Seb Rupik]

Hi there,

The decision to allow all VRFs access to the VTYs or limit it to just one depends on your topology and security posture. Certainly vrf-also is convenient, but if you are operating a multi tenant environment then it would make sense to limit access to the management plane to just one VRF, ie, the L3 domain which contains your management VLAN.

cheers,

Seb.

[balaji.bandi]

Do not want to re-invent the wheel :

good explanation here :

https://community.cisco.com/t5/switching/vty-access-class-vrf-also-question/td-p/2528048

[johnlloyd_13]

hi balaji,

i'm aware of the 'vrf-also' and use it in our environment. my question is regarding 'vrfname' if has the same purpose and what's the main difference between the two.

i don't see it commonly used since it's relatively new.

[Seb Rupik]

I have the opposite experience and always use 'vrfname Mgmt-vrf' as switches are connected via the out of band gi0/0 switchport.

vrfname is useful as it allows you to explicitly list the VRFs you want to have access instead of opening the flood gates and using vrf-also, as you eluded to in your first post, this should be considered more secure.

cheers,

Seb.

[balaji.bandi]

adding @Seb Rupik  comment...

  vrf-also  Same access list is applied for all VRFs
  vrfname   Access list is applied for given VRFs

Commands are self explanatory. If you have more VRF ( VRF-also works) - if you looking Granular 1 VRF - VRFNAME should do the job

Make sense ?

[johnlloyd_13]

hi balaji,

is using 'vrf-also' tied to the default 'Mgmt-intf' VRF, which is applied to the dedicated OOB management port?

[balaji.bandi]

yes mgmt vrf should cover technically. (if that is the only VRF available in your network, i prefer to go with vrfname

vrfname   Access list is applied for given VRF

[Elliot Dierksen]

I know I am necro-ing an old thread here, so sorry about that. My process for routers handling untrusted traffic (like internet routers) prior to the support for being able to name a specific vrf in the access class on the vty's was to put the management traffic in the global routing table and then untrusted traffic in a vrf. That way when I specified an access class without the 'vrf-also' keyword then all traffic from vrf's was blocked. I a context where management traffic is in 'Mgmt-intf', can I specify an access class for that vrf that permits certain hosts, and then another access class without a vrf keyword that denies all traffic from the global routing table? The routers I have with this now are remote and I don't want to lock myself out.