You might be an Network Guy If

Preparing to CCNP SWITCH by the official certification guide involves lots of side research. Previous time, filling my gaps in STP, I found spanning tree poem. Today I was researching about STP again and found an interesting text, which is a joke about telecom guys. By far I know telecom-involved people as the ones who have no any kind of subculture whatsoever. Programmers and Administrators have their jokes, legends, stories, even official days. Telecom guys do not seem to. Or it might be my impression only. Nevertheless, I'm going to collect stuff here which might belong to a "nonexistent" telecom subculture.

You might be an Network Guy If

You know more ip addresses than phone numbers
You regularly mock TV shows for using technology that isn't part of the feature set available on the devices they have
You correct people who mix up Megabytes and Megabits
You waited eagerly for wireless N to be approved officially.
You can explain everything in your life using 7 layers
You tell people not to use TKIP because of it's security flaw
You think people should be able to do without DNS for a day, just use IP addresses...
You follow your wife around shopping retail stores and spend your time skimming the ceilings for their APs and mapping out a heat map of the store in your head
You know what TCP/IP stands for, not to mention DNS, HTTP, SNMP, BGP, OSPF, WPA, and DHCP - Sometimes you wonder if you know more acronyms than words
You've known what IPv6 was for years
Cmd, telnet, and ssh are useful everyday tools, not just black boxes
Linus Torvalds comes up in everyday conversation
You know jokes about DHCP and LSAs
You cringe when you have to use a Gui to configure a switch or router
Your Amazon wish list consists of routers and ASA firewalls
Dealing with Tier 1 tech support makes you pull your hair out.
You have read the NSA's security best practices
The routing protocol in your house changes daily depending on what you have been reading
You know what a nibble is
You know what 1000 Terabytes is called
You can intelligently discuss how Egypt shut off their Internet to the country

Source


Cisco IOS replace running config instead of merge

By default, if you do

# copy startup-config running-config

the startup config would be merged to the running one. The same happens if you use tftp:// or flash:// instead of startup-config. Eventually, there is a way to replace the running config. The command is:

# configure replace ftp://192.168.1.1/dyn1_bgp

Juniper Network Connect Eerror nc.windows.app.23711 Fix

Diagnosis for me was getting error nc.windows.app.23711 after a random amount of time running VPN to IVE.

According to Juniper forums and burgtrack [1, 2], The error message is caused by something changing your computer's route table. It may be any application. hen it happens, you are going to receive similar message in a network connect log (when set to 'Detailed info' level: Advanced View -> Logs):

00218,09 2012/04/12 23:20:43.001 1 SYSTEM dsNcService.exe dsNcService p1612 t690 routemon.cpp:582 - 'rmon' Unauthorized new route to 10.95.48.228/192.168.1.7 has been added (conflicts with our route to 0.0.0.0), disconnecting

The message is not going to be the last one before you receive the error, you have to scroll a bit up to find it.

Since I had no Bonjour installed, I had to find anything what could change my routing table. I searched registry for IP address appeared in logs. It should have pointed me to a software abusing my routing. In the registry of mine the address appeared few times, all in printing settings. Most of the branches having '10.95.48.22' record had 'Hewlett Packard' record, or appeared in HP branch, or had other relation to HP. Since the soft belonged to HP, I had to prevent anything developed by HP from starting up with my system. I used autoruns by Sysinternals to disable all the HP-vendored soft. After the reboot I discovered my VPN connection would not interrupt. After enabling services one by one, I found out the issue was caused by

c:\windows\system32\hptcpmon.dll

I suppose it is some kind of driver or so. Most likely it is a part of printing driver ver 61.93.1.67 for HP LaserJet M2727 MFP Series PCL 6 on Windows 7 64 bit. But I'm still not 100% sure that the issue cause by the driver itself. It may be caused by Windows 7, who attempts to add a route to the installed TCP/IP printer.


Spanning tree poem

There is eventually a spanning-tree poem. I found two versions. A version by Radia Perlman

I think that I shall never see
A graph as lovely as a tree.
A tree which must be sure to span.
So packets can reach every LAN.
First the root must be selected.
By ID, it is elected.
Least cost paths from Root are traced.
In the tree these paths are placed.
A mesh is made by folks like me.
Then bridges find a spanning tree.

A version from Network Warrior:

