- NANOG - lists.nanog.org

Future of the IPv6 CPE survey on RIPE Labs - Your Input Needed
by Mirjam Kuehne 27 Jan '11

27 Jan '11

[apologies for duplicates] Hello, Based on new information we received since the last publication, we updated the IPv6 CPE matrix: http://labs.ripe.net/Members/mirjam/ipv6-cpe-survey-updated-january-2011 In order to make this information more useful for a large user base, we are preparing a detailed survey to gather more structural feedback about the range of equipment that is currently in use. Not only would we like you to participate in this survey, but we also ask for your help in identifying the right survey questions. Please find a call for input on RIPE Labs: http://labs.ripe.net/Members/marco/future-of-the-ipv6-cpe-survey-more-input… Kind Regards, Mirjam Kuehne & Marco Hogewoning RIPE NCC

11 17

Re: [dnsext] Historical root keys: The Large Router Vendor Speaks
by Jay Ashworth 27 Jan '11

27 Jan '11

----- Original Message ----- > From: "John Bashinski" <jbash(a)cisco.com> > Well, this has generated some interesting messages, and apparently > some people think that the "large router vendor" in question should > speak for itself. Yay! > Realities > ========= > 5. Some of the people installing these products (frankly including some > of the professional network gear) will have no clue what DNSSEC is > or what cryptography is. > > 6. In the case of the consumer gear, the cost to us of helping the > customer deal with any DNSSEC failure will be greater than the entire profit > we make on the device. > > 7. Even for professional gear, customers don't want to pay their staff > to mess with this, and we don't want to pay our staff to support > them. > > 8. Lots of our products get drop-shipped to people's field offices, > get plugged in by a wire-plugger-inner who basically just checks > that the lights are on and goes on to the next task, and then > have to fend for themselves, at least enough to be able to talk > to the NOC and await further instructions. > > Implication B: As much as it possibly can, anything we do must work > without human intervention, and especially without very skilled > intervention. We know there will be problems, but we MUST minimize > them and minimize the amount of "touch" required to fix them. > > Implication C: Social engineering is almost always a bigger risk than > cryptographic failure, especially at the device end of the > communication chain. That block of (correct) observations, coupled with later ones which I've elided for space, suggests to me the following observation: There is a limit to the maximum practical security and trust which can be engineered into the Internet at Large, absent some investment by specific users/network operators who require more. That observation shouldn't apply to the people who actually have a reason to be on this list -- backbone operators and professional DNS zone server operators *should* make that investment, as a contribution to the Public Good... but you can't necessarily expect it at the edge. My experience, and the integration of all the things I've learned in doing this for 25 years, is that complexity reaches a tipping point; there's only so much of it you can allow and still have a stable system -- and the complexity "attack surface" is at least proportional to the size of the system itself; something the size of The Entire Internet has even more stringent limits in that regard than, say, an enterprise LAN/WAN. So while I applaud Cisco's (or, more properly, John's) evaluation of the situation, and statement of goals -- and I agree with nearly everything he says -- my personal opinion is that there's a practical limit as to how close to the edge you can push the event horizon without the whole thing falling over... and I don't think that number's 100%. Cheers, -- jra

1 0

Re: Found: Who is responsible for no more IP addresses
by Jay Ashworth 27 Jan '11

27 Jan '11

[ Sorry; forgot to address this to the list, earlier. ] ----- Original Message ----- > From: "Brian Johnson" <bjohnson(a)drtel.com> > I'm a bit torn on this issue. I haven't even heard any other > "main-stream" sources say anything on this topic. But Incorrect info > is bad too. > > I hope the viewers who watched this are getting the gist that > "Something wicked this way comes". :) Vint was quoted as saying this some months ago, I believe in a story linked from Slashdot on a reputable news outlet. Sure enough: https://encrypted.google.com/search?q=vint+cerf+IP+address Cheers, -- jra

1 0

Contact at Dynadot
by Christopher 27 Jan '11

27 Jan '11

