Catalyst vs Nexus

1, Catalyst supports VSS( Virtual Switch System )for combining 2 switches into one logic switch, just like virtual chassis in Juniper EX. While Nexus support VPC (Virtual port-channel) to combine ports from different switches into the same port channel.  However 2 Nexus switches with VPC configured still run independently in control plane level, therefore L3 redundancy need to be realized by enabling hsrp or vrrp. Virtual chassis in Juniper will select one switch running as control chassis and the rest of the chassis running as line card in active/passive mode. VSS is very much likely as Virtual chassis in Juniper.

2, Nexus support VDC(virtual switching context ) to separate one switch into several switch logically.  VDC will actually run separated control plane for each switching context, that means each VDC has its own L2/L3 instances (vrf, hsrp, lacp, etc)

3, Catalyst support wide range of WAN interfaces and extra FW/VPN modules.

4, FEX support: Nexus 7000 supports the use of the Nexus 2200 Series fabric extenders to additionally expand the system and provide a large-scale virtual chassis in the data center. Up to 32 of the fabric extenders can be supported by the Nexus.

5, Difference between Nexus 7000 and Nexus 9000 is that Nexus support ACI (Application Centric Infrastructure) That will facilitate SDN deployment. There are some other differences too which need to be further researched.

Some concept used in SDN

NETCONF

The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs).

YANG

YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications.

RESTCONF

describes a REST-like protocol that provides a programmatic interface over HTTP for accessing data defined in YANG, using the datastores defined in NETCONF.

BGP-LS

Copied from internet

“BGP-LS is an extension to Border Gateway Protocol (BGP) for distributing the network’s link-state (LS) topology model to external entities, such as the SDN controller. It has received a lot of attention because many SDN apps need this model.

The network’s link-state topology model consists of nodes (typically, but not limited to, routers) and links that connect these routers together. For each link, a set of attributes is also contained. These may include interface addresses, various metrics, and each link’s total and available bandwidth. This topology model is distributed among routers using one of the two prominent Interior Gateway Protocols (IGPs): ISIS (Intermediate System to Intermediate System) and OSPF (Open Shortest Path First) protocols.

The detailed link-state models of these two protocols are not identical. As a result, BGP-LS defines its own more abstract topology model and defines how to map these IGP models to its own model. As the network topology is discovered by the IGPs, the changes are reflected in the BGP-LS model as well and are also distributed using BGP-LS messages to any interested party, such as SDN controllers and apps. Note that the network devices themselves are not interested in learning the network topology this way, as they already participate in IGP and learn it firsthand.”

CISCO APIC

The Cisco Application Policy Infrastructure Controller (Cisco APIC) is the unifying point of automation and management for the Application Centric Infrastructure (ACI) fabric.

It use policy agent to translate polices into instructions.

CISCO EEM

The EEM(Embedded Event manager is a software component of cisco IOS, XR, and NX-OS makes life easier for administrators by tracking and classifying events that take place on a router and providing notification options for those events. EEM allows you to automate tasks, perform minor enhancements and create workarounds.
There are two independent pieces: Applets and Scripting
-> Applets are a collection of CLI commands
-> Scripts are actions coded up in TCL(interpreter language)

EEM uses event detectors and actions to provide notifications of those events:

EEM detectors can be:
1) SNMP:-Monitoring SNMP objects.
2) Syslog:-Responds to various syslog messages, allowing for matching on regular expressions.
3) Counter: Monitoring and responding to interface counter when cross threshold settings.
4) CLI events: Screening CLI input for a regular expression match.
5) None: This event detector is use to test EEM script/applet using “event manager run” command.
6) Timers :(Countdown, watchdog and CRON)
7) IP SLA and Netflows events.

.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

6, RIP version 2 support classless routes ads, but in order to advertise classless route, command “no auto summary” need to be configured.