When we study IPSec, we know Mr. Diffie and Mr. Hellman invented a method in year 1976 that is the core of Internet Key Exchange (IKE) to create mutually shared secret. We also have to specify and configure DH Group Number in ISAKMP policy sets (crypto-map in Cisco IOS).

A.M. Turing Award Logo. Captured on ACM Official Website.

I am not going to dig in the details about the mathematics behind Diffie-Hellman method. I just want you to know Mr. Diffie and Mr. Hellman receive Turing Award 2015 together.

Photo of Whitfield Diffie, captured on ACM Official Website.

Photo of Martin E. Hellman, captured on ACM Website.

A.M. Turing Award of Association for Computing Machinery (ACM) is the highest honorable award in computer science just like Nobel Prize for other fields of science.

This was released on March 1, 2016.

In case you want to know more about Diffie-Hellman method, I found one video on YouTube is quite helpful for you to understand it more.

Have fun!

I came across a new RFC 7772: “Reducing Energy Consumption of Router Advertisements”. I want to share my learnings after reading this RFC.

Internet Engineering Task Force (IETF) Logo, captured on Wikipedia.

I intentionally mentioned “iPhone” at the subject to have your attention. Actually, the whole discussion applies to any mobile devices with limited battery capacity, such as smart phones and tablet computers.

It is quite obvious mobile devices will consume more power while awake than asleep. The question is how serious this problem is?

Although the authors of this RFC did not mention how they got these numbers, I believe the numbers must be typical and derived from actual lab measurements.

While asleep, a mobile device would consume 5 mA of current. While awake, it would consume 40 times more on the other hand. That is 200 mA.

A single Router Advertisement (RA) will wake up the target mobile device. A single multicast RA to all hosts will wake up ALL the mobile devices attached to the same subnet.

Remember, the power capacity of mobile devices are so limited. The more power consumption we can save, the more battery time we will have for every mobile devices attached to the same IPv6 subnet.

Here I want to emphasize on the word “reasonable”. To keep IPv6 working, we do need RAs to push and refresh network information to mobile devices. If nothing changed at the network, why keep sending so many unnecessary RAs just to wake mobile devices up and waste battery capacity?

Here is a reasonable goal: 2% of idle power consumption.

Assume we want to achieve the goal: we do not want RAs to consume more than 2% of idle (sleeping) power consumption of every mobile device. After some calculations, we know the reasonable frequency for RAs is no more than 7 RAs per hour.

Here is the calculation.

A typical wakeup high power consumption surge mentioned in this RFC would last for 250 ms. That is, the wakeup power consumption is triggered by single RA is:

{The battery capacity consumed for single RA wakeup in mAH} = 200 mA x 250ms/1 hour = 200 x 250/3,600,000 = 0.0138888… ~= 0.014 mAH.

To calculate the idle (asleep) power consumption, I assume the device keeps asleep for the whole hour. This is the total budget for me to meet.

{2% of idle (asleep) power consumption of battery capacity for an hour in mAH} = 2% x 5mA x 1 Hour = 0.02x5x1 mAH = 0.1 mAH.

{Reasonable number of wakeups without exceeding the budget} = 0.1 / 0.014 ~= 7

I have to be honest I did not expect this number to be this small. The default IPv6 RA interval is 200 seconds on Cisco IOS routers. That is equivalent to 18 RAs per hour. I believe configuring the interval to roughly 600 seconds would be a better idea.

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipv6/command/ipv6-cr-book/ipv6-i3.html#wp3911380069

The default interval between IPv6 RA transmissions is 200 seconds.

Note: the lifetime of each RA should be 5 to 10 times of this interval. This is also mentioned in this RFC as roughly 45~90 minutes.

I will just focus on the network side.

To implement the recommendations of Section 5.1.1 and 5.1.2 of this RFC, I found one interesting command on Cisco’s web site.

The command is:

interface E0/0

 ipv6 nd ra solicited unicast

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipv6/command/ipv6-cr-book/ipv6-i3.html#wp5031733970

Large networks with a high concentration of mobile devices might experience like battery depletion, when solicited Router Advertisement messages are multicast . Use the ipv6 nd ra solicited unicast to unicast solicited Router Advertisement messages extend battery life of mobile device in the network.

