1/31/2011

IOS on Unix (IOU)

source http://evilrouters.net/2011/01/18/cisco-iou-faq/


What is IOU?
From the Cisco Engineering Education web site (a long time ago):
IOS on Unix (IOU) is a fully working version of IOS that runs as a user mode UNIX (Solaris) process. IOU is built as a native Solaris image and run just like any other program. IOU supports all platform independent protocols and features.
What operating systems does IOU run on?
It is my understanding that, initially, IOU was Solaris (SPARC) only. Nowadays, however, there are also builds for OS X and Linux. Similar to dynamips, IOU allows you to build out a network topology on a computer, without the need for physical routers. This is useful for validating designs, proof-of-concept testing, and certification self-study.

Is my system compatible with IOU?
You will need to be running the operating system that your IOU image were built for, obviously. Other than that, there are no special requirements to run IOU. It is not very CPU- or memory-intensive, unlike dynamips.

What skills do I need to run IOU?
You will need to be comfortable on the command-line of your operating system. Knowledge of vi (or other text editors) and shell scripting would definitely be useful. If you’ve only ever used Windows, you might want to look into GNS3 instead.
Warnings

Is this legal?
Usage of IOU outside of Cisco (and trusted partners) is a potentially legal gray area. From an old internal-only Cisco web page:
Cisco IOS on Unix is a tool intended for internal use only. Distribution of IOU images to customers or external persons, or discussion of IOU with customers or external persons, is prohibited. Don’t do it or we’ll have to come and kill you.

Does IOU attempt to call home?
Yes. At startup, IOU images will attempt to make an HTTP POST of some XML data to xml.cisco.com. The data includes your (short) hostname (e.g. not the FQDN), the username of the user running IOU, the version, etc. It appears that xml.cisco.com is not reachable from the Internet, however, so the connection will not be made. This could change in the future, though, so you may want to do the following:
# echo '127.0.0.1 xml.cisco.com' >> /etc/hosts
I can’t find it, will you send me a copy?
No, don’t even ask. Seriously.
Features

What features does IOU support?
Pretty much everything, depending upon the image you’re using. The major exception is layer 2 switching, which L2IOU should take care of.
What version of IOS does it use?
I have seen a few Linux images floating around. One appears to be built on the “ipbase” featureset and another appears to be built with the “adventerpisek9″ featureset.

Are there pagent images?
Yes, in addition to “standard” IOU images, there are pagent images.
Licensing

Do I need a license to use IOU?
It does not seem that older IOU images needed a license to be used, while newer IOU images (including the Linux ones I have seen) do require a valid license.
How do I get a license?
Unfortunately, licenses are only able to be acquired inside of Cisco. An individual license code is generated, based upon the machine’s hostname and IP address.
Will you post your script to “crack” it?
Although I initially said I would, I have decided against this after careful thought. You may do this on your own, if you are so inclined.
Pre-requisites
What is the IOURC file?
The IOURC file is where IOU looks for your license code at startup.
Where does the IOURC file go?
IOU will look for the following:
A file named “iourc” in the current working directory
A file named “.iourc” in the user’s home directory
The file pointed to by the IOURC environment variable
What is the format of the IOURC file?
For licensing, your IOURC file needs to look like this:
[license]
hostname = 4242424242424242;
Replace “hostname” with your computer’s (short) hostname — not the fully-qualified domain name — and “4242424242424242″ with your license code. Make sure the line ends with a semi-colon. Your hostname can be found from the error IOU spits out or by running the following at a command-line:
# hostname -s
What is the NETMAP file?
The network topology map, or NETMAP, file is similar to a .net file for dynagen. It is used for controlling the layout of the “virtual cabling”.
Where does the NETMAP file go?
IOU will look for the following:
A file named “NETMAP” in the current working directory
A file named “.NETMAP” in the user’s home directory
The file pointed to by the NETIO_NETMAP environment variable

What is the format of the NETMAP file?

I’ve posted an example topology and NETMAP file that might be helpful.
Using IOU

How do I run IOU?

Usage: [options]
: unix-js-m | unix-is-m | unix-i-m | ...
: instance identifier (0 < id <= 1024)
Options:
-e Number of Ethernet interfaces (default 2)
-s Number of Serial interfaces (default 2)
-n Size of nvram in Kb (default 16K)
-c Configuration file name
-d Generate debug information
-t Netio message trace
-q Suppress informational messages
-h Display this help
-C Turn off use of host clock
-m Megabytes of router memory (default 64)
-L Disable local console, use remote console
-u UDP port base for distributed networks

How do I stop IOU?

