Archive

Archive for December, 2012

Unachievable Targets for the Coming Year…

December 31, 2012 Leave a comment

Tis the season to write stuff down on what I hope to achieve over the coming year so that I might laugh at my abject failures in 12 months time.

My primary goal is one of self improvement.  This coming week marks the return of bi weekly squash and I need to be out on my bike cos I’m waaaayyy too fat again.  Regardless of if it’s cold/wet/windy.

Ridiculous one:

1) See Liverpool win the league.  No chance, but some hope all the same.

Professional goals:

2) Complete the NRS2 lab, this one should be achievable.  The issue here is one of cost. $750 worth of cost for a professional level cert!  Plus flights to Brussels and accommodation.  This is where my (lack of) negotiation skills come in to play with work.

3) Complete the SRA lab which includes sitting 5 more written exams.  This one is optional for me depending on completion of the writtens to become eligible.  I have it on good authority I can be at the level required for the lab in a couple of months of consistent practice.

4) Make a decision on whether I continue with my ‘dream’ of the CCIE RS or switch to the SP track, which I prefer.  This will be down to INE in part if they are willing to compromise on what I have already paid for.

5) Do a couple of CCNA levels certs, primarily the SP if INE release some vids as rumoured. As a hater of voice getting that CCNA done would be nice so I have some experience of it.

6) If time allows do the CCNP SP.

Are any of these achievable ?  Only time will tell.

TTFN.

Advertisements
Categories: Uncategorized

SROS System Admin and Security

December 27, 2012 3 comments

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.

Categories: NRS2 Lab, SROS

SROS System Basics

December 24, 2012 Leave a comment

Service Router OS is the operating system that runs on Alcatel-Lucent 7×50 and 7210 routers and switches.  It’s a pretty handy OS and I just love it in the same way Kevin Keegan would love it if we beat them.  It is well structured and very flexible and, once you get used to it, it kicks the pants off other vendors I have used, in my opinion.

There is a distinct lack of information that I have found on the Internet for configuring these boxes, especially considering the 7750 is apparently number 1 or 2 in the PE market in Europe.  In this post I will cover some basic system configurations to get you going.

I will be using SR1 and SR7 routers for config throughout these posts although there are other models available, e.g. SR12.  The SR1 has a single processor and line card with two daughter card slots (MDA) whereas the SR7/12 have dual processors and five and ten line card slots respectively.

In this post I will be using an SR7, its processor slots are named A and B and the line cards are numbered 1-5.  The active processor is indicated by either A: or B: at the CLI prompt. Each daughter slot is labelled x/1 or x/2, e.g. slot 2 sub-slot 2 is MDA 2/2.

Each processor (SF/CPM) holds a male DB9 console connector (with DCE/DTE toggle switch), RJ45 Ethernet management port and three compact flash slots.  The SROS image is stored in cf3 and cf1/2 can be used to store log files etc.

In order to boot the chassis we need to configure the Boot Options File (bof) to locate the image and config files.

To configure the image and config locations point the bof at the directory/file locations.  The A: indicates we are on the processor slot A:


*A:7750#bof
*A:7750>bof# primary-image cf3:\TiMOS-9.0.R11
*A:7750>bof# primary-config cf3:/myconfig.cfg

We then need to set the console speed.  SROS defaults to 115200 so let’s change it to 9600 because everybody loves that one:


*A:7750>bof# console-speed 9600

It’s also a good idea to enable persistent indexing between reboots, especially if you use SAM5620 to manage the devices (a reload is required for it to take effect):


*A:7750>bof# persist on

Finally, you may want to use the RJ45 port if you don’t have an async device available.  It doesn’t register in the Global Routing Table so any configuration here won’t impact on the operation of the router.  Lets set the speed, duplex and an address:


*A:7750>bof# address 1.2.3.4/24 active
*A:7750>bof# speed 10|100
*A:7750>bof# duplex full|half

And that’s pretty much it for the bof, just don’t forget to save your work. If you are in the bof context then it is simply save. If you are in any other context you can use /bof save where the use of / allows the subsequent command to be run from any context.  This also applies to config and admin level commands too.

Finally a word on saving in general.  If the card identifier has a * against it then configuration has not been saved since the last change.  You save the ‘running config’ by parsing admin save, again the / allows the command to be run outside its usual context.  If the * doesn’t disappear after either an admin save or bof save then you will have to parse the other save command. From the config context I will save both the running and bof configs, notice the * disappears:


*A:7750# configure
*A:7750>config# /admin save
Writing configuration to cf3:\myconfig.cfg
Saving configuration ... OK
Completed.
*A:7750>config# /bof save
Writing BOF to cf3:/bof.cfg ... OK
Completed.
A:7750>config#

So that’s it for my first post on this ALU craic.  I plan to build up a network from here on starting at the physical basics all the way up to advanced service configuration.

Happy Christmas.

Categories: labbing, SROS