My experience on upgrading the IOS of my Cisco 2500s

For the last few weeks, I've been adding routers and switches to my watch list on eBay. Some of them were Cisco 2500s that had 16D/16F, basically maxed out RAM and flash. At first, it was cheaper than buying the 16D and 16F by themselves. However, as we all know, it is an auction so it'll go up. The price went up so high that it was cheaper to just grab 16MB DRAM and 8MB flash by themselves, the routers already had 8MB flash in them so I just need one more stick per router. That being said, I grabbed four 16MB DRAM and 8MB flash sticks.

You might be asking yourself, why would anyone still want to invest on these ancient routers? Well, I am actually preparing for the labs that I will be doing for the CCIE R&S lab exam and since I am an old school guy, I will be using real devices instead of using Dynagen/Dynamips. In addition to that, I am trying to follow INE's topology as much as possible.

Anyways, let's skip all the stories and get on with the topic. Upgrading IOS is not a very hard task. I do this at work all the time. Though, I do this via WAN and instead of the regular TFTP, we use FTP. I started upgrading my Cisco 2511 and it was what I expected but it gave me some prompts that I've never seen before. Then again, it wasn't such a big deal since it was very intuitive anyways. Since 2500s do not hold more than 16MB of flash, I had to delete the IOS. As I've said, it went through fine but did encounter some new prompts. After upgrading the IOS, I went ahead and tried upgrading the IOS on my 2520 (2) and 2514 (1). What a mess! I couldn't delete the IOS from flash because it was marked as Read-only. I was like, WTF? Now what do I do? Well, of course I am going to use my Google skills. c",) Anyway, I found out that there are bootstrap versions out there that don't let you delete the IOS if you booted the router on the regular mode.

In order for you to delete the IOS from the flash is by booting to ROMmon, looks like rommon1> prompt, or by boot image, looks like Router (boot)> prompt. For whatever reason, I couldn't go to ROMmon, it defaults to the Boot ROM (I believe that's what it is called). I am not familiar with that OS so I was like now what, AGAIN! If you haven't seen what the prompt looks like, it was just showing you ">" (greater than symbol). After spending time searching the world wide web, I was able to find some information about it. Basically, you had to issue "i" and then when that's done you issue "b". However, those didn't help! It booted to regular mode and didn't allow me to delete the flash. I went back again to search and found out that you need to set the config-reg to 0x100. So I did that and did the same thing as well, the "i" and the "b". It finally went to the prompt that I wanted, boot image - Router (boot)>. Boot image is pretty similar to regular boot. Honestly, I don't remember all the differences about these prompts anymore. It was covered in 640-801 materials but I wasn't interested on going back to read about it since it was already 12AM when I was doing this! So anyways, I was able to load the right IOS that I want for it. All booted fine and working great when I tested it. Of course I changed the config-reg back to 0x2102! c",)

These experiences are not in any Cisco Press books, so I suggest you to work on real devices not just simulator or emulator if you're still not in the field. Though, it can get very expensive. To be honest with you guys/girls, I've spent more than $1,000 already on my lab and it is still not complete.

Written by: Andr01d
"I know nothing except the fact of my ignorance" - Socrates

New technology should simplify things, not complicate them

An old-school guy like me adheres to an old-school mantra on network and system administration: "If it 'ain't broke, don't fix it"

Rookie Netads and Sysads tend to be too excited when new technologies are available on the market. Under the impression that it will make their jobs and responsibilities easier, they jump to the bandwagon. First they sign up for a trial, then they extend the trial and eventually purchasing the product in the end. "Hey boss, this software/product will cut off costs and man-hours of working on _______ manually, blah, blah"

In other words, please buy this software for me. But sometimes we fail to put into consideration that introducing a new technology on our network most of the time tends to complicate things, especially in troubleshooting when problems start to surface.

There's this company based in the East Coast. They have a corporate size network, with a couple of WAN connections to connect to their regional offices and remote employees. Things were doing good until after they implemented redundancy across all routers and Layer 3 devices on their network. How ironic that they started experiencing major issues when they tried to implement a technology that address the availability of their network.

These guys implemented a technology that they fail to test first on at least half of the nodes/workstations on their network. They fell prey to the "herd mentality". Hey, customer ABC and XYZ are doing it, we should to, that type of herd mentality in IT. And hearing this directly coming from their "seasoned" IT Director saddens me.