Simply hit CTRL-C and the process will exit.
What is the “wrapper”?
When you run an IOU image, it will stay in the foreground and you’ll be connected to the “console”. This may not always be the desired behavior, especially if you wish to telnet to the console from another host on the network (a la dynamips). The wrapper program can be used to redirect a TCP port to the “console” of the router so that you can do exactly this.

How do I use the wrapper?
$ ./wrapper
Usage: ./wrapper [-v] -m -p -- [iou options]
where is in the range <1024-65550>
all options after the '--' are passed to iou
[-v] Display version

Instead of just running “./imagename ”, you would use something like this:
$ ./wrapper -m ./imagename -p 2000 -- -e0 -s1 -m 64 100
This would tell the wrapper to start the image named “./imagename” and listen ton TCP port 2000. Any options after “–” are passed off to the executable, so in this case our IOU instance would start up with zero ethernet interfaces (“-e0″), one serial interface (“-s1″) — which actually means four in newer images, due to something called “Wide Port Adapters” — and 64 MB of RAM. The “application ID”, which we’ll use to refer to this instance in the NETMAP file, is 100.
The wrapper is most useful in a shell script to start up and background a number of IOU instances at once.
How do I stop IOU when using the wrapper?
If you are using the wrapper and have backgrounded the IOU instance, you’ll need to find the process ID and kill it. The following will find all running instances and kill them:
$ ps -ef | grep [w]rapper | awk '{ print $2 }' | xargs kill
IOUlive
What is IOUlive?
IOUlive is a separate application that allows one to bridge an IOU instance to the real world. This is similar to using dynagen’s NIO_linux_eth descriptor. By connecting an IOU instance to IOUlive, your virtual routers can talk to devices on your physical network.
How do I use IOUlive?
I’ve posted an example topology and NETMAP file that might be helpful.
Errors
What does “UNIX ERR:tcgetattr:Invalid argument” mean?
No idea, but it doesn’t seem to hurt anything. it appears that it can be safely ignored.
I’m getting an error about libcrypto.so.4.
These images were compiled against an older version of the libcrypto shared library than what your Linux distribution may have. For me, creating a symbolic link from /lib/libcrypto.so.0.9.8 to /lib/libcrypto.so.4 took care of the error.
I’m getting a “host not found in iourc file” error.
Fix your IOURC file. See above.
How can I add an NM-16ESW module?
You can’t.
There must be some way to add ATM or NM-16ESW modules!
There’s not.
When running “./wrapper-linux -m i86bi_linux-adventerprisek9-ms …” I get “No such file or directory”.
Provide the path to the IOU image. If it’s in the working directory, refer to it as “./i86bi_linux-adventerprisek9-ms”, for example.
I’ve tried everything and I can’t get it to work. What should I do?
Google “gns3″ and follow a tutorial on how to download and install it. Seriously.
If

1/27/2011

added new book to my collection

Just got another book for my collection. I am not big fen of MPLS/VPLS,however, this topic is mandatory in routing and switching lab.


MPLS Configuration on Cisco IOS Software: A complete configuration manual for MPLS, MPLS VPNs, MPLS TE, Any Transport over MPLS (AToM), and VPLS (Networking Technology) [Paperback]

Paperback: 720 pages
Publisher: Cisco Press; 1 edition (10 Jun 2010)
Language English
ISBN-10: 1587142503
ISBN-13: 978-1587142505

1/23/2011

Understanding STP convergence

I've been trying to find a good explanations on some of the Internetwork Expert tasks and why they decided to use the solutions they used in some of the tasks. I tagged all posts related to the labs with tag "ccienotes". The one bellow is related to IE lab 11; task 1.3.




1) General overview of STP convergence process
2) How STP converges if a directly connected link fails
3) How STP converges when it detects indirect link failure
4) Topology changes and their effect

See more detailed overview at: http://blog.ine.com/wp-content/uploads/2010/04/understanding-stp-rstp-convergence.pdf


STP Convergence in General

As we know, STP protocol follows certain simple procedure to calculate the loop-free subset of the network topology. STP protocol could be compared to RIP in some sense. Both execute a version of Bellman-Ford iterative algorithm, which could be described as “gradient” (meaning it iteratively looks for the optimal solution, selecting the “closest” candidate every time). Every switch accepts and retains only the best current root bridge information. The switch then blocks alternate paths to the root bridge, leaving only the single optimal (in terms of path cost) uplink and continues relaying the optimal information. If a switch learns about a better (“superior”) root bridge than it knows now (e.g. better bridge id, or shorter path to the root), the old information is erased and the new one immediately accepted and relayed. Note that the switch stores the most recent STP BPDUs with every port that receives them. Therefore, for a given switch, there is a BPDUs stored with every root or alternate (blocked port).

