Cli context doubt

3 views
Skip to first unread message

Alexandre Heidemann

unread,
Jul 24, 2026, 2:40:09 PM (2 days ago) Jul 24
to Event-Driven Servers
Hello 

I've been testing the cli context, and I need a tip how can I handle with that:

LER-ZTE-6120H-S(config)#interface vlan82 # mark as context VLAN
LER-ZTE-6120H-S(config-if-vlan82)#ip address 10.27.27.1/30
*LER-ZTE-6120H-S(config-if-vlan82)#exit
*LER-ZTE-6120H-S(config)#dhcp # mark as context DHCP
*LER-ZTE-6120H-S(config-dhcp)#interface  vlan82
*LER-ZTE-6120H-S(config-dhcp-if-vlan82)#mode proxy
*LER-ZTE-6120H-S(config-dhcp-if-vlan82)#

I want to allow all commands under the DHCP configuration, but under the "interface vlan " I only want to allow the ip address command.

The challenge is that the interface vlan82 command exists in both contexts. When the parser sees interface vlan82, it switches to the VLAN context instead of the DHCP interface context.

Do you have any suggestions on how I could handle this?

current profile config:

profile access_zte_movel_homolog_v2 {
  script {
    if (service == shell) {
      if (cmd =~ /^interface\s+vlan/) {
        context = "vlan"
        permit
      }
      if (cmd =~ /^dhcp/) {
        context = "dhcp"
        permit
      }
      if (cmd =~ /^(exit|quit|end)/) {
        context = ""
        permit
      }
      if (context == "vlan") {
        if (cmd =~ /ip address/) {
          permit
        }
        deny
      }
      if (context == "dhcp") {
        if (cmd =~ /.*/) {
          permit
        }
        deny
      }
    }
    # <<< tac_mgr_context
    if (service == exec ) {
      if (cmd == "") {
        set priv-lvl = 14
        permit
      }
      permit
    }
    if (service == shell ) {
      set priv-lvl = 14
      if (cmd == "") {
        permit
      }
      permit
    }
    permit
  }
}

Thank u

Marc Huber

unread,
Jul 24, 2026, 3:05:53 PM (2 days ago) Jul 24
to event-driv...@googlegroups.com

Hi Alexandre,

the NAD could support this easily by providing cli context. It doesn't, and, plainly, I don't grasp why simply adding context via some "context" av-pair would escape vendor implementations.

Unfortunately, working around this on the server side (having identical commands at different levels) just isn't possible.

Cheers,

Marc

--
You received this message because you are subscribed to the Google Groups "Event-Driven Servers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to event-driven-ser...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/event-driven-servers/f852c136-ebed-4d3a-8a31-3f4b6fdea71en%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages