.cloginrc

.cloginrc is a file that contains login information for each devices that will be accessed via clogin. .cloginrc is normally located under /home/username.

Below is an example of .cloginrc file:

# comments are cool, as is whitespace
# clogin supports a number of add directives:
# password
# user
# userprompt
# userpassword
# passprompt
# method
# noenable
# enauser
# enableprompt
# autoenable
# cyphertype
# identity
#
# Details on each of these follows. Also see cloginrc(5).
#
# add password <router name glob> <vty passwd> <enable passwd>
#
# add user <router name glob> <username>
# The default user is $USER (i.e.: the user running clogin).
#
# add userprompt <router name glob> <username prompt>
# What the router prints to prompt for the username.
# Default: {“(Username|login|user name):”}
#
# add userpassword <router name glob> <user password>
# The password for user if different than the password set
# using ‘add password’.
#
# add passprompt <router name glob> <password prompt>
# What the router prints to prompt for the password.
# Default: {“(\[Pp]assword|passwd):”}
#
# add method <router name glob> {ssh} […]
# Defines, in order, which connection method(s) to use for a device
# from the set {ssh,telnet,rsh}. e.g.: add method * {ssh} {telnet} {rsh}
# will attempt ssh connection first. if ssh fails with connection
# refused (i.e.: not due to authentication failure), then try telnet,
# then rsh.
# Default: {telnet} {ssh}
#
# add noenable <router name glob> <1>
# equivalent of -noenable on the cmd line to not enable at login.
#
# add enableprompt <router name glob> <enable prompt>
# What the router prints to prompt for the enable password.
# Default: {“\[Pp]assword:”}
#
# add enauser <router name glob> <username>
# This is only needed if enable asks for a username and this
# username is different from what user is set to.
#
# add autoenable <router name glob> <1/0>
# This is used if you are automatically enabled by the login process.
#
# add cyphertype <router name glob> <ssh encryption type>
# Default is 3des.
#
# set ssh encryption type, dflt: 3des
# Newer SG300 don’t support cbc, add aes256-ctr
add cyphertype * {aes256-cbc,aes256-ctr}
#
#
#
# add identity <router name glob> <path to ssh identity file>
# Default is your default ssh identity.
#
# include <file>
# include a secondary .cloginrc file
#
#
# Note: The first match for a hostname takes precedence.

#add password sl-bb*-dc cow24
#add password sl-gw*-dc geeks
#add password sl* hank dog
#add password at* pete cow
#add password sdn* mujahid horse
#add password icm* peter
#add password * anything
#
#add user sl-gw*-dc twit
#add user sdn* sdn_auto
#add user sdn-bb* ops_eng
#add user * $env(USER)

# customer x
# these routers ask for a username and password. we automatically get
# enable access after successful authentication.
#add user *.custx.net roger
#add password *.custx.net {doger}
#add autoenable *.custx.net 1

# customer y
# this is the normal cisco login. a password followed by and enable password.
# try ssh first, then rlogin.
#add password *.custy.net {vector} {victor}
#add method *.custy.net ssh rlogin

# customer z; they use ssh only.
#add user *.custz.net shirley
#add password *.custz.net {jive} {surely}
#add method *.custz.net ssh

# the route-server’s do not provide enable access. cmdline -noenable
# equivalent.
#add noenable route-server* 1

# all our routers, i.e.: everything else
#add password * {clearance} {clarence}

# set ssh encryption type, dflt: 3des
#add cyphertype * {3des}

# set the username prompt to “router login:”
#add userprompt * {“router login:”}

# ssh identity for a juniper; used with jlogin
#add identity my.juniper $env(HOME)/.ssh/juniper

# riverstone / enterasys / cabletron (rivlogin) example
# these boxes are ‘back-to-front’ from cisco (i.e., ask
# for vty password always, then tac+/radius if configured).
#
# vty password and last resort (enable) password for rivlogin
#add password rs3000 {vtypass} {lastresort}
# if using tac+ or radius login, include these lines
#add user rs3000 {monster}
#add userpassword rs3000 {scary}

# include non-ssh-capable switches (i.e. 3500XL, 2900XL and sth1-core1a)
include /local/rancid/.cloginrc-switchesnonsshcapable

## Firewalls, only ssh is allowed

add method firewallname* ssh
add user firewallname* username

add password firewallname* {password}

 

Using clogin to automate some boring stuff

In some cases we need do some boring stuff, for example, checking every devices to document hardware type, serier number; to backup configuraiton; doing the same tiny changes on each network devices. It is time-consuming too if you have massive similar devices that you have to login and check one by one. This type of works can be automated by using clogin plus some simple scripts.