Most of the IPv6 end devices could send out Router Solicitation even when their own link-local addresses are not determined yet. In that case, the replying RAs to such Router Solicitations would become destined to multicast address of all hosts. After enabling this feature, the router would ignore all such Router Solicitations. End devices can still get their global IPv6 prefix because after determination of their own link-local addresses, they can send out RS again and at this moment the router will respond to them because these RSs are sourced with unicast addresses.

For stable network, we should keep the RA interval as large as possible to save more power on mobile devices. Here is a sample configuration on Cisco IOS Routers.

interface ethernet 0/0

  ipv6 nd ra interval 600

  ipv6 nd ra lifetime 2700

Here I use 45 minutes (2700 seconds) as a reasonable RA lifetime.

We should consider increasing the frequency ONLY when we are changing network topology or renumbering address. For most of the time, we should keep below 7 RAs per hour as reasonable configuration.

Zhuifen Station (追分車站) (Google Maps). Taichung City, Taiwan.

Increasing RA frequency indeed helps to push network changes much faster to all end devices. For devices without battery capacity concerns such as desktop computers, this advantage would outweigh the power consumption.

My personal suggestion is we should put limited battery capacity mobile devices in separate IPv6 subnets, and enable only to such subnets with the recommendations discussed in this post.

I just want to make sure you have known this news and updated your Cisco ASA OS already.

Cisco announced a "critical" vulnerability of Cisco ASA OS and released patched OS for them at the same time. Hackers could make use of this vulnerability to gain control of your Cisco ASA.

The first fixed version of ASA OS to fix this problem.
Screen captured on Cisco's web site.

Vulnerable Products

Cisco ASA Software is affected by this vulnerability if the system is configured to terminate IKEv1 or IKEv2 VPN connections.

This includes the following:

Cisco ASA Software can be downloaded from the Software Center on Cisco.com by visitinghttp://www.cisco.com/cisco/software/navigator.html.

The full details about this vulnerability and patched OS is on Cisco's official web site:

Cisco ASA Software IKEv1 and IKEv2 Buffer Overflow Vulnerability (CVE-2016-1287)

I have learned one lesson several years ago. Around 2003, I secretly installed a SQL server right in my house. I thought I was the only one who knew I have installed that SQL server, and I was the only one who knew my public IP address. I put that server at public Internet side so I can get back to it any time I want.

However, I was wrong. Within just 12 hours, hackers found and broke into my SQL server.

The key lesson I have learned is, if I tried again to put some hardware or software with vulnerability unfixed at public Internet, the survival time for it would be far less than 12 hours. Remember, it was only year 2003.

Go patch up your Cisco ASA OS ASAP!

I saw this Cisco IOS hidden command show ip ospf route for OSPF in this post. I tried to create a running example for myself so I can learn more about this hidden command.

【Output at R4】

R4#show ip ospf route

            OSPF Router with ID (1.0.0.4) (Process ID 1)

                Base Topology (MTID 0)

    Area 4

    Intra-area Route List

*   4.0.1.0/24, Intra, cost 64, area 4, Connected

      via 4.0.1.4, Serial1/0

*   4.0.2.0/24, Intra, cost 64, area 4, Connected

      via 4.0.2.4, Serial1/1

    Intra-area Router Path List

i 1.0.0.2 [64] via 4.0.2.2, Serial1/1, ABR, Area 4, SPF 8

i 1.0.0.1 [64] via 4.0.1.1, Serial1/0, ABR, Area 4, SPF 8

    Inter-area Route List

*>  3.0.1.0/24, Inter, cost 128, area 4

      via 4.0.1.1, Serial1/0

*>  3.0.2.0/24, Inter, cost 128, area 4

      via 4.0.2.2, Serial1/1

*>  3.0.0.3/32, Inter, cost 129, area 4

      via 4.0.2.2, Serial1/1

      via 4.0.1.1, Serial1/0

R4#

R4#show ip ospf database

            OSPF Router with ID (1.0.0.4) (Process ID 1)

                Router Link States (Area 4)

Link ID         ADV Router      Age         Seq#       Checksum Link count

1.0.0.1         1.0.0.1         632         0x80000006 0x00F099 2

