If working in the networking industry especially with $big_vendor equipment it is helpful to have an overview of interfaces on a working component. This is not complicated if you have access to the CLI. Usually you do something like:
R1#sh int descr
Interface Status Protocol Description
Fa0/0 admin down down
Gi1/0 up up
Gi2/0 up up
Gi3/0 admin down down
Gi4/0 admin down down
Fa5/0 admin down down
Fa5/1 admin down down
Gi6/0 up up
Lo0 up up
So getting an overview on CLI with a handful of interfaces is pretty easy, you juggle some pipes and excludes or includes and et voiala:
R1#sh int descr | i up
Gi1/0 up up
Gi2/0 up up
Gi6/0 up up
Lo0 up up
R1#
You have an overview. Sometimes you get an request from management, we need a spreasheet with or at least a CSV file so we can apply our own filters with it. Well in this case you need to export everything to a text file: (to external source or you might save it on flash the scp somewhere). It is up to you.
R1#sh ip int brie | tee tftp:/interfaces.txt
Then you need to replace all whitespaces that are >=2 line into commas.
sed 's/ \{2,\}/,/g' interfaces.txt
Then again you receive a csv file which can be imported into a spreasheet program for further working.
Interface,Status,Protocol Description
Fa0/0,admin down,down
Gi1/0,up,up
Gi2/0,up,up
Gi3/0,admin down,down
Gi4/0,admin down,down
Fa5/0,admin down,down
Fa5/1,admin down,down
Gi6/0,up,up
Lo0,up,up
As I have been working with IOS or IOS-XE devices over the years there have been always new methods added on howto add a username and secret to the running configuration. The last new secrets that have proved insecure has been the cisco type 4 secret. It took around 1 year to prove that this type of hash has been cracked.
At these days one should at least use SHA256 hashes, or even better SHA512. Bruce Schneier suggests to use Twofish.
On the IOS CLI I have discovered new way to generate SHA256 hashes or SCRYPT. I would not suggest to use SCYPT but it is sure better than a TYPE7 crypted password. So everyone should choose its poison.
Here an example on how to generate a descent encrypted password hash:
R1(config)#username test algorithm-type ?
md5 Encode the password using the MD5 algorithm
scrypt Encode the password using the SCRYPT hashing algorithm
sha256 Encode the password using the PBKDF2 hashing algorithm
R1(config)#username test algorithm-type sha256 ?
secret Specify the secret for the user
R1(config)#username test algorithm-type sha256 secret ?
LINE The UNENCRYPTED (cleartext) secret for the user
R1(config)#username test algorithm-type sha256 secret test ?
LINE <cr>
R1(config)#username test algorithm-type sha256 secret test
R1(config)#do sh run | i username
username test secret 8 $8$TE8n7dWN/KlQyE$eceJA2BUi4U/PuqdKzZkA34XfIwNPQzsIll5LoDS0pw
And a scrypt password hash looks like this
R1(config)#username test algorithm-type scrypt secret test
R1(config)#do sh run | i username
username test secret 9 $9$BcqD2r2quPOAZk$9ou68K/72Z3dHeaolP.YNyvn4b5jOJWsczV9dw6ZzmU
So in IOS/IOS-XE a SHA256 password hash has a $8$ prefix and a SCRYPT hash has a $9$ prefix.
Let's wait until the double digit prefix appears $10$ identifying a Twofish encrypted password. Or at least Blowfish should be implemented. I would wish that
This is a reminder to myself. I like using convenient configured services:
I like using Name Based Virtual Hosts, the user experience is a lot better.
This is a reminder for myself because I constantly forget howto secure copy a file form an IOS component to a network target. The syntax is somehow hard to remember:
R1#copy sup-bootflash:/file.txt scp://user@host
The keys defined on a X11 system running can be looked up in following file:
/usr/include/X11/keysymdef.h
To find out if the specified file above is on your running system use following command:
locate keysymdef.h
Searching for special key:
user@host~ grep -i space /usr/include/X11/keysymdef.h
#define XK_BackSpace 0xff08 /* Back space, back char */
#define XK_KP_Space 0xff80 /* Space */
#define XK_ISO_Partial_Space_Left 0xfe25
#define XK_ISO_Partial_Space_Right 0xfe26
#define XK_space 0x0020 /* U+0020 SPACE */
#define XK_nobreakspace 0x00a0 /* U+00A0 NO-BREAK SPACE */
#define XK_emspace 0x0aa1 /* U+2003 EM SPACE */
#define XK_enspace 0x0aa2 /* U+2002 EN SPACE */
#define XK_em3space 0x0aa3 /* U+2004 THREE-PER-EM SPACE */
#define XK_em4space 0x0aa4 /* U+2005 FOUR-PER-EM SPACE */
#define XK_digitspace 0x0aa5 /* U+2007 FIGURE SPACE */
#define XK_punctspace 0x0aa6 /* U+2008 PUNCTUATION SPACE */
#define XK_thinspace 0x0aa7 /* U+2009 THIN SPACE */
#define XK_hairspace 0x0aa8 /* U+200A HAIR SPACE */
Anoter useful X tool to find out a key name is called xev. This tool is part of the X.org server pacage.
I have discovered a interesting default behaviour on a Nexus 7000 Router while troubleshooting. The Cisco Nexus 7000 switches (in this case a router), seem to drop ICMP echo replies.
Pinging from a directy connected IOS/IOS-XE device:
S1#ping 192.0.2.1 repeat 1000
Type escape sequence to abort.
Sending 1000, 100-byte ICMP Echos to 192.0.2.1, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!
Success rate is 99 percent (998/1000), round-trip min/avg/max = 1/3/24 ms
You always want to have Success rate is 100 percent if devices are directly connected.
If pinging a target IOS/IOS-XE device over a routed network the result looks like this:
S1#ping 198.51.100.250 repeat 1000 size 1500 df-bit
Type escape sequence to abort.
Sending 1000, 1500-byte ICMP Echos to 198.51.100.250, timeout is 2 seconds:
Packet sent with the DF bit set
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (1000/1000), round-trip min/avg/max = 1/4/20 ms
Success rate is 100 percent with the df-bit and the maximum packet size. That is called a reliable link.
- No packetloss if pinging over a routed network
- Packetloss on directly connected devices
On the NX-OS router pinging the directly connected S1 switch. S1 has the IP 192.0.2.10.
R1# ping S1 count 1000
...
64 bytes from 192.0.2.10: icmp_seq=995 ttl=254 time=1.396 ms
64 bytes from 192.0.2.10: icmp_seq=996 ttl=254 time=2.188 ms
64 bytes from 192.0.2.10: icmp_seq=997 ttl=254 time=1.339 ms
64 bytes from 192.0.2.10: icmp_seq=998 ttl=254 time=1.352 ms
64 bytes from 192.0.2.10: icmp_seq=999 ttl=254 time=1.333 ms
--- S1 ping statistics ---
1000 packets transmitted, 996 packets received, 0.40% packet loss
round-trip min/avg/max = 1.014/1.786/17.317 ms
This link is not reliable enough. It looks like something is blocking the traffic.
And it is true. The documentation reveals a default security feature called CoPP (Control Plane Policing).
R1# sh copp status
Last Config Operation: None
Last Config Operation Timestamp: None
Last Config Operation Status: None
Policy-map attached to the control-plane: copp-system-p-policy-strict
It says the control plane has a policy-map attached to it. Strict or policy-stict. Looking deeper reveals:
R1# sh policy-map type ?
control-plane Control-Plane
network-qos Type network-qos
qos Type qos
queuing Type queuing
...4 different types of policy-maps are configured. The one we are interested in is the control-plane policy map:
R1# sh policy-map type control-plane
...
class copp-system-p-class-monitoring
set cos 1
police cir 130 kbps bc 1000 ms
conform transmit violate drop
...
And here a detailed output:
R1# sh policy-map type control-plane expand
...
class copp-system-p-class-monitoring
match access-group name copp-system-p-acl-icmp
match access-group name copp-system-p-acl-icmp6
match access-group name copp-system-p-acl-mpls-oam
match access-group name copp-system-p-acl-traceroute
match access-group name copp-system-p-acl-http-response
match access-group name copp-system-p-acl-smtp-response
match access-group name copp-system-p-acl-http6-response
match access-group name copp-system-p-acl-smtp6-response
set cos 1
police cir 130 kbps bc 1000 ms
conform transmit violate drop
...
There is a class named copp-system-p-class-monitoring This particular class applies to following ACL's f.e:
- copp-system-p-acl-icmp
- copp-system-p-acl-icmp6
And some other well known protocols listed.
The policy map assignes the matched traffic (ICMP,HTTP,SMTP...) as class 1. This policy map has a Commited information rate (CIR) of 130 kbps. If the ICMP Traffic exceeds this threshhold the traffic will be dropped.
Hence the Quest is over.
We found a configuration snipplett for rate-limits incoming/outgoing traffic.
Limits are applied to modules 3-6:
R1# sh policy-map interface Control-plane | b monitoring
class-map copp-system-p-class-monitoring (match-any)
match access-group name copp-system-p-acl-icmp
match access-group name copp-system-p-acl-icmp6
match access-group name copp-system-p-acl-mpls-oam
match access-group name copp-system-p-acl-traceroute
match access-group name copp-system-p-acl-http-response
match access-group name copp-system-p-acl-smtp-response
match access-group name copp-system-p-acl-http6-response
match access-group name copp-system-p-acl-smtp6-response
set cos 1
police cir 130 kbps bc 1000 ms
conform action: transmit
violate action: drop
module 3:
conformed 194465448 bytes,
5-min offered rate 16 bytes/sec
peak rate 80 bytes/sec at Sun Dec 11 07:59:43 2016
violated 0 bytes,
5-min violate rate 0 bytes/sec
peak rate 0 bytes/sec
module 4:
conformed 2019193 bytes,
5-min offered rate 0 bytes/sec
peak rate 550 bytes/sec at Thu Dec 29 14:29:46 2016
violated 510 bytes,
5-min violate rate 0 bytes/sec
peak rate 1 bytes/sec at Thu Dec 29 14:29:46 2016
module 5:
conformed 0 bytes,
5-min offered rate 0 bytes/sec
peak rate 0 bytes/sec
violated 0 bytes,
5-min violate rate 0 bytes/sec
peak rate 0 bytes/sec
module 6:
conformed 275859216 bytes,
5-min offered rate 13 bytes/sec
peak rate 505 bytes/sec at Sun Oct 02 09:14:32 2016
violated 64 bytes,
5-min violate rate 0 bytes/sec
peak rate 0 bytes/sec
In the example above the drop policy has been hit on Thu Dec 29 14:29:46 2016 to module 4.
NX-OS cisco devices have default settings preconfigured to protect the control plane.
Further documentation about NX-OS CoPP feature is found here:
oneliner to see the troublemakers:
R1#show policy-map interface control-plane | i "class|conform|violated"