I think that I shall never see
A graph more lovely than a tree.
A tree whose crucial property
Is loop-free connectivity.
A tree which must be sure to span.
So packets can reach every LAN.
First the Root must be selected
By ID it is elected.
Least cost paths from Root are traced
In the tree these paths are placed.
A mesh is made by folks like me
Then bridges find a spanning tree.


Funny bugfixes in Nortel 6.2.4 ERS software release

There are few nice bugs in Nortel 6.2.4 ERS release (release notes). There are update surprises:

  • After Upgrading from 6.1.1 to 6.2.1, QoS configurations were lost (wi00838747)
  • Some links get disabled after upgrade from 5.1.x to 6.x (wi00731564)
  • Stack upgrade failure from 6.1.4.011s to 6.2.1.003s with a large config file (wi00882592)
  • After upgrading from 5.1.4 to 6.2.1 EDM routing/IGMP/SNOOPING table expanded indefinitely causing high CPU utilization (wi00886347)

Weird issues, which can be explained by lack of objects interoperability:

  • Unable to add static route under certain conditions, adding the route required a reboot (wi00937754)
  • With autosave enabled on 5632FD, if the power is recycled the fiber connectivity to 470-48T switch is lost (wi00941175)
  • Autonegotiation could not be disabled (wi00824799)
  • Ping or Telnet to any DNS hostname would sometimes cause loss of connectivity to the management VLAN requiring a reboot of the stack (wi00933202)

Very weird bugs, which cause many wtf-like questions on the source code:

  1. Using show running-configuration with 744 VLANs configured, spiked the CPU utilization to 100% for about 12-15 minutes (wi00907462)
  2. Switch does not learn MAC of format xx:59:xx:xx:xx:xx (wi00870510)
  3. Cannot give an IP address to the switch with the last octet as "0" (wi00872983)

I can explain the third bug by an error of checking network address in classless notation. I suppose, the code was checking an IP address in a classful way, i.e. if IP ends by zero, it's a network address, hence can not be assigned.

How could they create bugs 1 and 2? They should've had hard coded numbers 744 and 0x59 (dec89). Why? what was the purpose? What was the algorithm? Can you guess an algorithm by knowing the information above?


How to Remove Juniper Netscreen Tunnel Interface

1. Delete all routes for all VR's

set route 10.0.0.0/24 interface tunnel.1 preference 20
set route 10.0.0.0/24 interface tunnel.1 preference 20

2. Delete all policy entries

set policy id 1 name "Policy Name" from "Trust" to "Untrust"  "Local" "Remote" "HTTPS" permit
set policy id 1
set service "Remote-services"
exit
set policy id 2 from "Untrust" to "Trust"  "Remote" "Local" "ANY" permit
set policy id 2
set dst-address "Trust-networks"
exit

3. Delete all policy elements

set address "Untrust" "Network Name" 10.63.194.0 255.255.255.0

4. Delete all interface bindings. Via web interface you should edit AutoKey IKE entry by removing interface binding first (advanced settings), only after delete the AutoKey IKE

set vpn "PH2_Policy" id 0x1b9 bind interface tunnel.1

5. Delete AutoIKE entry

set vpn "PH2_Policy" gateway "PH1_Policy" no-replay tunnel idletime 0 sec-level standard
set vpn "PH2_Policy" monitor source-interface ethernet0/1 optimized rekey
set interface tunnel.1 ip unnumbered interface ethernet0/1

6. Delete the tunnel Interface

set interface "tunnel.1" zone "Untrust"

Bringing Cisco IOS CLI to Linux CLI

There are few people on the globe who loves to work with Cisco and Linux via CLI. These people might have issues with trying to apply Bash/Vim syntax to IOS and vice versa. I'm certainly one of them. That's why I can do the followng in my Bash:

$ show .bashrc | i return
[[ "$-" != *i* ]] && return
#     return 0
#     [[ -z $adir ]] && return 1
#   [[ $? -ne 0 ]] && return 1
#     [[ $? -ne 0 ]] && return 0
#   return 0

It's very handy for checking Cisco configs, stored on a Unix machines, without inverting your mind out. In fact, if you are in rush and tried to apply IOS syntax to Bash, you won't be distracted by an error message, but you'd get a result you reqired.

$ show samle_conf.cfg | i spanning-tree
spanning-tree mode rapid-pvst
spanning-tree etherchannel guard misconfig
spanning-tree extend system-id
spanning-tree pathcost method long
 spanning-tree portfast
 spanning-tree portfast
 spanning-tree portfast
spanning-tree bpduguard enable
...