1.0.0.2         1.0.0.2         946         0x80000008 0x000D76 2

1.0.0.4         1.0.0.4         1512        0x80000007 0x006E64 4

                Summary Net Link States (Area 4)

Link ID         ADV Router      Age         Seq#       Checksum

3.0.0.3         1.0.0.1         632         0x80000003 0x00BD34

3.0.0.3         1.0.0.2         682         0x80000003 0x00B739

3.0.1.0         1.0.0.1         632         0x80000003 0x00C62E

3.0.1.0         1.0.0.2         946         0x80000003 0x004370

3.0.2.0         1.0.0.1         632         0x80000003 0x003E75

3.0.2.0         1.0.0.2         946         0x80000003 0x00B53D

R4#

【Output at R1】

R1#show ip ospf route

            OSPF Router with ID (1.0.0.1) (Process ID 1)

                Base Topology (MTID 0)

    Area BACKBONE(0)

    Intra-area Route List

*   3.0.1.0/24, Intra, cost 64, area 0, Connected

      via 3.0.1.1, Serial1/0

*>  3.0.2.0/24, Intra, cost 128, area 0

      via 3.0.1.3, Serial1/0

*>  3.0.0.3/32, Intra, cost 65, area 0

      via 3.0.1.3, Serial1/0

    Intra-area Router Path List

i 1.0.0.2 [128] via 3.0.1.3, Serial1/0, ABR, Area 0, SPF 3

    Area 4

    Intra-area Route List

*   4.0.1.0/24, Intra, cost 64, area 4, Connected

      via 4.0.1.1, Serial1/1

*>  4.0.2.0/24, Intra, cost 128, area 4

      via 4.0.1.4, Serial1/1

    Intra-area Router Path List

i 1.0.0.2 [128] via 4.0.1.4, Serial1/1, ABR, Area 4, SPF 9

R1#

R1#show ip ospf database

            OSPF Router with ID (1.0.0.1) (Process ID 1)

                Router Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Link count

1.0.0.1         1.0.0.1         703         0x80000004 0x00CCC2 2

1.0.0.2         1.0.0.2         1019        0x80000006 0x00E89F 2

1.0.0.3         1.0.0.3         617         0x80000008 0x00368C 5

                Summary Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum

4.0.1.0         1.0.0.1         703         0x80000003 0x00B93A

4.0.1.0         1.0.0.2         1534        0x80000004 0x00347D

4.0.2.0         1.0.0.1         1729        0x80000004 0x002F82

4.0.2.0         1.0.0.2         1019        0x80000003 0x00A849

                Router Link States (Area 4)

Link ID         ADV Router      Age         Seq#       Checksum Link count

1.0.0.1         1.0.0.1         703         0x80000006 0x00F099 2

1.0.0.2         1.0.0.2         1019        0x80000008 0x000D76 2

1.0.0.4         1.0.0.4         1585        0x80000007 0x006E64 4

                Summary Net Link States (Area 4)

Link ID         ADV Router      Age         Seq#       Checksum

3.0.0.3         1.0.0.1         703         0x80000003 0x00BD34

3.0.0.3         1.0.0.2         755         0x80000003 0x00B739

3.0.1.0         1.0.0.1         703         0x80000003 0x00C62E

3.0.1.0         1.0.0.2         1019        0x80000003 0x004370

3.0.2.0         1.0.0.1         703         0x80000003 0x003E75

3.0.2.0         1.0.0.2         1019        0x80000003 0x00B53D

R1#

【My Observation】

From my observation, this command is helpful when I am not familiar to other OSPF commands such as “show ip ospf database”. This command provides more readable information about ip prefixes themselves, instead of cryptic link state objects.

Because this is a hidden command, do not rely on it when you are preparing for exams.

【My Configurations】

! R1

hostname R1

interface Loopback0

 ip address 1.0.0.1 255.255.255.255

!

interface Serial1/0

 ip address 3.0.1.1 255.255.255.0

 no shutdown

!

interface Serial1/1

 ip address 4.0.1.1 255.255.255.0

 no shutdown

!

router ospf 1

 network 3.0.0.0 0.0.255.255 area 0

 network 4.0.0.0 0.0.255.255 area 4

!

! R2

hostname R2