Again, I am big fan of keeping things simple. A simple network consumes less resources in all aspects of your business or organization. From technical to administrative. If you want redundancy in your network, study the technology t first before implementing it. Try to look beyond brochures, case studies and white papers. Not all networks are the same despite what those "Best Practices" guide say.

Cofiguring ACLs on Huawei

First of all, why ACLs? Did it have to be specific? Not really, it's just that I find configuring ACLs on Huawei a bit more complex or should I say. .structured. More complex in a sense that if you know how to configure ACLs on Cisco, you might find configuring it on Huawei a bit weird because it's kind of like the way route-map or a QoS policy is configured in Cisco. But don't get me wrong its not that hard, really, all I'm saying is that its pretty similar as to the way those are configured but it doesn't necessarily mean its hard. It only takes a little bit of time to understand the equivalents specially for guys who had their basics the Cisco way just like me.

Now if you're already good at Cisco ACLs then this might just be a piece of cake for you to understand. There's just a little bit more to it but its pretty easy to digest. First up, there's three new terms you would need to know – Traffic Classifier, Traffic Behavior & Traffic policy. Now let me introduce you to these terms (actually they're already the exact commands lol).

Traffic Classifier – This where we match/catch our traffic using our acl. Under this command we specify the acl no. we would like to filter

Traffic Behavior – Under this command we tell how our filtered traffic will be treated e.g. permit/deny.

Traffic Policy – As the name tells this will be our actual policy. You may think of this as a route-map or a QoS policy as I have mentioned. Under this command you will specify what traffic are we interested in and what are we going to do with it.

Does it all come together now? Yes we will calling the Traffic Classifier and Traffic Behavior we configured to basically tell our policy WHAT traffic are we going to look at and HOW are we going to treat it.

Now that we are already familiar with the terms lets get to know how ACLs are done. Its almost the same as in Cisco however with a few better syntaxes.

First create the ACL. Now in Cisco if standard ACLs are from 1-99, in Huawei they are 2000-2999. They are also termed as basic ACLs. And for extended ACLs which is 100-199 in Cisco, in Huawei its 3000-3999 and referred to as advanced ACLs. The command for these are as follows:

[Router]acl acl-number

As for our first example lets have a basic ACL. Under this command you may already start entering the ACL lines, or rules rather. The syntax will be:

rule rule-number {permit | deny} source source-ip source-mask destination destination-ip destination-mask

Lets say we would want to deny 110.100.174.0/24 and 110.100.175.0/25 from getting to a server 115.128.85.93.

acl 2100

rule 1 permit source 110.100.174.0 0.0.0.255 destination 115.128.85.93 0

rule 2 permit source 110.100.175.0 0.0.0.255 destination 115.128.85.93 0

Now notice how easy it is know what's going on with this ACL? The source and destination addresses are explicitly defined as compared to Cisco ACLs. And also there's a bit of difference when it comes to specifying a single host. In Cisco when its a single host then you specify the parameter host, and then its IP address. Here we specify the address then specify in its mask that it is a host but instead of putting in 0.0.0.0 instead you only put in 0 which is much shorter, to understand that its a host.

How about we make our example into an advanced ACL. Lets say we just want to deny ssh access to this server. Also let’s do some summarization just for example. The syntax would be as follows:

acl 3100

rule 1 permit tcp source 110.100.174.0 0.0.1.255 destination 115.128.85.93 0 destination-port eq 22

As you can see its not that hard to figure out. The options are well defined and you won’t go wrong unless you put in the wrong values or mistyped it. But look..haven’t you guys noticed? I’ve been putting in permit rules wherein the purpose of our ACL is to deny/block. This where the 3 commands we discussed earlier comes in. So to complete our configuration lets go through those one by one.

traffic classifier c300

if-match acl 3100

traffic behavior b300

deny

traffic policy p300

classifier c300 behavior b300

As you can see above we have configured traffic classifier c300 to match our acl (acl 3100). Please note that the words in italics (e.g.c300) are just names and I just labeled them for easy identification. For our traffic behavior b300 we specified it to deny. So whatever we match with this behavior will be blocked. Finally for our traffic policy p300 we called on our traffic classifier and traffic behavior to complete our overall policy. In essence, what this policy will do is DENY whatever is permitted or matched in our classifier, in this case c300 and so which ever interface we apply this to will start filtering traffic according to this policy.

