<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title>Blogroll - Category - Fryguy's Blog</title><link>https://hugo.fryguy.net/categories/blogroll/</link><description>Blogroll - Category - Fryguy's Blog</description><generator>Hugo -- gohugo.io</generator><language>en</language><lastBuildDate>Sun, 31 Jul 2011 12:11:02 +0000</lastBuildDate><atom:link href="https://hugo.fryguy.net/categories/blogroll/" rel="self" type="application/rss+xml"/><item><title>Packet Pushers Podcast</title><link>https://hugo.fryguy.net/2011/07/31/packet-pushers-podcast/</link><pubDate>Sun, 31 Jul 2011 12:11:02 +0000</pubDate><author>Fryguy</author><guid>https://hugo.fryguy.net/2011/07/31/packet-pushers-podcast/</guid><description><![CDATA[<p style="text-align: center;">
  
</p>
<p>If you have not heard of it by now, let me take a moment and introduce you to a really good podcast called Packet Pushers Podcast (PPP for short).<br>
PPP is a bunch of networking nerds and uber geeks getting together around a virtual workbench and talking about topics that are of interest to us networking people.  Past topics have ranged from Juniper Q-Fabric, LISP, MS Teredo, Arista Networks, Openflow, and many many more.  Some of these topics might be new to you, some of them are an old hat, but no matter what they it is a great opportunity to listen and learn to what others have to say.  Sometimes their view or understanding is different then ours.  Also what is nice – sometimes the Vendors step in and join the conversation, so you are getting first-hand information!<br>
The primary topics focus on the core technologies – Routing, Switching, and Firewalls.  These are the core of what most of us do on a day to day basis, and lets be honest – how many of us have time to research all the technologies and changing industries that are out there?   We all can do some, but there are many more that we cannot look at, and this is where PPP is great.  It is a chance to listen to about an hour podcast and listen and learn.  I usually listen when I am either walking during lunch, cutting the grass at, or going for a bike ride after work (still trying to get rid of the CCIE 30.) (cont)</p>]]></description></item><item><title>Welcome. . .</title><link>https://hugo.fryguy.net/2011/05/24/welcome/</link><pubDate>Tue, 24 May 2011 23:55:36 +0000</pubDate><author>Fryguy</author><guid>https://hugo.fryguy.net/2011/05/24/welcome/</guid><description><![CDATA[<p><a href="/wp-content/uploads/2011/05/Welcome2.jpg" rel=""></a><br>
 <br>
Welcome to the new site!  I have recently moved the site from the WordPress hosted site so a new location.  This site is now reachable via blog.fryguy.net or <a href="https://www.fryguy.net" target="_blank" rel="noopener noreffer ">www.fryguy.net</a>, <a href="https://www.fryguy.net" target="_blank" rel="noopener noreffer ">www.fryguy.net</a> being the preferred method going forward.  I still need to finish up a few things here and there, but all the posts have been moved with all their content – so we should be good to go!<br>
Why did I move it you may ask, well I just felt it was time to be able to branch out a bit.  I can now host video, flash, or anything else that suit my readers.<br>
So, if you have any suggestions or ideas – just let me know!  Also, if you find any problems – please let me know so that I can correct them quickly.<br>
Thank you, and again – Welcome!</p>]]></description></item><item><title>Integrated Switch Modules in Routers (SM-E3SG and NME-XD)</title><link>https://hugo.fryguy.net/2011/01/23/integrated-switch-modules-in-routers-sm-e3sg-and-nme-xd/</link><pubDate>Sun, 23 Jan 2011 14:03:15 +0000</pubDate><author>Fryguy</author><guid>https://hugo.fryguy.net/2011/01/23/integrated-switch-modules-in-routers-sm-e3sg-and-nme-xd/</guid><description>&lt;p>In the Small Branch office type of environment we are commonly limited to the budget of the design, the space for the hardware, as well as the remote supportability of the site.  By supportability I refer to being able to walk someone through what each device it, what it does, and how to check when (not if) there is a problem. Normally this design may look something a router connecting to WAN links (T1/DS3/etc), then that router connecting to some type of switch or switches, and finally the end stations being connected to the switch(es).  Perhaps in a simplistic fashion, the network looks like this:&lt;/p></description></item></channel></rss>