!

interface Loopback0

 ip address 1.0.0.2 255.255.255.255

!

interface Serial1/0

 ip address 3.0.2.2 255.255.255.0

 no shutdown

!

interface Serial1/1

 ip address 4.0.2.2 255.255.255.0

 no shutdown

!

router ospf 1

 network 3.0.0.0 0.0.255.255 area 0

 network 4.0.0.0 0.0.255.255 area 4

!

! R3

hostname R3

interface Loopback0

 ip address 1.0.0.3 255.255.255.255

!

interface Loopback1

 ip address 3.0.0.3 255.255.255.0

!

interface Serial1/0

 ip address 3.0.1.3 255.255.255.0

 no shutdown

!

interface Serial1/1

 ip address 3.0.2.3 255.255.255.0

 no shutdown

!

router ospf 1

 router-id 1.0.0.3

 network 3.0.0.0 0.0.255.255 area 0

!

! R4

interface Loopback0

 ip address 1.0.0.4 255.255.255.255

!

interface Serial1/0

 ip address 4.0.1.4 255.255.255.0

 no shutdown

!

interface Serial1/1

 ip address 4.0.2.4 255.255.255.0

 no shutdown

!

router ospf 1

 network 4.0.0.0 0.0.255.255 area 4

!

Skin-removed Persimmons are to be air-dried. This is a traditional Hakka sweets.
Photoed at this farm (味衛佳觀光果園) in Hsinpu Township, Hsinchu County, Taiwan.

We all know adding redundant supervisors/CPUs to any given system, we can increase the uptime for that system. With In-Service Software Upgrade (ISSU), Cisco hardware even allow us to upgrade the operating system software on-the-fly without stopping the whole system.

Flowers of Cassia fistula was blooming together in southern Taiwan starting from mid-May.
This photo was taken around this location in Baihe District of Tainan City, Taiwan.

An interesting question might be asked. Does Cisco hardware keep track of system uptime even upon supervisor/CPU failover events? And how to display the system uptime, in addition to individual supervisor/CPU uptime?

I spent some time and I summarize my findings in this post.

Basically the command “show system uptime” is for NX-OS to display system uptime for both Nexus 7000 and MDS 9500

For Cisco MDS 9500, the official web site gives me an explaining example.

http://www.cisco.com/c/en/us/td/docs/switches/datacenter/mds9000/sw/4_1/configuration/guides/cli_4_1/clibook/ha.html#pgfId-1120592

switch# show system uptimeSystem start time: Fri Aug 27 09:00:02 2004
System uptime: 1546 days, 2 hours, 59 minutes, 9 seconds
Kernel uptime: 117 days, 1 hours, 22 minutes, 40 seconds
Active supervisor uptime: 117 days, 0 hours, 30 minutes, 32 seconds

 

For Nexus 7000, the following link tell us “show system uptime” is a legal command for Nexus 7000.

http://docwiki.cisco.com/wiki/Cisco_Nexus_7000_Series_NX-OS_Troubleshooting_Guide_--_Troubleshooting_Installs,_Upgrades,_and_Reboots

However, the screen capture is not helpful for me to clarify system uptime and supervisor uptime.

I found another more meaningful example here.

http://ccie5851.blogspot.tw/2011/01/joys-of-issu-on-nexus-7000.html

cmhlab-dc2-sw2-otv1# show system uptimeSystem start time: Tue Oct 26 19:46:38 2010System uptime: 89 days, 6 hours, 56 minutes, 26 secondsKernel uptime: 0 days, 0 hours, 29 minutes, 16 secondsActive supervisor uptime: 0 days, 0 hours, 19 minutes, 56 secondscmhlab-dc2-sw2-otv1#

The command for Cisco IOS platforms, such as Catalyst 6500 and 4500, is “show redundancy”.

http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/71585-cat6k-red-supeng-swimg-upg.html

Router#show redundancy

Redundant System Information :

------------------------------

Available system uptime = 34 minutes

Switchovers system experienced = 1

Standby failures = 0

Last switchover reason = unsupported

Hardware Mode = Duplex

Configured Redundancy Mode = Stateful SwitchOver - SSO

Operating Redundancy Mode = Stateful SwitchOver - SSO

