iamjeffvader's studymotron and rantatorium

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

Matching:

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.

Who-am-I?

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 10.11.12.13 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 10.12.13.14 secret "mysecretfor1"
*A:pe1>config>system>security>tacplus# server 2 address 10.12.13.15 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.

SSH:


*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 10.12.13.0/24


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 ospf-igp src-ip 10.12.13.0/24


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.