So to finalize the whole configuration let's put them altogether and apply it to an interface, plus I'll show you how its done from that start!

Telnet into Huawei device

super

system-view

acl 3100

rule 1 permit tcp source 110.100.174.0 0.0.1.255 destination 115.128.85.93 0 destination-port eq 22

quit

traffic classifier c300

if-match acl 3100

traffic behavior b300

deny

traffic policy p300

classifier c300 behavior b300

quit

interface GigabitEthernet0/1/1

traffic-policy p300 inbound

return

save

Let me give you the equivalent of the unfamiliar commands here in Cisco

super – enable

system-view – config terminal

quit – exit

return – end

save - write

See? It's not that bad right? If you already know Cisco its not hard to learn Huawei or vice versa.

Note: There's actually an old way to this. Previously Huawei uses the same way how Cisco uses ACLs (the basic way) however in newer devices this is already the standard.

And does this configuration remind you of route-maps? Yes it did not take me that long to figure out ACLs in Huawei as they're not that far from the concepts which we have in Cisco. Yes I am aware of the controversy which happened between them but then its not really our problem. I guess one important thing to keep in mind here is that its not just a Cisco world out there. I am experiencing that first hand in my current company and really you got to be open into handling devices from other vendors and embracing this truth. We even have Linux routers to add to that and its running OSPF(Zebra), handling PPPoE sessions and all that. I'd be grinning if someday we'll eventually be ordering hardware from Juniper. Be a cross-platform Network Engineer if you can because you'll never know what you may encounter at work. Until my next topic hope you guys picked up something:)

IPv6 address types

One of the topics to focus on in IPv6 is the addressing part, greatly because its a totally new addressing scheme. As compared to IPv4 which has 32 bits, the IPv6 address is 128 bits long and is in hexadecimal format (0-9 A-F) or four bits per digit.

0000:0000:0000:0000: 0000:0000:0000:0000

NOTE: In IPv6, due to the length of the address itself there were rules that were made to somehow shorten the address into a bit more human-readable format. These two rules are zero compression and leading zero compression.

zero compression - in case there are consecutive zeros within the address you may replace it by putting in double colons (::). However you can only do this once within an address as the device would have no way of determining how many zeros are there in each '::' theres is if there were more than one. For an example 2001:0005:0000:0000:0201:50FF:FE68:AF50 could be compressed as 2001:0005::0201:50FF:FE68:AF50. The zeros in between were omitted and was replaced by ::.

leading zero compression - for any leading zeros you can go ahead and exclude them to make the address a bit more shorter. However in case there are all zeros within colons you must leave at least one zero to specify that it is all zeros before that hex digit. Using our previous example our address would look like 2001:5:0:0:201:50FF:FE68:AF50.

We could use these two rules simultaneously. And therefore our fully compressed IPv6 address would be 2001:5::201:50FF:FE68:AF50.

One major difference also is there is no ‘class’ system here (class A, B, C, D). In IPv6, we more refer to them as types. Now lets go through them one by one.

Unicast Address – used for sending to one host or interface. Currently there are two types of IPv6 unicast addresses:

Global Unicast – formerly known as Global Aggregatable Unicast address but the ‘Aggregatable’ has now been omitted in the latest RFC. Global Unicast is equal to IPv4s public or Internet address. Knowing this we can understand that this address type will be the ones we use to communicate to the Internet. These addresses composes of the global routing prefix (as of today IANA is assigning numbers that starts with 2000::/3) plus the 64-bit Interface Identifier (EUI-64 format) which we will discuss later.

Link-Local Unicast – are the addresses our devices use to communicate with other nodes on the same local network even without a global unicast address. You may compare this type of address to the layer 2 address or data-link layer address we have in IPv4. Note that these address are autoconfigured on the interfaces using FE80::/10 prefix plus the EUI-64 format Interace Identifier, which again will be discussed later.

Anycast Address – an anycast address is a global unicast address assigned to two or more devices. Packets coming from nodes who wants to access this address will be routed to the closest active device with the anycast address. This is determined by the routing protocol metric or rather the router which receives this packet then routes to the closest one to it.