According to the maual,  clogin is an expect(1) script to automate the process of logging into a Cisco router, Catalyst switch, Extreme switch, Juniper ERX/E-series, Procket Networks, or Redback router. There are complementary scripts for Alteon, Avocent (Cyclades), Bay Networks (nortel), ADC-kentrox EZ-T3 mux, Foundry, HP Procurve switches and Cisco AGMs, Hitachi routers, Juniper Networks, MRV optical switch, Mikrotik routers, Netscreen firewalls, Netscaler, Riverstone, Netopia, Cisco WLCs and Xirrus arrays.

clogin reads the .cloginrc file for its configuration, then connects and logs into each of the routers specified on the command line in the order listed. Command-line options exist to override some of the directives found in the .cloginrc configuration file.

Below are simple examples of how clogin works:

Example 1

We want to login to each devices and check its serier number.  Let us assume that we have 20 devices, all of them are Juniper EX switches. Indead of logining and checking every devices, we can do the following script in Linux:

  1. list all devices hostname into a file “switches”
  2.  run the following script: for i in `cat /tmp/switches`; do /local/rancid/bin/clogin -autoenable -c “show virtual-chassis” $i >> /tmp/switchessn; done
  3. trim “switchessn” file to remove noneed text if necessary. now we have a file that contain all serier number and hardware type of switches

Example 2

