<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>The Geekery &#187; Networking</title>
	<atom:link href="http://jon.netdork.net/category/technology/networking/feed" rel="self" type="application/rss+xml" />
	<link>http://jon.netdork.net</link>
	<description>The Usual Stuff...</description>
	<lastBuildDate>Sun, 18 Jul 2010 16:53:23 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.1</generator>
		<item>
		<title>Massive Uptimes, or the failure of them&#8230;</title>
		<link>http://jon.netdork.net/2010/06/18/massive-uptimes-or-the-failure-of-them?utm_source=rss&amp;utm_medium=rss&amp;utm_campaign=massive-uptimes-or-the-failure-of-them</link>
		<comments>http://jon.netdork.net/2010/06/18/massive-uptimes-or-the-failure-of-them#comments</comments>
		<pubDate>Sat, 19 Jun 2010 04:39:26 +0000</pubDate>
		<dc:creator>Jonathan Angliss</dc:creator>
				<category><![CDATA[Networking]]></category>
		<category><![CDATA[SysAdmin]]></category>

		<guid isPermaLink="false">http://jon.netdork.net/?p=872</guid>
		<description><![CDATA[The Nubby Admin has a great post on uptimes, and the old fascination of having a large uptime. Okay, you can get your minds out the gutter now, not that kind of up time. We&#8217;re talking servers here. The post covers a hidden fear, and the goods and bads of large server uptimes. A good [...]]]></description>
			<content:encoded><![CDATA[<!-- google_ad_section_start --><div class="tweetmeme_button" style="float: right; margin-left: 10px;">
			<a href="http://api.tweetmeme.com/share?url=http%3A%2F%2Fjon.netdork.net%2F2010%2F06%2F18%2Fmassive-uptimes-or-the-failure-of-them">
				<img src="http://api.tweetmeme.com/imagebutton.gif?url=http%3A%2F%2Fjon.netdork.net%2F2010%2F06%2F18%2Fmassive-uptimes-or-the-failure-of-them&amp;source=j_angliss&amp;style=normal&amp;service=bit.ly&amp;hashtags=SysAdmin" height="61" width="50" />
			</a>
		</div><p><a href="http://thenubbyadmin.com/" title="The Nubby Admin">The Nubby Admin</a> has a <strong>great</strong> <a href="http://thenubbyadmin.com/2010/06/16/epic-uptime-bragging-rights-or-epic-fail/?utm_source=TheGeekery&amp;utm_medium=web&amp;utm_campaign=epic-uptime-bragging-rights-or-epic-fail" title="The Nubby Admin; Epic Uptime – Bragging Rights or Epic Fail?">post</a> on uptimes, and the old fascination of having a large uptime.  Okay, you can get your minds out the gutter now, not that kind of <em>up</em> time.  We&#8217;re talking servers here.  </p>

<p>The post covers a hidden fear, and the goods and bads of large server uptimes.  A good read, and one you should look at if you&#8217;re watching your server rolling over into the third year of being running.  I get a mention (well more of a quote), and seem to fall in with the general crowd, large server uptimes are generally bad.</p>

<p>Go read, enjoy, learn something new from the great minds Wesley is surrounding himself with (myself excluded).</p><!-- google_ad_section_end -->]]></content:encoded>
			<wfw:commentRss>http://jon.netdork.net/2010/06/18/massive-uptimes-or-the-failure-of-them/feed</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
	<!-- google ad injected by adsense-optimizer http://www.adsenseoptimizer.de -->
			<div  style="padding:7px; display: block; margin-left: auto; margin-right: auto; text-align: center;"><!-- Linkblock number: 1 --><script type="text/javascript"><!--
	 
google_ad_client = "pub-5380792458095798";
google_ad_width = 468;
google_ad_height = 15;
google_ad_format = "468x15_0ads_al"; google_ad_channel ="";
google_color_border = "CCCCCC";
google_color_bg = "F7F7F7";
google_color_link = "2970A6";
//--></script>
<script type="text/javascript" src="http://pagead2.googlesyndication.com/pagead/show_ads.js"></script></div>	<item>
		<title>Tracking the rogue IP address</title>
		<link>http://jon.netdork.net/2010/05/06/tracking-the-rouge-ip-address?utm_source=rss&amp;utm_medium=rss&amp;utm_campaign=tracking-the-rouge-ip-address</link>
		<comments>http://jon.netdork.net/2010/05/06/tracking-the-rouge-ip-address#comments</comments>
		<pubDate>Thu, 06 May 2010 20:47:35 +0000</pubDate>
		<dc:creator>Jonathan Angliss</dc:creator>
				<category><![CDATA[Networking]]></category>

		<guid isPermaLink="false">http://jon.netdork.net/?p=798</guid>
		<description><![CDATA[Digging up an old post today, I helped my wife figure out why her office A/C system couldn&#8217;t be managed properly. Apparently their system connects on a specific IP address, and it wasn&#8217;t responding. It was surmised that it was caused by some work I had done fixing one of the other machines a few [...]]]></description>
			<content:encoded><![CDATA[<!-- google_ad_section_start --><div class="tweetmeme_button" style="float: right; margin-left: 10px;">
			<a href="http://api.tweetmeme.com/share?url=http%3A%2F%2Fjon.netdork.net%2F2010%2F05%2F06%2Ftracking-the-rouge-ip-address">
				<img src="http://api.tweetmeme.com/imagebutton.gif?url=http%3A%2F%2Fjon.netdork.net%2F2010%2F05%2F06%2Ftracking-the-rouge-ip-address&amp;source=j_angliss&amp;style=normal&amp;service=bit.ly" height="61" width="50" />
			</a>
		</div><p>Digging up an <a href="http://jon.netdork.net/2007/07/26/hunting-ip-conflicts-on-a-windows-network" title="TheGeekery; Hunting IP Conflicts on a Windows Network">old post</a> today, I helped my wife figure out why her office A/C system couldn&#8217;t be managed properly.  Apparently their system connects on a specific <acronym title="Internet Protocol">IP</acronym> address, and it wasn&#8217;t responding.  It was surmised that it was caused by some work I had done fixing one of the other machines a few months ago. But after some quick digging, turns out it wasn&#8217;t.  Apparently their &#8220;consultant&#8221; had a device on the network for VPN, firewall, etc, which had the same address on it.  How it got the same, we don&#8217;t know, but here is how we figured it out&#8230;</p>

<p><span id="more-798"></span></p>

<p>From a server on the network, we pinged the <acronym title="Internet Protocol">IP</acronym> address that the A/C system was supposed to use.</p>

<div class="codecolorer-container dos default" style="overflow:auto;white-space:nowrap;border:1px solid #9F9F9F;width:435px;"><div class="dos codecolorer" style="padding:5px;font:normal 12px/1.4em Monaco, Lucida Console, monospace;white-space:nowrap">C:\&gt; ping 192.168.1.200<br />
Pinging 192.168.1.200 with <span style="color: #cc66cc;">32</span> bytes of data:<br />
Reply from 192.168.1.200: bytes <span style="color: #cc66cc;">32</span> time=1ms TTL=<span style="color: #cc66cc;">21</span><br />
Request timed out.<br />
Request timed out.<br />
Request timed out.<br />
<br />
Ping statistics <a href="http://www.ss64.com/nt/for.html"><span style="color: #00b100; font-weight: bold;">for</span></a> 192.168.1.200:<br />
&nbsp; Packets: Sent = <span style="color: #cc66cc;">4</span>, Received = <span style="color: #cc66cc;">1</span>, Lost = <span style="color: #cc66cc;">3</span> <span style="color: #66cc66;">&#40;</span><span style="color: #cc66cc;">75</span><span style="color: #33cc33;">%</span> loss<span style="color: #66cc66;">&#41;</span>,</div></div>

<p>This showed us there was a device alive with the address, but it was being bumped off, probably due to fighting with the A/C unit.  Next was to figure out what the device was.  This required the <a href="http://en.wikipedia.org/wiki/MAC_address" title="Wikipedia; MAC Address">MAC address</a> of the device.  To get that we needed ARP, or Address Resolution Protocol.  Essentially, with the little known information about MAC address, we can figure out who made the NIC card installed in the device conflicting.  This can help us clue in to what kind of device is causing the issue.  We get the information using the following:</p>

<div class="codecolorer-container dos default" style="overflow:auto;white-space:nowrap;border:1px solid #9F9F9F;width:435px;"><div class="dos codecolorer" style="padding:5px;font:normal 12px/1.4em Monaco, Lucida Console, monospace;white-space:nowrap">C:\&gt;arp -a<br />
<br />
Interface: 192.168.1.2<br />
&nbsp; Internet Address &nbsp; &nbsp; &nbsp; &nbsp;Physical Address &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Type<br />
&nbsp; 192.168.1.200 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 00-09-0F-##-##-## &nbsp; dynamic</div></div>

<p>Now we have the <acronym title="Internet Protocol">IP</acronym> address, and the <em>Physical Address</em>, or the MAC address.  Okay, those numbers don&#8217;t mean a whole bunch to some people, but the IEEE (Institute of Electrical and Electronics Engineers) keeps a <a href="http://standards.ieee.org/regauth/oui/index.shtml" title="IEEE; OUI and Company_id Assignments">register</a> of who owns what MAC address.</p>

<p>Using the IEEE <a href="http://standards.ieee.org/regauth/oui/index.shtml" title="IEEE; OUI and Company_id Assignments">search page</a> we entered in the first 3 octets (the ones above not masked with ##).  This came back with a device registered by <strong>Fortinet Inc</strong>.  A quick look up, and we saw a FortiGate device, which is made by FortiNet.  An appliance device that does VPN, Firewall, spam filtering, web filtering, and all types of other fun stuffs.</p>

<p>This isn&#8217;t the only way either.  There are other ways too, especially if you have access to the switches, and they give you handy commands like the Cisco&#8217;s do, and then you go do stuff like <a href="http://packetlife.net/blog/2010/apr/19/locating-host-port-ip-address/" title="PacketLife; Locating Host Port IP Address">this</a>.</p>

<p>Now the wife has to get in touch with the &#8220;consultant&#8221; to figure out why it&#8217;s using that <acronym title="Internet Protocol">IP</acronym> address, and how to correct it.</p><!-- google_ad_section_end -->]]></content:encoded>
			<wfw:commentRss>http://jon.netdork.net/2010/05/06/tracking-the-rouge-ip-address/feed</wfw:commentRss>
		<slash:comments>3</slash:comments>
		</item>
		<item>
		<title>Networking Cheat Sheets&#8230;</title>
		<link>http://jon.netdork.net/2010/01/24/networking-cheat-sheets?utm_source=rss&amp;utm_medium=rss&amp;utm_campaign=networking-cheat-sheets</link>
		<comments>http://jon.netdork.net/2010/01/24/networking-cheat-sheets#comments</comments>
		<pubDate>Mon, 25 Jan 2010 04:11:43 +0000</pubDate>
		<dc:creator>Jonathan Angliss</dc:creator>
				<category><![CDATA[Networking]]></category>
		<category><![CDATA[Technology]]></category>

		<guid isPermaLink="false">http://jon.netdork.net/?p=605</guid>
		<description><![CDATA[PacketLife as an excellent collection of cheat sheets for networking professionals. Well worth a quick look and bookmarking for later.]]></description>
			<content:encoded><![CDATA[<!-- google_ad_section_start --><div class="tweetmeme_button" style="float: right; margin-left: 10px;">
			<a href="http://api.tweetmeme.com/share?url=http%3A%2F%2Fjon.netdork.net%2F2010%2F01%2F24%2Fnetworking-cheat-sheets">
				<img src="http://api.tweetmeme.com/imagebutton.gif?url=http%3A%2F%2Fjon.netdork.net%2F2010%2F01%2F24%2Fnetworking-cheat-sheets&amp;source=j_angliss&amp;style=normal&amp;service=bit.ly" height="61" width="50" />
			</a>
		</div><p>PacketLife as an excellent collection of <a href="http://packetlife.net/library/cheat-sheets/" title="PacketLife; Cheat Sheets">cheat sheets</a> for networking professionals.  Well worth a quick look and bookmarking for later.</p><!-- google_ad_section_end -->]]></content:encoded>
			<wfw:commentRss>http://jon.netdork.net/2010/01/24/networking-cheat-sheets/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