Multicast Address – a multicast address identifies a group of interfaces. Traffic sent to these addresses are sent to all of the interfaces in that group. Mulicast in IPv6 is not that different in IPv4, its just that in IPv6 only multicast exists. There is no such thing as broadcast in IPv6 (except for some that is specifically addressed to interfaces that maybe within one segment or layer 2 domain like in IPv4). Interfaces may belong to many multicast groups simultaneously. Multicast addresses are addresses that start with FF00::/8. All IPv6 multicast address are within this prefix and so when you see an address that starts with this you will know that this is an IPv6 Multicast address.

Now lets get to the Interface Identifier as promised. Knowing how this address is made is important as you don’t really get to configure this since this is autoconfigured already on the IPv6 enabled interface.

Interface Identifiers (IDs) – are addresses used to identify a unique interface on a link and are sometimes referred to as the ‘host portion’ of the IPv6 address. These address are 64-bits long and is can be dynamically created based on the data-link layer address of the interface. IPv6 Interface IDs are determined depending on the specific data-link layer type of interface there is. In this topic we will discussing Ethernet Interface IDs as this is what we commonly use almost everywhere (even on non-ethernet mediums). Now we can determine its ID based on its MAC address, using a format called Extended Universal Identifier 64-bit (EUI-64). The EUI-64 format Interface ID is derived from the 48-bit MAC address by inserting the hexadecimal digits FFFE between the Organizationally Unique Identifier (OUI), which is the upper three bytes, and the vendor code, which is the lower three bytes of the MAC address. I hope you guys could still remember your MAC addressing fundamentals back in the days because yes it back and used a lot in the IPv6 world. In addition to this the 7^th bit in the first byte in the resulting Interface ID, which is the Universal/Local (U/L) bit is always set to binary 1. The U/L bit indicates whether the Interface ID is locally unique on the link or universally (globally) unique. IDs derived from universally unique MAC addresses are assumed to be globally unique so no worries if your already using the Burn In Address of your Interfaces. The 8^th bit on the first byte then is the Individual/Group (I/G) bit for managing multicast groups, it is not altered.

As you can see in this example it is pretty easy to understand how an IPv6 Interface ID is composed. You just have to remember two steps. First insert FFFE in between the 48 bit MAC address (in between the two sets of three bytes or 24bits) and then the 7^th bit is set to 1. MAC addresses almost always starts with 00 as of yet (I haven’t seen one which isn’t or at least not that I can remember at this time) so you will always see this as ‘02’ (0000 0010).

Now going back to the Glocal Unicast and Link-Local Unicast where we used this Interface IDs. For Global Unicast for example we have a IPv6 public address assigned by APNIC 2001:1F14::/32 (/32s are assigned to ISPs). We now then assign a subnet to our main PoP the subnet 1 and assign a Network Access Server located there an IPv6 address. The server happens to have the MAC address of 00:53:07:2B:AE:09. Knowing this we now determine the Globally unique IPv6 address of this server. The public IPv6 address assigned to us with a subnet of 1 – 2001:1F14::1:, plus the EUI-64 format Interface Identifier derived from the MAC address of the device - 0253:07FF:FE2B:AE09. Our Global Unicast address for our server would be 2001:1F14::1:0253:07FF:FE2B:AE09/64. Now for our Link-Local address we only have to use FE80:: along with our Interface ID. We then now get FE80::0253:07FF:FE2B:AE09. Please note again that this is autogenerated (you will see that once you start assigning an IPv6 address on a router) and that you have to get use to these addresses as these addresses are the ones used by routing protocols for IPv6 e.g OSPFv3, RIPng & MP-BGP.

I hope you guys learned something new and I’ll probably post more topics about IPv6 if I find the time. Yes its been busy these days so it sort of feels good to be able to post a topic again. If you have any questions about this topic just post you may visit the forum.

Linux's version of ipconfig

Last night I installed Ubuntu Server 9.04 via VMWare running inside my Windows 2003 Server. I've used several distros in the past but always gave up on Linux because of how hard to find the real solutions to all the problems that I've encountered in the past. Almost every year, I try to at least test one or two distros whenever I get a chance. Personally, I like OpenSuSe and Fedora Core but since Ubuntu is pretty much the de facto standard for desktop OS, I'll stick with Ubuntu just because of the community support.