If we need find our root bridge for each vlans in a layer 2 networks. Below is the script that I learned:

  1. Run the the first step to get the bridge ID´s of all the switches listed int eh file swtiches.txt
    for i in `cat /tmp/switches.txt`; do /local/rancid/bin/clogin -autoenable -c "sh spanning-tree bridge \n\n end" $i > /tmp/$i; done
  2. Purge the documents from step 1 to only contan the isolated bridge-id for each switch
    for b in `cat /tmp/switches.txt`; do egrep -o -m 1 "[[:space:]][[:alnum:]]{1,4}\.[[:alnum:]]{1,4}\.[[:alnum:]]{1,4}[[:space:]]" /tmp/170390/$b > /tmp/access-bridge-id/bridge-id_$b.txt; done
  3. As step 3 to collect the “spanning-tree root-id” table from each swith in the switches.txt document
    for v in `cat /tmp/switches.txt`; do /local/rancid/bin/clogin -autoenable -c "sh spanning-tree root \n\n end" $v > /tmp/root-id/root-id_$v; done
  4. Collect all file names containing the access-switch bridge-id´s to one file for parsing during the last step:
    printf "%b\n" /tmp/170390/access-bridge-id/* > /tmp/170390/access-bridge-id/access-bridges.txt
  5. Finally extract all the entries from the previous steps to find out what VLAN´s each access-switch is root bridge for.
    for x in `cat /tmp/170390/access-bridge-id/access-bridges.txt`; do grep -f $x /tmp/170390/root-id/* >> /tmp/170390/final/final.txt ; done

IS-IS for JNCIS

1, DIS is selected based on the highest priority, especially, DIS will be reselected whenever a new router is added into the lan segment. No backup DIS

2,to enable IS-IS on a Junos device, one of the parameters is the network entity title(NET), which is usually set on the lo0 interface, the NET contains the area ID, system ID and selector.

3,IS-IS adjacencies can only form when the level is the same for both peers, and for level 1, the neighbor must be in the same area

4, Link-state PDUs are sent as a response to a link-state request with a PSNP and during the formation of an IS-IS neighbor relationship. They are also sent as a triggered event when network changes occur.

 

The difference between aggregated route and generated route

Generated routes are very similar to aggregate routes, with one exception: generated routes inherit a real next-hop interface, while aggregate routes only allow discard or reject as next-hops.
For example, the following config:
routing-options {
aggregate {
route 192.168.16.0/21;
}
generate {
route 10.0.0.0/16;
}
}
Results in:
lab@lab> show route protocol aggregate
inet.0: 57 destinations, 60 routes (57 active, 0 holddown, 0 hidden)
+ = Active Route, – = Last Active, * = Both
10.0.0.0/16 *[Aggregate/130] 00:00:04
                   > via so-0/0/0.0 <<<<<<REAL NEXT HOP (inherited from contributor)
192.168.16.0/21 *[Aggregate/130] 1d 08:33:02
Reject <<<<<<Reject is the default (can be configured to discard)
Note that they both show up in the routing table as protcol type Aggregate.

 

RIP v2 in nutshell

1, RIP does not form adjacency for each other,  nor do they use hello protocol. It just send out update to the mulitcast destination ip 224.0.0.9 with UDP protocol port 520. RIPv2 router can also configured to use the 255.255.255.255 broadcast ip address, but this is not commonly done.

RIP can also send unicast update, when “neighbor ip-address” command is configured, identifys a neighbor to which unicast RIP updates will be sent.

RIPv2 has only 2 types of messages: requests and Responses

Update interval is 30 seconds by default, update will be full update, when routes change, update will be triggered as well.

2, RIPv2 convergence and loop prevention is realized by the following functions:

  • Counting to Infinity(16)
  • Split Horizon(should not be enabled in point-to-mulitpoint segment)
  • Route Poisoning
  • Split Horizon with Poisoned Reverse
  • Triggered update
  • Update time (30 secs by default)
  • Invalid after time (180 secs by default)
  • Holddown timer (180 secs by default)
  • Flushed after timer (240 secs by default)

When a router has one interface shutdown, router will flush the poisoned routes to all of other interfaces, the update will been sent immediately. When a router has a link down, after “Invalid after time”, the route will be set as invalid, holddown timer starts, after 60 secs, route will be flushed and holddown timer reset, the route change will trigger update as in the first scenario.

3, Routes can be filtered in both “in” and “out” direction by using distribute-list

4, RIPng for IPv6

5, “clear ip route *” command will clear the routing table entry and with RIP, sends RIP requests, quickly rebuilding the routing table

 

IS-IS in nutshell

1, IS-IS is using NASP address to build up adjacency between each node, not IP address.

2, IS-IS is used to solve L1 and L2 routing problem described in

https://yingsnotebook.wordpress.com/2017/05/27/osi-network-tcpip

Especially L1 is similar with OSPF Not So Stub Totally Stub area, L1 area has no information about l2 routing and any other l2 area’s routing, it has only a default router (L1L2 router) which will connect this L1 area to L2 area; L2 area is similar with OSPF backbone area, which has information of both L2 and L1 areas.

When OSI network model is used, L2 will carry only area id info because L2 only need to forward the traffic towards correct L1 area, it does not have to know all ES address in L1 area. When IP is used, L2 will have IP information for networks directly connected in L2 router, and also the networks routes learned from L1 route calculation.

L1L2 router will have two IS-IS link databases, one is for L1 area which it connects to, the other is for L2. L1 and L2 databases are separated and can not be shared with each other, but L1L2 router will advertise routes learned according to L1 calculation to L2 database.

3, In IS-IS there are two types of network link: point-to-point and broadcast link. While point-to-multipoint can be simulated as several point-to-point links.

All interfaces in broadcast link will participate in DIS selection, like DR and BDR selection in OSPF broadcast link, but unlike DR and BDR role in OSPF, DIS in IS-IS is not the only one router which can send out LSP update, instead, all routers in  IS-IS broadcast link can send out LSP update. DIS is used to:

  • Help routers on a broadcast segment to synchronize
  • Representing the broadcast segment in the link-state database as a standalone object- The Pseudonode

4, Unlike OSPF which has several types of LSA, in IS-IS each router generate only one LSP, which includes all routes information of the router, LSP can be very long and need to be segmented to transfer in Layer two network, a sequence number will be used to identify the LSP packet sent by each router.  Router selected as DIS will generate 2 LSP: One is the general LSP for routing information, the other is Pseudonode LSP to indicate broadcast segment information. LSPID will be system ID + Pseudonode ID(local circuit ID of the interface)

5,  IS-IS has 3 adjacency states:

  • Down: the initial state
  • Initializing: IIHs have been received from the neighbout, but it is not certain that the neighbor is properly receiving this routers IIH
  • Up: IIHs have been received and also it is certain that the neighbor is properly receiving this router’s IIHs

6, IS-IS is a true multiprotocol routing protocol in the sense that it does not require any particular Layer 3 routing to carry it packets, and in a single instance, it can carry informaton of destination described by different address families, for example IPv4 and Ipv6 can be carried at the same time a single LSP and maintained in the same link state datebase.

OSI network & TCP/IP

OSI teminology: ES (end system)  is used as host in TCP/IP, IS( Intermediate System) is used for a router

In network layer of OSI reference model, there are 2 modes for end-to-end communication: connectionless-mode and connection mode. For connection-oriented mode, an adaptation of the x.25 is used, there is no analogous connection-oriented network layer protocol in TCP/IP. Connectionless-mode network protocol (clns) is to OSI networks what IPv4/v6 are to TCP/IP networks.

NSAP address is the address used in OSI reference model, unlike ip address, each IS node has only one NSAP address, each interface on the IS node is represented with local circuit ID. NSAP has minimum 8 octets, with only AFI, system ID and SEL. Tha maximum size is 20 octotets

Levels of Routing in OSI networks:

Level 0 routing: between ES and IS

Level 1 routing: between ES nodes within the same area

Level 2 routing: between ES nodes which are in the different area of the same domain

Level 3 routing:between ES nodes which are in different domains

IS-IS provice level 1 and level 2 routing. BGP  for inter-autonomous system routing in TCP/IP is fairly analogy of Level 3 routing.