!--- This verifies that software has set the redundancy mode

!--- back to SSO after the software upgrade.

Maintenance Mode = Disabled

Communications = Up

Current Processor Information :

-------------------------------

Active Location = slot 6

Current Software state = ACTIVE

Uptime in current state = 4 minutes

Image Version = Cisco Internetwork Operating System Software

IOS (tm) MSFC2A Software (C6MSFC2A-IPBASE_WAN-M), Version 12.2(18)SXF6,

RELEASE SOFTWARE (fc1)

Technical Support: http://www.cisco.com/techsupport

Copyright (c) 1986-2006 by cisco Systems, Inc.

Compiled Mon 18-Sep-06 17:17 by tinhuang

BOOT = bootflash:c6msfc2a-ipbase_wan-mz.122-18.SXF6.bin,1;

CONFIG_FILE =

BOOTLDR =

Configuration register = 0x2102

Peer Processor Information :

----------------------------

Standby Location = slot 5

Current Software state = STANDBY HOT

Uptime in current state = 3 minutes

Image Version = Cisco Internetwork Operating System Software

IOS (tm) MSFC2A Software (C6MSFC2A-IPBASE_WAN-M), Version 12.2(18)SXF6,

RELEASE SOFTWARE (fc1)

Technical Support: http://www.cisco.com/techsupport

Copyright (c) 1986-2006 by cisco Systems, Inc.

Compiled Mon 18-Sep-06 17:17 by tinhuang

BOOT = bootflash:c6msfc2a-ipbase_wan-mz.122-18.SXF6.bin,1;

CONFIG_FILE =

BOOTLDR =

Configuration register = 0x2102

This is for Catalyst 4500. However, the screen capture is not good.

http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst4500/12-2/25ew/configuration/guide/conf/RPR.html

The command for ASR 9000 is again “show redundancy”.

http://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k_r4-2/rommon/configuration/guide/b_rommon_cg_42asr9k/b_rommon_cg_42asr9k_chapter_0101.html#ID2119

RP/0/RSP1/CPU0:router# show redundancy

Redundancy information for node 0/RSP1/CPU0:

==========================================

Node 0/RSP1/CPU0 is in ACTIVE role

Partner node (0/RSP0/CPU0) is in STANDBY role

Standby node in 0/RSP0/CPU0 is ready

Standby node in 0/RSP0/CPU0 is NSR-ready

Reload and boot info

----------------------

A9K-RSP-4G-HDD reloaded Thu Dec 11 14:50:47 2008: 2 hours, 41 minutes ago

Active node booted Thu Dec 11 17:15:15 2008: 16 minutes ago

Last switch-over Thu Dec 11 17:19:29 2008: 12 minutes ago

Standby node boot Thu Dec 11 17:28:56 2008: 3 minutes ago

Standby node last went not ready Thu Dec 11 17:30:02 2008: 2 minutes ago

Standby node last went ready Thu Dec 11 17:31:02 2008: 1 minute ago

There has been 1 switch-over since reload

RP/0/RSP1/CPU0:router#

I also found one example for Cisco ASA.

For Cisco ASA, the hardware itself does not provide system-wide redundancy. It only provides cluster-wide (pair-wide) redundancy. Here is the “show version” command output example of Cisco ASA, which explains Cisco ASA also keeps track of cluster-wide uptime in addition to single hardware box uptime.

https://supportforums.cisco.com/discussion/11291816/failover-cluster-uptime

asa-firewall> sh ver
Cisco Adaptive Security Appliance Software Version 8.2(1)
Compiled on Tue 05-May-09 22:45 by builders
System image file is "disk0:/asa821-k8.bin"
Config file at boot was "startup-config"
asa-firewall up 2 days 22 hoursfailover cluster up 1 year 79 daysHardware:   ASA5550, 4096 MB RAM, CPU Pentium 4 3000 MHz

Why do I have to write down this post? If I can capture the system-wide uptime (or cluster-wide uptime) in addition to single hardware uptime, I have something much more persuading to buying decision makers because the traffic is not stopped at all right here at this system (or cluster) for such a long time.

By the way, what is the “longest” system or cluster uptime you have ever seen before? Please share your experiences with me here at the comments area!

Thank you so much!