Anyway, the point of this post is to educate newbie of Linux, such as myself. The practice of most people, if not all, is to statically assign IP addresses on all their servers and let the clients to get their IP address dynamically (DHCP). As for me, I don't like assigning static IP addresses in my home network. Why? I don't know. I just don't feel like it. c",) Anyway, I didn't like the IP address that I received when I issued ifconfig (ipconfig equivalent in Windows), so I went ahead and reserved the IP address of the one I like to use for this box by going to my router setup page. Once it was done, I needed to issue the equivalent commands of Window's ipconfig /release and /renew in Linux. So what a normal person would do? Well, they'll apply their mad Google skillz (hahaha). Anyway I found several commands that were suggested and are listed below:

sudo ifconfig eth0 down

then

sudo ifconfig eth0 up

That actually didn't do the trick. This pretty much the same thing as Cisco's command shutdown and no shutdown command. The correct command were showed below:

sudo dhclient -r

then

sudo dhclient

After issuing those commands, I was able to get the IP address that I reserved on my router.

Hopefully, you'll be able to use these commands on your long journey as a Network professional.

Note:

I believe these commands will only work for Debian based distro such as Ubuntu. If you use a different distro, try taking out the sudo and it might work. If not, then use your mad Google skillz to find the answer.

Posted by Andr01d

"I know nothing except the fact of my ignorance" - Socrates

VoIP Application Layer 1: The Packet Infrastructure

Thinking of creating your own VoIP application Part II.
Layer 1: The Packet Infrastructure

Let's say I am Superman and I have X-ray vision. My goal is to look at the inner-workings of a VoIP application or clients like Skype, Yahoo Messenger and Five9 Virtual Contact Center (VCC) Agent.

Like Superman, my goal is to "see-through" this VoIP application because I need to investigate on something. Apparently, Lex Luthor, being a rich genius that he is, has managed to create his own secure VoIP client. Lex Luthor is using this VoIP client application to make calls to his henchmen. So its up to me to investigate on this, retrieve evidence and prove to that he is the mastermind.

If I was Superman, all I need to do is use my X-ray vision to see-through the VoIP application Lex Luthor is using. I will immediately see hundreds of lines of programming codes, specifically variables, commands, and on the networking side, what communication protocols and their corresponding ports this application is using to communicate over the Internet. Now that's interesting.

Luckily, we do not need to be a man of steel or someone who wears blue and red tights and fly around the city saving people and still look cool in the process. Thank goodness for protocol analyzers. It is the X-ray vision of us guys in the voice and data networking field.

Wireshark, (known as Ethereal from its early days) is one of the leading protocol analyzers out there, and its free. If you need to investigate the inner-workings of an application connected to a network, Wireshark is your answer. It is slowly becoming the tool of choice for network sniffers and VoIP phreakers, black hat or white hat. There's tons of things you can do with Wireshark once you have it installed and running on your network, but that is beyond the topic of this post.

For this post, I will refer and use Wireshark extensively to show to you what networking protocols and ports Five9 Agent VCC is using. Five9 Agent VCC is a VoIP client used by Call Center Agents around the globe in making and receiving calls. Five9 VCC Agent utilizes a Softphone feature, the dial pad and other telephone features are on the screen, just push the buttons you need. All you need is a reliable Internet connection, a USB headset with microphone and an account with Five9, and that's it.

(To be continued on next post)

Gigabit Ethernet

I've been busy doing some mini projects at home and one of them was to install gigabit switch and NICs in all my computers, except my laptop. So what pushed me in upgrading my home network to gigabit? Well, I realized that moving over 250GB worth of data takes a long time! - obviously. I had to move that much data over my network to my File/Domain/DNS server - running Windows Server 2003. I know, it may be overkill to be running a NOS (Network Operating System) in my home network since it is pretty small, but has its benefits over peer-to-peer networking, which by the way been using since 2000. Moving to a domain-based network has been in my mind since 2002 or 2003. However, I didn't have time to study how to set it up properly since the last time I've touched NOS was back when NT Server 4.0 and it was the de facto standard. Anyway, let's skip all the stories and move to our main topic.