It's achieved very easily. You need to add some aliases to your ~/.bashrc file and relogin:

echo 'alias show="cat"' >> ~/.bashrc
echo 'alias i="grep --color"' >> ~/.bashrc

Fixing SSH access on cisco via SNMP

Sometimes you may ecounter a situation, when your SSH is not properly configured, for example, if you forgot to generate SSL certificate before enabling transport input ssh on all vty lines, as I recently did. In this situation you might be lucky enough to have SNMP RW community string configured. In this situation you can fix literally everything.

There are no many configurable settings on cisco can be done via SNMP. But you can copy a prepared config to device via TFTP, RCP etc. You may download current device's config to tftp server, edit necessary lines and upload it back. You may upload it to either running config, startup config or a flash file.

To download running config:

snmpset -v 1 -c rw_community hostname ccCopyProtocol.13 i 1 
snmpset -v 1 -c rw_community hostname ccCopySourceFileType.13 i 4 
snmpset -v 1 -c rw_community hostname ccCopyDestFileType.13 i 1 
snmpset -v 1 -c rw_community hostname ccCopyServerAddress.13 a tftp_serv_ip
snmpset -v 1 -c rw_community hostname ccCopyFileName.13 s "file_name" 
snmpset -v 1 -c rw_community hostname ccCopyEntryRowStatus.13 i 1

Edit on the server, and upload it back by the following commands. Be careful! If you upload to startup-config, IOS will not merge the uploaded config and the startup one, it will replace it instead. Do not upload partial sets of commands!. TO be on a safe side always I recommnd to never upload partial configs. Only necessary lines should be added/cancelled/corrected and the whole config should be uploaded.

snmpset -v 1 -c rw_community hostname ccCopyProtocol.13 i 1 
snmpset -v 1 -c rw_community hostname ccCopySourceFileType.13 i 1 
snmpset -v 1 -c rw_community hostname ccCopyDestFileType.13 i 4 
snmpset -v 1 -c rw_community hostname ccCopyServerAddress.13 a tftp_serv_ip
snmpset -v 1 -c rw_community hostname ccCopyFileName.13 s "file_name" 
snmpset -v 1 -c rw_community hostname ccCopyEntryRowStatus.13 i 1

If you ecountered situation with SSH with no generated certificate, You config might look like this:

line vty 0 4
 length 0
 transport input ssh
line vty 5 15
 transport input ssh
exit

You should fix it to:

line vty 0 4
 length 0
 transport input telnet
line vty 5 15
 transport input telnet
exit

Some commands can be cancelled with "no " statment before the command. Some, as in above case, not.


IPv4 free address pool is empty. No reason to panic.

What Happened?

ICANN announced there are no more IPv4 addresses. What they said was IANA have delegated the last blocks to RIR's. Does it mean you can no longer get a public block of addresses? No. You still can get a brand new block from your local RIR. Or yet unallocated block from your local ISP. Meaning, there is NO reason to panic.

How IP address allocation works?

For ones, who does not know how IP addresses are given out. The process is the following. The original holder of the whole free address space for both IPv4 and IPv6 is IANA. IANA registers and delegates IP address blocks to Regional Internet Registries (RIR's). RIR's alocate IP addresses and IP address blocks to end customers. If you want to get an IP address, you have to allocate a block by registering it in your local RIR. Upon successful registration the block is allocated to you and you can do whatever you want with it, including reselling it. Currently most IP blocks are allocated to ISPs and big corporations. End users are mostly getting addresses from their ISPs.

The allocation works as follows:

ICANN (IANA) -> RIR -> Organization (ISP, corporation)  -> End user

What really happened?

What really happened is IANA's "IPv4 allocation department" is going to be renamed to "IPv6 allocation department". They've done their job with IPv4 - they have delegated all of them to RIR's, they announced it, they had a fierce party. These are the processes behind allocating the last block.

Currently whole free IPv4 address space (not so big - 16 000 000 managed by each of 5 RIR's) is managed by RIR's and ISP's worldwide. Meaning, IPv4 addresses space is going to be really exhausted soon. Not yet, but it's approaching. Still there is nothing to fear. Even if it fully exhausts, the only problem of yours is not getting a pretty 4-octet address. Internet will remain running. Moreover, IPv4 addresses are a subset of IPv6 address. Even if whole Internet except you migrates to IPv6, you'll still be available on an Intenet.

The ICANN's announcement shall be considered as a last warning and a last call for IPv6 migration.