There are certain features in STP designed to improve the algorithm stability and ensure the aging out of the old information. Every BPDU contains two fields: Max_Age and Message_Age. The Message_Age field is incremented every time a BPDU traverses a switch (so it might be compared to the hop count). When a switch stores the BPDU with the respective port, it will count the time in seconds, starting from Message_Age and up to the Max_Age. If during this interval, no further BPDUs are received, the current BPDU is wiped out and the port is declared designated. This procedure ensures that the old information is eventually aged out of the topology.

There is one more thing, similar to the “hold-down” feature found in RIP. It is the way in which STP deals with “inferior” BPDUs. The BPDU is considered inferior, if it carries information about the root bridge that is worse than the one currently stored for the port, or the BPDU has longer distance to reach the current root bridge (compare this to RIP’s increase in metric). Inferior BPDUs may appear when a neighboring switch suddenly loses its uplink and claims itself the new root of the topology. By default, every switch should ignore inferior BPDUs, until the currently stored BPDU expires (time=Max_Age – Message_Age). This feature intends to stabilize STP topology in situations where an uplink on some switch flaps, causing the switch to start sending inferior information.

STP convergence in case of directly connected link failure

Consider a switch on Fig 1., with two uplinks – one forwarding (root port, port A) and another blocking (alternate port, port B). Imagine now that the root port fails.



There are two different situations:

1) The switch detects loss of carrier and immediately declares the port dead. Since this was the port with the best information, the switch immediately invalidates it, and selects the next “best candidate” which is the alternate port (Port B) as the new root port. The switch will transition Port B through Listening and Learning states, which takes 2xForward_Time. Therefore, the connectivity is restored in 2xForward_Time.

2) The switch does not detect the loss of carrier (for example, the uplink is fiber connected to a converter or connects through a hub), and thus the port remains up. The root port, however, loses the continuous stream of BPDUs. Thus, the stored BPDU information is no longer updated. Based on the default procedure, it takes time=Max_Age-Message_Age to expire the stored information. After this, the switch considers the BPDU stored with the alternate port, and unblock Port B. It will take another 2xForward_Delay to bring the port to forwarding state. Therefore, the connectivity is resotored in 2xForward_Time + (Max_Age-Message_Age).

If the switch detects loss of carrier on the designated port (Port C) nothing much will happen. Since there are no BPDUs received on this port, the switch will only generate a topology change event (more on that later), but will not block or unblock any other local ports. This event, might, however, affect the downstream switches.

STP Convergence in case of indirect link failure

Consider the topology on Fig 2.



In this case, SW2 has better Bridge ID than SW3, and thus Port D is designated on the segment between SW2 and SW3. SW3 blocks the redundant uplink to via SW3 (Port B) and elects Port A as the root port. Now imagine that SW2 detects loss of carrier on the link connected to SW1 (Port C). The switch will immediately invalidate the best BPDU stored for Port C, and will assume itself the root of the spanning-tree, as there are no other ports receiving BPDUs. SW2 will start advertising BPDUs to SW3, setting the designated and the root bridge to itself in the configuration BPDUs. Those are, by definition, inferior BPDUs, and SW3 will ignore them, as it still hears better information from SW1. SW3 will also keep the previous BPDU associated with Port B for the duration of Max_Age-Message_Age. When this timer expires, SW3 will start considering the inferior BPDUs. Port B will move to Listening state, and SW3 will start relaying SW1’s BPDUs to SW2, as those are superior to SW2’s BPDUs. Now, SW2 would detect the better information on its formerly designated port (Port D) and will cycle the port through Listening and Learning states. Both switches (SW2 and SW3) will eventually move their ports into forwarding states, recovering the connectivity. Therefore, it will take Max_Age-Message_Age + 2xForward_Time to recover from indirect link failure.

The effect of topology changes

Switches forward Ethernet frames based on their MAC address tables (filtering tables) that bind MAC addresses to egress ports. When a change in topology occurs (e.g. a link failure) the MAC address tables may appear to be invalid, as the paths between switches have changed. The switches may eventually re-learn the new information, but it may take considerable time, especially if the traffic is scarce and MAC address aging time is large (5 minutes by default). Based on that, if switch detects a change in the topology (e.g. link going up or down), it should notify all other switches that something has changed. In response to this notification, all switches will reduce their MAC address aging time to Forward_Time (15 secs by default) effectively fastening the aging process.