You probably already know this, but let's make this post for non-techy people out there. In order to get gigabit speeds (1000 Megabits per second or Mbps for short - also known as 1Gbps), you need gigabit capable switch (Netgear GS605 - this is what I have), gigabit capable NIC (Network Interface Card) - Rosewill RC-400 - this is what I have, CAT 5e or CAT 6 (recommended). Don't you think it's a little weird that I don't have Cisco/Linksys at home since I work on Cisco routers and switches every day at work? Well, to be honest, I wasn't happy with the very first Wi-Fi router that I bought from Linksys/Cisco. It kept dropping my wireless connection so I had to return it get the brand that I was already familiar with, which was Netgear. The very first Netgear products that I bought were NICs and a 4-port hub. This was back in 2000 which at that time I didn't know anything about networking, so I picked the hub instead of a switch. Well, to be honest, I still don't know anything about networking! c",)

Before we dive in to the network performance of gigabit, I want to show you what the throughput of 100Mbps that I was getting. By the way, I am using FreeMeter as my bandwidth monitor. Below is a screenshot of the throughput using 100Mbps LAN using 6GB file:

The left graph is the upload throughput using 100 Mbps. As you can see, you are not getting the theoretical bandwidth. That is understandable because you'll never get the theoretical bandwidth ever. Why? One notable reason is interference. Attenuation is another one, but it isn't applicable here since I only have 7 feet CAT6 cable.

The right graph is the download throughput using 100 Mbps. 77.1 Mbps was the highest that I could get with my 100 Mbps NIC connected to the gigabit switch. At least it is a little bit higher than the upload speed.

Here's what you've been waiting for, the network performance of Gigabit Ethernet. I am using the same setup with the exception of the NIC - of course. Below is the screenshot of gigabit throughput:

This time, the graphs were switched, but the color remained the same - green for download and red for upload. As you can see, it gave us about 100 Mbps more throughput compared to the 100 Mbps results. But, with the upload speed, it gave us about 200 Mbps more! I seriously wasn't expecting that - I was expecting that I'll get more out of the download than the upload.

Before I purchased my NICs, I read through all the user reviews because I was wondering how much faster if I go with gigabit ethernet. I was hoping to get at least 50% of the theoretical bandwidth, but I guess I was asking too much with the result above - a little disappointing. Anyway, after reading much reviews, I learned something new which was never in any of my books. In all the networking books that I've read, they talk about MTU (Maximum Transmission Unit) size of Ethernet is 1500 octects/bytes. With gigabit, you can use more than 1500 bytes, which they call jumbo frame. According to those reviews that I've read, enabling jumbo frame will give you more throughput - so I had to try.

Last night, I've installed the gigabit NICs in two of my computers (my HTPC has an onboard gigabit NIC, which is good) and I have one more gigabit NIC to install. Anyway, this morning, I changed the configuration of the NIC to 7K jumbo frame. Unfortunately, since I went with a cheap NIC, it can only support 7K jumbo frame instead of the de facto standard 9K jumbo frame. To change the configuration of your NIC, you have to go to the Device Manager. There are two ways to get there, one method is by right clicking My Computer > Properties > *System Properties* will show up > Hardware tab > Device Manager. The second way, which is my favorite, is by clicking Start > Run > type "devmgmt.msc" - without the quotation marks of course. Here's a sample shot of what you'll see:

Once you're there, click on the "+" sign right next to Network adapters. If you have two NICs, you'll see both of them there but pay attention to the right network adapter. In my case, I am using the Realtek based NIC. Oh so you noticed eh? Yes, all of my PCs are named after the characters in Starcraft. Anyway, once you picked the correct NIC, you'll need to hit right click and click on Properties. What you'll see is similar to the one below:

If your NIC supports Jumbo Frame, then you should be able to see it, just like the one above. As mentioned earlier, my NIC only supports up to 7K MTU size - the de facto standard is 9K MTU size. Without further delay, the screenshot below is the network performance with 7K MTU jumbo frame:

Same as before, green graph is for download and red graph for upload. Noticed something? It nearly doubled my download speed! While, the upload throughput went down by about 50 Mbps - a little disappointing. The saying is true, you can't get everything you want! c",)

Just to give you guys a heads up, you may want to read up more on jumbo frame with a mixed node setup. According to what I've read, you'll see problems once you start moving data from 100 Mbps enabled device to a 1 Gbps enabled device or vice versa with jumbo frames. It makes sense because one device can only support 1500 bytes of frame, while the other one is sending out 9KB of frame. I'll give you guys an update once I test it.

Written by: Andr01d

"I know nothing except the fact of my ignorance" - Socrates