I have been knocking down this Romanian IRC botnet since Thanksgiving and Dynadot has been dragging their feet. I even called and talked to someone in tech support, which was an Asian guy with a small grasp of English but that's another discussion, and still they say they are "investigating it" Does anyone have a personal contact at Dynadot to get this escalated? It's painfully obvious and needs no investigation because they can look at the past DNS records for this subdomains to see the constant changes and updates with totally random IP addresses - customer DSL IP addresses, Russia, China, EDU institutions worldwide, etc. Please contact me off list. Thank you

1 0

NANOG 51 (Miami): ISP Security BOF
by Paul Scanlon 27 Jan '11

27 Jan '11

Hi All, Happy New Year. NANOG 51 in Miami is rapidly approaching, January 30 - February 2, and we are looking for topics for the ISP Security BOF. Eric Osterweil and I are going to be moderating this year with the assistance of Danny McPherson. We would very much like to hear your feedback regarding topics of interest for the session. If you have any security related topics that you would like to hear about, not hear about, or be willing to speak about, please let one of us know as soon as possible, feedback to the list obviously welcome. Slides are welcome but not required. Much thanks, Eric & Paul ------------------------------------ Paul Scanlon Arbor Networks +1.303.477.0919 office +1.303.810.7260 mobile ------------------------------------

2 2

Re: NANOG Digest, Vol 36, Issue 141
by Ivan Brunello 27 Jan '11

27 Jan '11

> > Message: 10 > Date: Tue, 25 Jan 2011 16:11:46 -0500 > From: Christopher <caldcv(a)gmail.com> > Subject: Re: Network Naming > To: nanog(a)nanog.org > Message-ID: <4D3F3C92.9050401(a)gmail.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > I usually name them after ex-girlfriends > > > On 01/25/2011 03:50 PM, Nick Olsen wrote: > > Whats the rule of thumb for naming gear these days > > (routers,switches...etc). Or is there one? > > > > looks like level3 does something like > > interface.routertype.location.level3.net > > > > Nick Olsen > > Network Operations > > (855) FLSPEED x106 > > > > > > > I would then get short of names VERY FAST :-) Ivan Brunello Net Ops ....

2 1

Re: Using IPv6 with prefixes shorter than a /64 on a LAN
by bmanning＠vacation.karoshi.com 27 Jan '11

27 Jan '11

well... you are correct - he did say shorter. me - i'd hollar for my good friends Fred and Radia (helped w/ the old vitalink mess) on the best way to manage an arp storm and/or cam table of a /64 of MAC addresses. :) It was hard enough to manage a "lan"/single broadcast domain that was global in scope and had 300,000 devices on it. "route when you can, bridge when you must" --bill On Mon, Jan 24, 2011 at 08:58:25AM -0800, Owen DeLong wrote: > Bill... Last I looked, /120 was longer than /64, not shorter. > > What I'm not understanding would be why anyone would want to use > something shorter than /64 on a LAN. > > Owen > > On Jan 24, 2011, at 5:28 AM, bmanning(a)vacation.karoshi.com wrote: > > > as a test case, i built a small home network out of /120. works just fine. > > my home network has been native IPv6 for about 5 years now, using a /96 and IVI. > > > > some thoughts. disable RD/RA/ND. > > none of the DHCPv6 code works like DHCP, so I re-wrote > > client and server code so that it does. > > static address assignment is a good thing for services like DNS/HTTP > > secure dynmaic update is your friend > > > > summary - its not easy, vendors don't want to help. but it can be done. > > > > --bill > > > > > > On Mon, Jan 24, 2011 at 10:59:59AM -0200, Carlos Martinez-Cagnazzo wrote: > >> The subject says it all... anyone with experience with a setup like this ? > >> > >> I am particularly wondering about possible NDP breakage. > >> > >> cheers! > >> > >> Carlos > >> > >> -- > >> -- > >> ========================= > >> Carlos M. Martinez-Cagnazzo > >> http://www.labs.lacnic.net > >> ========================= >

3 4

IPv6 filtering
by Franck Martin 26 Jan '11

26 Jan '11

