<?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>onvox.net &#187; Catalyst</title>
	<atom:link href="http://onvox.net/tag/catalyst/feed" rel="self" type="application/rss+xml" />
	<link>http://onvox.net</link>
	<description></description>
	<lastBuildDate>Wed, 22 Feb 2012 15:29:48 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.2</generator>
		<item>
		<title>TDR cable testing with a Catalyst 3750E</title>
		<link>http://onvox.net/networking/tdr-cable-testing-with-a-catalyst-3750e</link>
		<comments>http://onvox.net/networking/tdr-cable-testing-with-a-catalyst-3750e#comments</comments>
		<pubDate>Wed, 22 Feb 2012 15:29:48 +0000</pubDate>
		<dc:creator>Jonathan Voss</dc:creator>
				<category><![CDATA[Cisco]]></category>
		<category><![CDATA[Networking]]></category>
		<category><![CDATA[3750]]></category>
		<category><![CDATA[Catalyst]]></category>
		<category><![CDATA[IOS]]></category>

		<guid isPermaLink="false">http://onvox.net/?p=278</guid>
		<description><![CDATA[A very useful tool for determining simple wiring problems (Layer 1) without having to leave your desk is the Time Domain Reflector testing built in to some of the Catalyst switches including the 3750E. One caveat is that it may cause connectivity problems for the particular tested interface. Start the test by issuing the command: [...]]]></description>
			<content:encoded><![CDATA[<p>A very useful tool for determining simple wiring problems (Layer 1) without having to leave your desk is the Time Domain Reflector testing built in to some of the Catalyst switches including the 3750E.</p>
<p>One caveat is that it may cause connectivity problems for the particular tested interface.</p>
<p>Start the test by issuing the command:</p>
<pre>
Switch#test cable-diagnostics tdr interface gi2/0/2
</pre>
<p>After a few seconds the test results will be available by issuing this command:</p>
<pre>
Switch#show cable-diagnostics tdr interface gi2/0/2
TDR test last run on: February 22 10:00:46

Interface Speed Local pair Pair length        Remote pair Pair status
--------- ----- ---------- ------------------ ----------- --------------------
Gi2/0/2   auto  Pair A     N/A                Pair B      Normal
                Pair B     N/A                Pair A      Open
                Pair C     64   +/- 1  meters N/A         Normal
                Pair D     65   +/- 1  meters N/A         Normal
</pre>
]]></content:encoded>
			<wfw:commentRss>http://onvox.net/networking/tdr-cable-testing-with-a-catalyst-3750e/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Suppress %SNMP-3-AUTHFAIL Logging</title>
		<link>http://onvox.net/networking/suppress-snmp-3-authfail-logging</link>
		<comments>http://onvox.net/networking/suppress-snmp-3-authfail-logging#comments</comments>
		<pubDate>Wed, 23 Mar 2011 16:37:21 +0000</pubDate>
		<dc:creator>Jonathan Voss</dc:creator>
				<category><![CDATA[Cisco]]></category>
		<category><![CDATA[Networking]]></category>
		<category><![CDATA[Catalyst]]></category>
		<category><![CDATA[IOS]]></category>

		<guid isPermaLink="false">http://onvox.net/?p=247</guid>
		<description><![CDATA[For a while now, security scanning software and users have been triggering an onslaught of %SNMP-3-AUTHFAIL messages in our device logs. This rather annoying message often obscures other events that may be more important. Old mentality would tell you to simply create a logging discriminator and be done with it. However, I recently learned of [...]]]></description>
			<content:encoded><![CDATA[<p>For a while now, security scanning software and users have been triggering an onslaught of %SNMP-3-AUTHFAIL messages in our device logs. This rather annoying message often obscures other events that may be more important. Old mentality would tell you to simply create a logging discriminator and be done with it. However, I recently learned of a little undocumented gem in IOS that saves the day:</p>
<pre>
hostname(config)#no logging snmp-authfail
</pre>
<p>Do not trust the almighty &#8216;<code>?</code>&#8216; command. It will not show up as a valid option. However, when actually executing the command, it has worked in every IOS case I have tried.</p>
]]></content:encoded>
			<wfw:commentRss>http://onvox.net/networking/suppress-snmp-3-authfail-logging/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Enabling IPv6 on Cisco Catalyst 3750 Devices</title>
		<link>http://onvox.net/networking/enabling-ipv6-on-cisco-catalyst-3750-devices</link>
		<comments>http://onvox.net/networking/enabling-ipv6-on-cisco-catalyst-3750-devices#comments</comments>
		<pubDate>Tue, 09 Feb 2010 18:00:32 +0000</pubDate>
		<dc:creator>Jonathan Voss</dc:creator>
				<category><![CDATA[Cisco]]></category>
		<category><![CDATA[IPv6]]></category>
		<category><![CDATA[Networking]]></category>
		<category><![CDATA[3750]]></category>
		<category><![CDATA[Catalyst]]></category>
		<category><![CDATA[IOS]]></category>

		<guid isPermaLink="false">http://onvox.net/?p=169</guid>
		<description><![CDATA[I was recently baffled to see that when I entered configuration mode within a VLAN interface on a Catalyst access layer switch that I could not set any IPv6 options! It turns out that by default, SDM prefers what it calls the “desktop default” template. This means it is optimized for IPv4 and does not [...]]]></description>
			<content:encoded><![CDATA[<p>I was recently baffled to see that when I entered configuration mode within a VLAN interface on a Catalyst access layer switch that I could not set any IPv6 options! It turns out that by default, SDM prefers what it calls the “desktop default” template. This means it is optimized for IPv4 and does not include IPv6 support. Fortunately a quick but painful fix to this is to change the prefered SDM template from “desktop default” to “dual-ipv4-and-ipv6″:</p>
<pre>
Switch>enable
Switch#config t
Switch(config)#sdm prefer dual-ipv4-and-ipv6
Switch(config)#end
Switch#reload
</pre>
<p>Unfortunately, you will need to reload (reboot) the device in order for the changes to take place, which will obviously incur annoying downtime for your users. Once the device has reloaded you can verify by issuing a <code>show sdm prefer</code> command which should look something like this:</p>
<pre>
Switch#show sdm  prefer
 The current template is "desktop IPv4 and IPv6 default" template.
 The selected template optimizes the resources in
 the switch to support this level of features for
 8 routed interfaces and 1024 VLANs.

  number of unicast mac addresses:                  2K
  number of IPv4 IGMP groups + multicast routes:    1K
  number of IPv4 unicast routes:                    3K
    number of directly-connected IPv4 hosts:        2K
    number of indirect IPv4 routes:                 1K
  number of IPv6 multicast groups:                  1.125k
  number of directly-connected IPv6 addresses:      2K
  number of indirect IPv6 unicast routes:           1K
  number of IPv4 policy based routing aces:         0
  number of IPv4/MAC qos aces:                      0.5K
  number of IPv4/MAC security aces:                 1K
  number of IPv6 policy based routing aces:         0
  number of IPv6 qos aces:                          0.5K
  number of IPv6 security aces:                     0.5K
</pre>
<p>Now you should be able to configure IPv6 interfaces and ACLs.</p>
]]></content:encoded>
			<wfw:commentRss>http://onvox.net/networking/enabling-ipv6-on-cisco-catalyst-3750-devices/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