As we know, topology changes are signaled via special TCN BPDU, which is being sent upstream from the originating switch (the one that detected the change) to the root switch via the root ports. As the root switch hears the TCN BPDU, it will set TCN ACK flag in all its outgoing configuration BPDUs for the duration of Max_Age+Forward_Time. All switches that see this flag, will set their MAC address tables aging time to Forward_Time. Once the switch that originated the TCN BPDU will hear the TCN ACK, it will stop signaling about the topology change.

Now what is the effect of a topology change event? Two major things are impacted:

1) Connectivity. In some cases, it may time additional Forward_Delay seconds to expire the old MAC address information and recover connectivity. This may only happen if the old information persists in some switches, and the frames are black-holed.

2) Network performance. Shortening the MAC address table aging time results in less stable topology. When a switch loses a MAC address, it starts flooding frames for this destination, effectively acting like a hub. If the flow of packets in your network is not intense enough, the switches may start losing MAC address table information, resulting in excessive traffic flooding.

The second issue might become pretty dangerous with high number of topology changes. Excessive flooding might severely impact your network performance. Note, that this issue also pertains to L2 topologies that runs RSTP, as the topology changes are handled in the similar way. In order to reduce the number of topology changes, configure all edge ports in the topology (connected to hosts, IP Phones, servers) as spanning-tree portfast. Portfast ports do not generate TC events when they go up or down.

For more detailed description of topology change notification read the following great article at Cisco’s site:

Understanding Spanning-Tree Topology Changes

Part II of this post will consider UplinkFast and BackboneFast features, and their effect on STP convergence.

PS
We often use the formula Max_Age-Message_Age in this text, to be precise. However, most STP topologies are small enough to ignore Message_Age and assume the value of Max_Age for most calculations, unless Max_Age is artificially set to a very low value.


source:http://blog.ine.com/2009/03/07/understanding-stp-convergence-part-i/
link1: http://www.certificationkits.com/-a-111.html

1/14/2011

INE vol2 lab 10 - task 1

--- cut ---
By default, EIGRP will choose the path with the lowest metric. For this topology, the Point to point link between R1-R3 is 1.536 Mbps, frame-relay link between R2-R3 is 1.28 Mbps and the frame-relay link between R1-R2 is 256Kbps. In this scenario, R1 will choose Path 1 to reach VLAN 26. At this point if we configure the variance of 5, then the traffic will be load balanced between the two paths at a ratio of 80:23 as shown in the output below.


RSRack1R1#sh ip route 164.1.26.6
Routing entry for 164.1.26.0/24
Known via “eigrp 100″, distance 90, metric 3026432, type internal
Redistributing via eigrp 100
Last update from 164.1.12.2 on Serial0/0, 00:00:56 ago
Routing Descriptor Blocks:
* 164.1.13.3, from 164.1.13.3, 00:00:56 ago, via Serial0/1
Route metric is 3026432, traffic share count is 80
Total delay is 40100 microseconds, minimum bandwidth is 1280 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 2
164.1.12.2, from 164.1.12.2, 00:00:56 ago, via Serial0/0
Route metric is 10514432, traffic share count is 23
Total delay is 20100 microseconds, minimum bandwidth is 256 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1

To achieve a 5:1 ratio, we can modify the metric through R2 to be 5 times the metric through R3. But before we can do that, let’s figure out how the metric is being calculated in the first place.

Metric = [K1*BW+(K2*BW)/256-Load)+K3*Delay]*[K5/(Reliability+K4)]

As we know, by default K1 and K3 equals 1 while all the other values are ZERO. So we can modify the above equation as follows:

Metric_R3 = (10^7/BW+Delay/10)*256
Metric_R3 = (10^7/1280+40100/10)*256
Metric_R3 = 3026432

In order to get the 5:1 ratio, we must increase the metric through R2 to be 5 times that of the metric through R3. This is how we can get the value of the DELAY through

R2.
Metric_R2 = Metric_R3 * 5
(10^7/BW+Delay/10)*256 = (10^7/BW+Delay/10)*256*5
(10^7/256+Delay/10) = (10^7/1280+40100/10)*5
(39062.5+Delay/10 = (7812.5 + 4010) * 5
Delay/10 = 59112.5 – 39062.5
Delay = 20050 * 10
Delay = 200500

Looking through the routing table, we can see that we already have a delay of 100 microseconds to reach VLAN26.


http://www.ccietalk.com/2008/09/21/eigrp-unequal-cost-load-balancing

and

http://blog.ipexpert.com/2010/05/03/eigrp-unequal-cost-load-balancing/

however, to get what should be the delay it's pretty easy

r2_delay = (10 ^ 7/min-bw-via-R3 + (delay-(r1-r3) + delay(r3+r2) ) /10 )*5