• ipv6 41 IPv6 # IPv6 • ipv6-route 43 IPv6-Route # Routing Header for IPv6 • ipv6-frag 44 IPv6-Frag # Fragment Header for IPv6 • ipv6-crypt 50 IPv6-Crypt # Encryption Header for IPv6 • ipv6-auth 51 IPv6-Auth # Authentication Header for IPv6 • ipv6-icmp 58 IPv6-ICMP icmpv6 icmp6 # ICMP for IPv6 • ipv6-nonxt 59 IPv6-NoNxt # No Next Header for IPv6 • ipv6-opts 60 IPv6-Opts # Destination Options for IPv6 Ok filtering ipv6 and ipv6-icmp is understood, it is like ipv4. But what about the others, should they be blocked, restricted? Does a ios "deny ipv6 any any" affect them?

9 9

Cisco Security Advisory: Cisco Content Services Gateway Vulnerabilities
by Cisco Systems Product Security Incident Response Team 26 Jan '11

26 Jan '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Cisco Security Advisory: Cisco Content Services Gateway Vulnerabilities Advisory ID: cisco-sa-20110126-csg2 http://www.cisco.com/warp/public/707/cisco-sa-20110126-csg2.shtml Revision 1.0 For Public Release 2011 January 26 1600 UTC (GMT) +--------------------------------------------------------------------- Summary ======= A service policy bypass vulnerability exists in the Cisco Content Services Gateway - Second Generation (CSG2), which runs on the Cisco Service and Application Module for IP (SAMI). Under certain configurations this vulnerability could allow: * Customers to access sites that would normally match a billing policy to be accessed without being charged to the end customer * Customers to access sites that would normally be denied based on configured restriction policies Additionally, Cisco IOS Software Release 12.4(24)MD1 on the Cisco CSG2 contains two vulnerabilities that can be exploited by a remote, unauthenticated attacker to create a denial of service condition that prevents traffic from passing through the CSG2. These vulnerabilities require only a single content service to be active on the Cisco CSG2 and can be exploited via crafted TCP packets. A three-way handshake is not required to exploit either of these vulnerabilities. Workarounds that mitigate these vulnerabilities are not available. This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20110126-csg2.shtml. Affected Products ================= The service policy bypass vulnerability affects all versions of the Cisco IOS Software for the CSG2 prior to the first fixed release, as indicated in the "Software Versions and Fixes" section of this advisory. The two denial of service vulnerabilities only affect Cisco IOS Software Release 12.4(24)MD1 on the Cisco CSG2. No other Cisco IOS Software releases are affected. Vulnerable Products +------------------ To determine the version of Cisco IOS Software that is running on the Cisco CSG2, issue the "show module" command from Cisco IOS Software on the switch on which the Cisco CSG2 module is installed to identify what modules and sub-modules are installed on the system. Cisco CSG2 runs on the Cisco Service and Application Module for IP (SAMI) card, and is identified in the following example in slot 2 via the WS-SVC-SAMI-BB-K9 identification: C7600#show module Mod Ports Card Type Model Serial No. --- ----- -------------------------------------- ------------------ ----------- 1 2 Supervisor Engine 720 (Active) WS-SUP720-3BXL JAF1226ARQS 2 1 SAMI Module (csgk9) WS-SVC-SAMI-BB-K9 SAD113906P1 4 48 CEF720 48 port 10/100/1000mb Ethernet WS-X6748-GE-TX SAL1127T6XY Mod MAC addresses Hw Fw Sw Status --- ---------------------------------- ------ ------------ ------------ ------- 1 001e.be6e.a018 to 001e.be6e.a01b 5.6 8.5(2) 12.2(33)SRC5 Ok 2 001d.45f8.f3dc to 001d.45f8.f3e3 2.1 8.7(0.22)FW1 12.4(2010040 Ok 4 001c.587a.ef20 to 001c.587a.ef4f 2.6 12.2(14r)S5 12.2(33)SRC5 Ok Mod Sub-Module Model Serial Hw Status ---- --------------------------- ------------------ ----------- ------- ------- 1 Policy Feature Card 3 WS-F6K-PFC3BXL JAF1226BNQM 1.8 Ok 1 MSFC3 Daughterboard WS-SUP720 JAF1226BNMC 3.1 Ok 2 SAMI Daughterboard 1 SAMI-DC-BB SAD114400L9 1.1 Other 2 SAMI Daughterboard 2 SAMI-DC-BB SAD114207FU 1.1 Other 4 Centralized Forwarding Card WS-F6700-CFC SAL1029VGFK 2.0 Ok Mod Online Diag Status ---- ------------------- 1 Pass 2 Pass 4 Pass C7600# After locating the correct slot, issue the "session slot <module number> processor <3-9>" command to open a console connection to the respective Cisco CSG2. Once connected to the Cisco CSG2, perform the "show version" command: The following example shows that the Cisco CSG2 is running software Release 12.4(24)MD1: CSG2#show version Cisco IOS Software, SAMI Software (SAMI-CSGK9-M), Version 12.4(24)MD1, RELEASE SOFTWARE (fc2) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2010 by Cisco Systems, Inc. Compiled Wed 07-Apr-10 09:50 by prod_rel_team --- output truncated --- Products Confirmed Not Vulnerable +-------------------------------- The Cisco Content Services Gateway - 1st Generation (CSG) is not affected by these vulnerabilities. No other Cisco products are currently known to be affected by these vulnerabilities. Details ======= The Cisco Content Services Gateway - Second Generation (CSG2) provides intelligent network capabilities such as flexible policy management and billing based on deep-packet inspection, as well as subscriber and application awareness capabilities that enable mobile operators to quickly and easily offer value-added, differentiated services over their mobile data networks. The service policy bypass vulnerability affects configurations that allow end users to first access non-accounted or billed sites. After a user accesses a non-accounted site, it is possible to access other sites that are defined by a billing service policy or to access sites that may be blocked by other policies by sending specially crafted HTTP packets. This vulnerability only affects HTTP content traffic. HTTPS and other traffic types are not affected. Both denial of service vulnerabilities require only a single content service to be active on the Cisco CSG2 and can be exploited via crafted TCP packets. A three-way handshake is not required to exploit either of these vulnerabilities. The vulnerabilities are triggered by TCP traffic that transits the Cisco CSG2. The service policy bypass vulnerability is documented in Cisco Bug ID CSCtk35917 and has been assigned CVE ID CVE-2011-0348. The denial of service bugs are documented in Cisco Bug ID CSCth17178 and Cisco Bug ID CSCth41891 and have been assigned CVE IDs CVE-2011-0349 and CVE-2011-0350 respectively. Vulnerability Scoring Details ============================= Cisco has provided scores for the vulnerabilities in this advisory based on the Common Vulnerability Scoring System (CVSS). The CVSS scoring in this Security Advisory is done in accordance with CVSS version 2.0. CVSS is a standards-based scoring method that conveys vulnerability severity and helps determine urgency and priority of response. Cisco has provided a base and temporal score. Customers can then compute environmental scores to assist in determining the impact of the vulnerability in individual networks. Cisco has provided an FAQ to answer additional questions regarding CVSS at: http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html Cisco has also provided a CVSS calculator to help compute the environmental impact for individual networks at: http://intellishield.cisco.com/security/alertmanager/cvss * CSCtk35917 ("Service Policy Bypass Vulnerability") CVSS Base Score - 6.4 Access Vector - Network Access Complexity - Low Authentication - None Confidentiality Impact - Partial Integrity Impact - Partial Availability Impact - None CVSS Temporal Score - 5.3 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed * CSCth41891/CSCth17178 ("Crafted TCP packet causes CSG2 to restart") CVSS Base Score - 7.8 Access Vector - Network Access Complexity - Low Authentication - None Confidentiality Impact - None Integrity Impact - None Availability Impact - Complete CVSS Temporal Score - 6.4 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed Impact ====== Successful exploitation of the service policy bypass can allow customers to obtain access to sites that would normally be accounted and billed according to the billing policy without the billing policy being engaged. Additionally, customers could gain access to URLs that are configured in the Cisco CSG2 to be explicitly denied. Successful exploitation of either denial of service vulnerability could result in the Cisco CSG2 reloading or potentially hanging. Due to Cisco Bug ID CSCtg50821, the Cisco CSG2 may not automatically recover and may require a manual reload of the SAMI card by issuing the "hw-module module <x> reset" CLI command from the switch. Software Versions and Fixes =========================== When considering software upgrades, also consult http://www.cisco.com/go/psirt and any subsequent advisories to determine exposure and a complete upgrade solution. In all cases, customers should exercise caution to be certain the devices to be upgraded contain sufficient memory and that current hardware and software configurations will continue to be supported properly by the new release. If the information is not clear, contact the Cisco Technical Assistance Center (TAC) or your contracted maintenance provider for assistance. Each row of the Cisco IOS Software table (below) names a Cisco IOS release train. If a release train is vulnerable, then the earliest possible releases that contain the fix (along with the anticipated date of availability for each, if applicable) are listed in the "First Fixed Release" column of the table. The "Recommended Release" column indicates the releases which have fixes for all the published vulnerabilities at the time of this Advisory. A device running a release in the given train that is earlier than the release in a specific column (less than the First Fixed Release) is known to be vulnerable. Cisco recommends upgrading to a release equal to or later than the release in the "Recommended Releases" column of the table. +---------------------------------------------------------------+ | Major | Availability of Repaired Releases | | Release | | |------------+--------------------------------------------------| | Affected | | | 12.x-Based | First Fixed Release | | Releases | | |------------+--------------------------------------------------| | 12.0 - | 12.0 through 12.3 based releases are not | | 12.3 | affected | |------------+--------------------------------------------------| | Affected | First Fixed Release | | 12.4-Based |--------------------------------------------------| | Releases | DoS | Service Policy Bypass | | | Vulnerabilities | Vulnerability | |------------+------------------+-------------------------------| | | All 12.4(11)MD | | | | releases are not | All 12.4(11)MD releases are | | | affected. | affected. Migrate to a fixed | | | | release. | | | All 12.4(15)MD | | | | releases are not | All 12.4(15)MD releases are | | | affected. | affected. Migrate to a fixed | | | | release. | | | All 12.4(22)MD | | | 12.4MD | releases are not | All 12.4(22)MD releases are | | | affected. | affected. Migrate to a fixed | | | | release. | | | Releases prior | | | | to 12.4(24)MD1 | All 12.4(24)MD releases prior | | | are not | to 12.4(24)MD3 are affected. | | | affected. | | | | | First fixed in 12.4(24)MD3 | | | First fixed in | | | | 12.4(24)MD2 | | |------------+------------------+-------------------------------| | | | All 12.4(22)MDA releases | | | | prior to 12.4(22)MDA5 are | | | | affected. First fixed in 12.4 | | | No releases | (22)MDA5 | | 12.4MDA | affected. | | | | | All 12.4(24)MDA releases | | | | prior to 12.4(24)MDA3 are | | | | affected. First fixed in 12.4 | | | | (24)MDA3 | |------------+--------------------------------------------------| | Affected | | | 15.X-Based | First Fixed Release | | Releases | | |------------+--------------------------------------------------| | 15.0 - | 15.0 through 15.1 based releases are not | | 15.1 | affected | +---------------------------------------------------------------+ Cisco IOS Software for the CSG2 is located on Cisco Software Download center at the following location: Cisco Interfaces and Modules --> Cisco Services Modules --> Cisco Service Application Module for IP. Workarounds =========== There are no workarounds for these vulnerabilities. Obtaining Fixed Software ======================== Cisco has released free software updates that address these vulnerabilities. Prior to deploying software, customers should consult their maintenance provider or check the software for feature set compatibility and known issues specific to their environment. Customers may only install and expect support for the feature sets they have purchased. By installing, downloading, accessing or otherwise using such software upgrades, customers agree to be bound by the terms of Cisco's software license terms found at http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html, or as otherwise set forth at Cisco.com Downloads at http://www.cisco.com/public/sw-center/sw-usingswc.shtml. Do not contact psirt(a)cisco.com or security-alert(a)cisco.com for software upgrades. Customers with Service Contracts +------------------------------- Customers with contracts should obtain upgraded software through their regular update channels. For most customers, this means that upgrades should be obtained through the Software Center on Cisco's worldwide website at http://www.cisco.com. Customers using Third Party Support Organizations +------------------------------------------------ Customers whose Cisco products are provided or maintained through prior or existing agreements with third-party support organizations, such as Cisco Partners, authorized resellers, or service providers should contact that support organization for guidance and assistance with the appropriate course of action in regards to this advisory. The effectiveness of any workaround or fix is dependent on specific customer situations, such as product mix, network topology, traffic behavior, and organizational mission. Due to the variety of affected products and releases, customers should consult with their service provider or support organization to ensure any applied workaround or fix is the most appropriate for use in the intended network before it is deployed. Customers without Service Contracts +---------------------------------- Customers who purchase direct from Cisco but do not hold a Cisco service contract, and customers who purchase through third-party vendors but are unsuccessful in obtaining fixed software through their point of sale should acquire upgrades by contacting the Cisco Technical Assistance Center (TAC). TAC contacts are as follows. * +1 800 553 2447 (toll free from within North America) * +1 408 526 7209 (toll call from anywhere in the world) * e-mail: tac(a)cisco.com Customers should have their product serial number available and be prepared to give the URL of this notice as evidence of entitlement to a free upgrade. Free upgrades for non-contract customers must be requested through the TAC. Refer to http://www.cisco.com/en/US/support/tsd_cisco_worldwide_contacts.html for additional TAC contact information, including localized telephone numbers, and instructions and e-mail addresses for use in various languages. Exploitation and Public Announcements ===================================== The Cisco PSIRT is aware of public announcements of the service billing bypass vulnerability on some external blog sites. However the Cisco PSIRT is not aware of any malicious use of the vulnerabilities described in this advisory. These vulnerabilities were found by both internal testing and when handling customer support calls. Status of this Notice: FINAL ============================ THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS DOCUMENT AT ANY TIME. A stand-alone copy or Paraphrase of the text of this document that omits the distribution URL in the following section is an uncontrolled copy, and may lack important information or contain factual errors. Distribution ============ This advisory is posted on Cisco's worldwide website at: http://www.cisco.com/warp/public/707/cisco-sa-20110126-csg2.shtml In addition to worldwide web posting, a text version of this notice is clear-signed with the Cisco PSIRT PGP key and is posted to the following e-mail and Usenet news recipients. * cust-security-announce(a)cisco.com * first-bulletins(a)lists.first.org * bugtraq(a)securityfocus.com * vulnwatch(a)vulnwatch.org * cisco(a)spot.colorado.edu * cisco-nsp(a)puck.nether.net * full-disclosure(a)lists.grok.org.uk * comp.dcom.sys.cisco(a)newsgate.cisco.com Future updates of this advisory, if any, will be placed on Cisco's worldwide website, but may or may not be actively announced on mailing lists or newsgroups. Users concerned about this problem are encouraged to check the above URL for any updates. Revision History ================ +------------------------------------------------------------+ | Revision 1.0 | 2011-January-26 | Initial public release. | +------------------------------------------------------------+ Cisco Security Procedures ========================= Complete information on reporting security vulnerabilities in Cisco products, obtaining assistance with security incidents, and registering to receive security information from Cisco, is available on Cisco's worldwide website at http://www.cisco.com/en/US/products/products_security_vulnerability_policy.…. This includes instructions for press inquiries regarding Cisco security notices. All Cisco security advisories are available at http://www.cisco.com/go/psirt. +-------------------------------------------------------------------- Copyright 2010-2011 Cisco Systems, Inc. All rights reserved. +-------------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iF4EAREIAAYFAk1APx0ACgkQQXnnBKKRMNBE4QD/WfH2GXgAJub+4ech0JhHizBO 98PLNKENutVsJpa0eCUA/2hKwfofNSloEh7i5JZXrwKFcjgBYJcPnDa1W2JRHSfZ =EZt9 -----END PGP SIGNATURE-----

1 0

Network Naming
by Nick Olsen 26 Jan '11

26 Jan '11

Whats the rule of thumb for naming gear these days (routers,switches...etc). Or is there one? looks like level3 does something like interface.routertype.location.level3.net Nick Olsen Network Operations (855) FLSPEED x106

7 7