Home > NRS2 Lab, SROS > SROS System Admin and Security

SROS System Admin and Security

This post will cover the basics of system configuration along with some security such as adding user names but also more advanced features including control plane filters.

First a few commands to get around the config files:

Context Navigation and Hierarchy:

exit drops you back to your previous level of the hierarchy,  exit all brings you back to root and back moves you back up one level of the hierarchy.

To enter config mode you simply type configuration (unambiguous commands are self completing)

Typing info will show you configured commands within your present working context, which itself can be viewed with pwc.  Using info detail will show all commands in the pwc including defaults, a very useful one!

As mentioned in my previous post / allows you to parse a command that would otherwise not be available.

tree will show you a tree structure of all available commands within your context


The availability of pipe commands is very useful in many OS, SROS being no different.  You can pipe any show, info or tree command to include or exclude variables but you can’t concatenate multiple matches in to one string:

info | match address will display any lines with ‘address’ in it

info | match match-not address will display all lines excluding ones with ‘address’ in it

info| match pre-lines 10 address will show you the 10 lines of config prior to a line with address in it,

info | match post-lines 10 address will show you the subsequent 10 lines of config if ‘address’ is matched.

Both the pre and post line match commands are very useful for locating config lines in large files.  I frequently see files with over 10,000 lines of config, a downside of the granularity of SROS.

You match a string with spaces by using speech marks:

info | match "address 10"  will show you anything with address 10 in the line, such as all network 10 addresses configured.


Configuring systems for human identification is crucial in an operational environment for obvious reasons.  Here we look at configuring systems name, location information, banners and NTP

A:7750# configure system name "pe1"
*A:pe1# configure system
*A:pe1>config>system# location "In a rack somewhere"
*A:pe1>config>system# contact "NOC @ 1234567890"
*A:pe1>config>system# login-control
*A:pe1>config>system>login-control# motd text "This is my router"
*A:pe1>config>system>login-control# pre-login-message "Unauthorized access prohibited"
*A:pe1>config>system>login-control# back
*A:pe1>config>system# time ntp
*A:pe1>config>system>time>ntp# server version 3 prefer
*A:pe1>config>system>time>ntp# no shutdown
*A:pe1>config>system>time>ntp# back
*A:pe1>config>system>time# zone [timezone]

Access Security:

I’m not  a security person by any means but it is always something we need to be conscious of.  At  a minimum we should be setting local authentication on a device.  To set up secure access we can configure a local user:

*A:pe1>config>system# security
*A:pe1>config>system>security# password authentication-order tacplus local exit-on-reject

This is pretty straightforward telling the router to use tacacs+ followed by local auth. Should authentication be rejected exit back to the login prompt.

To configure a local user:

*A:pe1>config>system>security# user "myname"
*A:pe1>config>system>security>user# password "mylocalpwd"
*A:pe1>config>system>security>user# access console
*A:pe1>config>system>security>user# console
*A:pe1>config>system>security>user>console# member "administrative"
*A:pe1>config>system>security>user>console# member "default"

To configure tacacs+ return to the system security context:

*A:pe1>config>system>security# tacplus
*A:pe1>config>system>security>tacplus# accounting
*A:pe1>config>system>security>tacplus# authorization
*A:pe1>config>system>security>tacplus# server 1 address secret "mysecretfor1"
*A:pe1>config>system>security>tacplus# server 2 address secret "mysecretfor2"

You can configure stuff for the SAM5620 manager but I won’t go in to hit as I don’t have a test SAM server.

CPM Filters

CPM filters are what protects your processor and it’s protocols for being compromised, such as OSPF neighbours from a specific subnet. These are not available on the SR1. Extreme care should be take as no-shutting the filters before allowing your own access method can disconnect you from the chassis, and there is no remote way to fix it without out of band. In this section we will configure basic SSH access control and OSPF.


*A:pe1>config>sys>security# cpm-filter
*A:pe1>config>sys>security>cpm-filter# ip-filter
*A:pe1>config>sys>sec>cpm-filter>ip-filter# entry 10 create
*A:pe1>cfg>sys>sec>cpm>ip-filter>entry# action accept [drop|queue]
*A:pe1>cfg>sys>sec>cpm>ip-filter>entry# match protocol tcp dst-port 22 65535
*A:pe1>cfg>sys>sec>cpm>ip-filter>entry# match src-ip


*A:pe1>config>sys>security# cpm-filter
*A:pe1>config>sys>security>cpm-filter# ip-filter
*A:pe1>config>sys>sec>cpm-filter>ip-filter# entry 10 create
*A:pe1>cfg>sys>sec>cpm>ip-filter>entry# action accept [drop|queue]
*A:pe1>cfg>sys>sec>cpm>ip-filter>entry# match protocol ospf-igp src-ip

You should configure all your protocols to be permitted where required and only no shut the CPM filters when you have permitted your own access, e.g. a SSH filter permitting a source subnet you are on.   I will post something on CPM protection when I dabble in it, it’s on my list of ‘to investigate’.

The last thing I want to mention under the configure system banner is the chassis mode.  This controls service resources including FIB sizes and can be A, B, C or D.  The SR1 supports mode A only which is somewhat limited.
Mode B allows 128k MAC FIB entries and the same ipv4 ARP entries.  Mode C must be enabled to allow for IPv6 but chassis mode D is the most scalable.  Mode D can support up to 500k MAC and an equivalent amount ARP entries.  The chassis mode you run can only be as good as the line cards you have installed.  If you have IOMv1 or v2 then you cannot run mode D regardless of the amount of higher spec cards.  If you have IOMv3/IMM only then you can run mode D.  Upgrading a chassis mode does not impact service traffic but downgrading, say from C to B, requires a reboot.  It is enabled using configure system chassis-mode [a|b|c|d]

That’s it for this post, the next ones will relate to actual network build.  I will do up a Visio with the topology and start at bringing the physical network up.

Categories: NRS2 Lab, SROS
  1. Evans
    March 19, 2014 at 9:55 am

    I would like to know how to do configure a user on 5620 SAM to be able to access nodes in the network..

    • iamjeffvader
      March 19, 2014 at 7:05 pm

      Hi Evans, I’m not really a GUI guy so I don’t know how to configure users in SAM. I did it years ago and I recall it was very involved with permissions. Best speak to your ALU SE.

  2. fk
    January 19, 2016 at 8:20 am

    Hi Evans.
    login on 5620 SAM
    go to user Administration menu – select Security – then click on NE user configuration
    Click on Create button , Enter username and description and turn on check on console
    As soon as you click on Apply button you will see another page enter your password here and other options as per your demand
    now click on profiles tab select admin or leave it as default.
    return back to General tab in 2nd line rite infront of “configuration mode” label you will switch mode button click on that select all nodes on which you want to create this user and press distribute . all done cheerz 🙂

    PS: this is the user which will be created on all nodes i hope you ask this not the SAM login user

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: