- NANOG - lists.nanog.org

Cisco Security Advisory: Multiple Vulnerabilities in the IOS FTP Server
by Cisco Systems Product Security Incident Response Team 09 May '07

09 May '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco Security Advisory: Multiple Vulnerabilities in the IOS FTP Server Advisory ID: cisco-sa-20070509-iosftp http://www.cisco.com/warp/public/707/cisco-sa-20070509-iosftp.shtml Revision 1.0 For Public Release 2007 May 09 1600 UTC (GMT) - --------------------------------------------------------------------- Contents ======== Summary Affected Products Details Vulnerability Scoring Details Impact Software Version and Fixes Workarounds Obtaining Fixed Software Exploitation and Public Announcements Status of this Notice: FINAL Distribution Revision History Cisco Security Procedures - --------------------------------------------------------------------- Summary ======= Multiple vulnerabilities exist in the Cisco IOS File Transfer Protocol (FTP) Server feature. These vulnerabilities include Denial of Service, improper verification of user credentials and the ability to read or write any file in the device's filesystem, including the device's saved configuration, which may include passwords or other sensitive information. The IOS FTP Server is an optional service that is disabled by default. Devices that are not specifically configured to enable the IOS FTP Server service are unaffected by these vulnerabilities. This vulnerability does not apply to the IOS FTP Client feature. This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20070509-iosftp.shtml Affected Products ================= Vulnerable Products +------------------ Cisco devices running IOS and configured for FTP server functionality are affected by these issues. IOS versions based on 11.3, 12.0, 12.1, 12.2, 12.3 and 12.4 contain the IOS FTP server feature. The IOS FTP server feature was removed via CSCsg16908. Only certain IOS releases based on the above IOS trains contain the IOS FTP server feature. For a device running Cisco IOS to be vulnerable, the following command must be present in the device configuration: ftp-server enable Products Confirmed Not Vulnerable +-------------------------------- Cisco devices that do not run IOS are not affected. Cisco IOS devices that do not have the FTP server feature enabled are not affected. Cisco IOS XR is not affected. No other Cisco devices are known to be affected. Details ======= Multiple vulnerabilities were discovered in the operation of the IOS FTP Server feature. They are documented as Cisco bug IDs: * CSCek55259 - Improper authorization checking in IOS FTP server * CSCse29244 - IOS reload when transferring files via FTP Due to the above issues with the IOS FTP server, the feature is being removed. Cisco is considering adding more fully-featured and secure FTP server functionality at a later date. The IOS FTP Server feature removal is addressed with Cisco bug ID CSCsg16908. Vulnerability Scoring Details ============================= Cisco is providing scores for the vulnerabilities in this advisory based on the Common Vulnerability Scoring System (CVSS). Cisco will provide a base and temporal score. Customers can then compute environmental scores to assist in determining the impact of the vulnerability in individual networks. Cisco PSIRT will set the bias in all cases to normal. Customers are encouraged to apply the bias parameter when determining the environmental impact of a particular vulnerability. CVSS is a standards based scoring method that conveys vulnerability severity and helps determine urgency and priority of response. 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 Cisco Bug IDs: CSCek55259 - Improper authorization checking in IOS FTP server CVSS Base Score: 10.0 Access Vector: Remote Access Complexity: Low Authentication: Not Required Confidentiality Impact: Complete Integrity Impact: Complete Availability Impact: Complete Impact Bias: Normal CVSS Temporal Score: 8.3 Exploitability: Functional Remediation Level: Official-Fix Report Confidence: Confirmed CSCse29244 - IOS reload when transferring files via FTP CVSS Base Score: 2.0 Access Vector: Remote Access Complexity: Low Authentication: Required Confidentiality Impact: None Integrity Impact: None Availability Impact: Complete Impact Bias: Normal CVSS Temporal Score: 1.7 Exploitability: Functional Remediation Level: Official-Fix Report Confidence: Confirmed Impact ====== Successful exploitation of these vulnerabilities may result in unauthorized users accessing the filesystem on the IOS device, a device restart, or remote code execution. Unauthorized users could retrieve or write the device's startup-config from the filesystem, which may contain information that could enable privilege escalation. Repeated exploitation of the vulnerabilities could lead to an extended Denial of Service (DoS). Software Version 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) describes a release train. If a given release train is vulnerable, then the earliest possible releases that contain the fix (the "First Fixed Release") and the anticipated date of availability for each are listed in the "Rebuild" and "Maintenance" columns. 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. The release should be upgraded at least to the indicated release or a later version (greater than or equal to the First Fixed Release label). Software releases that are not listed in the below table are not affected. For more information on the terms "Rebuild" and "Maintenance," consult the following URL: http://www.cisco.com/warp/public/620/1.html +---------------------------------------+ | Major | Availability of | | Release | Repaired Releases | |--------------+------------------------| | Affected | | | | 12.0-Based | Rebuild | Maintenance | | Release | | | |--------------+------------------------| | 12.0 | Vulnerable; migrate to | | | 12.2(40a) or later | |--------------+------------------------| | 12.0T | Vulnerable; migrate to | | | 12.2(40a) or later | |--------------+------------------------| | 12.0XC | Vulnerable; migrate to | | | 12.2(40a) or later | |--------------+------------------------| | 12.0XK | Vulnerable; migrate to | | | 12.2(40a) or later | |--------------+------------------------| | 12.0WC | 12.0(5) | | | | WC17 | | |--------------+----------+-------------| | Affected | | | | 12.1-Based | Rebuild | Maintenance | | Release | | | |--------------+------------------------| | 12.1 | Vulnerable; migrate to | | | 12.2(40a) or later | |--------------+------------------------| | 12.1T | Vulnerable; migrate to | | | 12.2(40a) or later | |--------------+------------------------| | 12.1XH | Vulnerable; migrate to | | | 12.2(40a) or later | |--------------+------------------------| | 12.1XM | Vulnerable; migrate to | | | 12.3(21)or later | |--------------+------------------------| | Affected | | | | 12.2-Based | Rebuild | Maintenance | | Release | | | |--------------+----------+-------------| | 12.2 | 12.2 | 12.2(46) | | | (40a) | | |--------------+------------------------| | 12.2T | Vulnerable; migrate to | | | 12.3(21) or later | |--------------+------------------------| | 12.2XA | Vulnerable; migrate to | | | 12.3(21) or later | |--------------+------------------------| | 12.2XG | Vulnerable; migrate to | | | 12.3(21) or later | |--------------+------------------------| | 12.2XT | Vulnerable; migrate to | | | 12.3(21) or later | |--------------+------------------------| | 12.2ZF | Vulnerable; migrate to | | | 12.4(12) or later | |--------------+------------------------| | 12.2ZH | Vulnerable; contact | | | TAC | |--------------+------------------------| | 12.2ZJ | Vulnerable; migrate to | | | 12.4(12) or later | |--------------+------------------------| | 12.2ZL | Vulnerable; contact | | | TAC | |--------------+------------------------| | 12.2ZN | Vulnerable; migrate to | | | 12.4(12) or later | |--------------+------------------------| | Affected | | | | 12.3-Based | Rebuild | Maintenance | | Release | | | |--------------+----------+-------------| | 12.3 | | 12.3(21) | |--------------+------------------------| | 12.3B | Vulnerable; migrate to | | | 12.4(12) or later | |--------------+------------------------| | 12.3T | Vulnerable; migrate to | | | 12.4(12) or later | |--------------+------------------------| | 12.3TPC | Vulnerable; contact | | | TAC | |--------------+------------------------| | 12.3XA | Vulnerable; contact | | | TAC | |--------------+------------------------| | 12.3XC | Vulnerable; contact | | | TAC | |--------------+------------------------| | 12.3XD | Vulnerable; migrate to | | | 12.4(12) or later | |--------------+------------------------| | 12.3XE | Vulnerable; contact | | | TAC | |--------------+------------------------| | 12.3XF | Vulnerable; migrate to | | | 12.4(12) or later | |--------------+------------------------| | 12.3XG | Vulnerable; contact | | | TAC | |--------------+------------------------| | 12.3XH | Vulnerable; migrate to | | | 12.4(12) or later | |--------------+------------------------| | 12.3XK | Vulnerable; migrate to | | | 12.4(12) or later | |--------------+------------------------| | 12.3XQ | Vulnerable; migrate to | | | 12.4(12) or later | |--------------+------------------------| | 12.3XR | Vulnerable; contact | | | TAC | |--------------+------------------------| | 12.3XS | Vulnerable; migrate to | | | 12.4(12) or later | |--------------+------------------------| | 12.3XX | 12.3(8) | | | | XX2d | | |--------------+------------------------| | 12.3YA | Vulnerable; migrate to | | | 12.4(12) or later | |--------------+------------------------| | 12.3YD | Vulnerable; migrate to | | | 12.4(11)T or later | |--------------+------------------------| | 12.3YG | Vulnerable; migrate to | | | 12.4(11)T or later | |--------------+------------------------| | 12.3YH | Vulnerable; migrate to | | | 12.4(11)T or later | |--------------+------------------------| | 12.3YI | Vulnerable; migrate to | | | 12.4(11)T or later | |--------------+------------------------| | 12.3YK | Vulnerable; migrate to | | | 12.4(11)T or later | |--------------+------------------------| | 12.3YM | Vulnerable; contact | | | TAC | |--------------+------------------------| | 12.3YS | Vulnerable; migrate to | | | 12.4(11)T or later | |--------------+------------------------| | 12.3YT | Vulnerable; migrate to | | | 12.4(11)T or later | |--------------+------------------------| | 12.3YZ | Vulnerable; contact | | | TAC | |--------------+------------------------| | Affected | | | | 12.4-Based | Rebuild | Maintenance | | Release | | | |--------------+----------+-------------| | | 12.4 | | | | (10b) | | | |----------+-------------| | 12.4 | 12.4(3g) | | | |----------+-------------| | | 12.4(7d) | | | |----------+-------------| | | 12.4(8c) | 12.4(12) | |--------------+------------------------| | 12.4SW | Vulnerable; contact | | | TAC | |--------------+------------------------| | | 12.4(4) | | | | T6 | | | |----------+-------------| | 12.4T | 12.4(6) | | | | T6 | | | |----------+-------------| | | 12.4(9) | 12.4(11)T | | | T2 | | |--------------+------------------------| | 12.4XA | Vulnerable; migrate to | | | 12.4(6)T6 or later | |--------------+------------------------| | 12.4XC | 12.4(4) | | | | XC6 | | |--------------+----------+-------------| | 12.4XD | 12.4(4) | | | | XD4 | | |--------------+----------+-------------| | 12.4XE | 12.4(6) | | | | XE2 | | +---------------------------------------+ Workarounds =========== Customers may disable the use of the IOS FTP Server feature by adding the following command to the device configuration: no ftp-server enable Additional mitigations that can be deployed on Cisco devices within the network are available in the Cisco Applied Intelligence companion document for this advisory: http://www.cisco.com/warp/public/707/cisco-air-20070509-iosftp.shtml Alternative File Transfer Mechanisms +----------------------------------- Cisco IOS supports multiple methods for transferring files to and from the device. One such method is Secure Copy (SCP). SCP is supported on Cisco IOS images that support strong cryptography. More information on the SCP feature can be found at the following url: http://www.cisco.com/en/US/products/s6350/products_configuration_guide_chap… Another alternative is using the Trivial File Transfer Protocol (TFTP) server in IOS. Information on configuring the TFTP server can be found here: http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_configurati… If disabling the IOS FTP Server is not feasible, customers may limit FTP access to the device via one of several mechanisms detailed below. Infrastructure ACLs (iACL) +------------------------- Although it is often difficult to block traffic transiting your network, it is possible to identify traffic which should never be allowed to target your infrastructure devices and block that traffic at the border of your network. Infrastructure ACLs are considered a network security best practice and should be considered as a long-term addition to good network security as well as a workaround for this specific vulnerability. The ACL example shown below should be included as part of the deployed infrastructure access-list which will protect all devices with IP addresses in the infrastructure IP address range. A sample access list for devices running Cisco IOS is below: !--- Permit FTP services from trusted hosts destined !--- to infrastructure addresses. access-list 150 permit tcp TRUSTED_HOSTS MASK INFRASTRUCTURE_ADDRESSES MASK eq 21 access-list 150 permit tcp TRUSTED_HOSTS MASK INFRASTRUCTURE_ADDRESSES MASK eq 20 !--- Deny FTP packets from all other sources destined to infrastructure addresses. access-list 150 deny tcp any INFRASTRUCTURE_ADDRESSES MASK eq 21 access-list 150 deny tcp any INFRASTRUCTURE_ADDRESSES MASK eq 20 !--- Permit all other traffic to transit the device. access-list 150 permit IP any any interface serial 2/0 ip access-group 150 in The white paper entitled "Protecting Your Core: Infrastructure Protection Access Control Lists" presents guidelines and recommended deployment techniques for infrastructure protection access lists. This white paper can be obtained here: http://www.cisco.com/warp/public/707/iacl.html Receive ACLs (rACL) +------------------ For distributed platforms, Receive ACLs may be an option starting in Cisco IOS Software Versions 12.0(21)S2 for the 12000 (GSR), 12.0(24)S for the 7500, and 12.0(31)S for the 10720. The Receive ACL protects the device from harmful traffic before the traffic can impact the route processor. Receive ACLs are designed to only protect the device on which it is configured. On the 12000, transit traffic is never affected by a receive ACL. Because of this, the destination IP address "any" used in the example ACL entries below only refer to the router's own physical or virtual IP addresses. On the 7500 and 10720, transit traffic with IP options set will be subject to the Receive ACL and permitted or denied accordingly. Receive ACLs are considered a network security best practice, and should be considered as a long-term addition to good network security, as well as a workaround for this specific vulnerability. The white paper entitled "GSR: Receive Access Control Lists" will help you identify and allow legitimate traffic to your device and deny all unwanted packets: http://www.cisco.com/warp/public/707/racl.html. The following is the receive path ACL written to permit this type of traffic from trusted hosts: !--- Permit FTP from trusted hosts allowed to the RP. access-list 151 permit tcp TRUSTED_ADDRESSES MASK any eq 21 access-list 151 permit tcp TRUSTED_ADDRESSES MASK any eq 20 !--- Deny FTP from all other sources to the RP. access-list 151 deny tcp any any eq 21 access-list 151 deny tcp any any eq 20 !--- Permit all other traffic to the RP. !--- according to security policy and configurations. access-list 151 permit ip any any !--- Apply this access list to the 'receive' path. ip receive access-list 151 Control Plane Policing (CoPP) +---------------------------- The Control Plane Policing (CoPP) feature may be used to mitigate these vulnerabilities. In the following example, only FTP traffic from trusted hosts and with 'receive' destination IP addresses is permitted to reach the route processor (RP). It should be noted that dropping traffic from unknown or untrusted IP addresses may affect hosts with dynamically assigned IP addresses from connecting to the Cisco IOS device. access-list 152 deny tcp TRUSTED_ADDRESSES MASK any eq 21 access-list 152 deny tcp TRUSTED_ADDRESSES MASK any eq 20 access-list 152 permit tcp any any eq 20 access-list 152 permit tcp any any eq 21 access-list 152 deny ip any any ! class-map match-all COPP-KNOWN-UNDESIRABLE match access-group 152 ! ! policy-map COPP-INPUT-POLICY class COPP-KNOWN-UNDESIRABLE drop ! control-plane service-policy input COPP-INPUT-POLICY In the above CoPP example, the ACL entries that match the exploit packets with the "permit" action result in these packets being discarded by the policy-map "drop" function, while packets that match the "deny" action are not affected by the policy-map drop function. CoPP is available in Cisco IOS release trains 12.0S, 12.2SX, 12.2S, 12.3T, 12.4, and 12.4T. Additional information on the configuration and use of the CoPP feature can be found at the following URL: http://www.cisco.com/en/US/products/ps6642/products_white_paper0900aecd804f… Obtaining Fixed Software ======================== Cisco will make free software available to address this vulnerability for affected customers. This advisory will be updated as fixed software becomes available. 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/public/sw-license-agreement.html, or as otherwise set forth at Cisco.com Downloads at http://www.cisco.com/public/sw-center/sw-usingswc.shtml. Do not contact either "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 agreement 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 who do not hold a Cisco service contract and customers who purchase through third-party vendors but are unsuccessful at obtaining fixed software through their point of sale should get their 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 Have your product serial number available and give the URL of this notice as evidence of your entitlement to a free upgrade. Free upgrades for non-contract customers must be requested through the TAC. Refer to http://www.cisco.com/warp/public/687/Directory/DirTAC.shtml for additional TAC contact information, including special localized telephone numbers and instructions and e-mail addresses for use in various languages. Exploitation and Public Announcements ===================================== The Cisco PSIRT is not aware of any public announcements or malicious use of the vulnerability described in this advisory. This vulnerability was reported to Cisco by a customer. 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. Distribution ============ This advisory is posted on Cisco's worldwide website at: http://www.cisco.com/warp/public/707/cisco-sa-20070509-iosftp.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-teams(a)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 | | Initial | | 1.0 | 2007-May-09 | 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. - --------------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (SunOS) iD8DBQFGQdbf8NUAbBmDaxQRAm0NAJ9Afj7rEDMQO+PolVME5taZE4R37ACfRGhS coBHHAO2nUFEBFKxuUDJH4Q= =phUK -----END PGP SIGNATURE-----

1 0

Omaha, NE Carrier Hotels???
by Robert Boyle 09 May '07

09 May '07

Omaha is right in the middle of the US and it seems to be a point on most carriers' national backbone maps. There has to be some type of carrier hotel there somehere, but I can't seem to find it. Can anyone provide insight on the 60 Hudson or One Wilshire or 111 8th or Westin of Omaha? Thanks! -Robert Tellurian Networks - Global Hosting Solutions Since 1995 http://www.tellurian.com | 888-TELLURIAN | 973-300-9211 "Well done is better than well said." - Benjamin Franklin

2 1

F/OSS SNMP tools (was Re: Cacti 0.8.6j Released)
by Kevin Blackham 09 May '07

09 May '07

You only need to worry about vendor MIBs if you're trying to query/monitor something vendor-specific. Standard stuff like ifInOctets and ifDescr are included in everything. I like to either read through MIBs by hand, or load em in a MIB browser (like mbrowse or use vendor C's snmp explorer tool) to search/dig into a table/value that interests me, then snmpwalk a base OID to find instances and enter the pattern directly into whatever collector tool I'm using that week. If you're trying to use vendor MIBs, you also have to deal with dependencies and conflicts, so prepare for some hair-pulling hell. I'm still on the hunt for a decent F/OSS trap receiver that will allow me to just load up MIBs, and have some simple config/UI method for selecting trigger actions/notifications, maybe some filtering and unknown-trap handling etc. Trying to snag traps with snmptrapd and parsing text output is uncooperative. Inconsistent formatting of key/value etc. On 5/8/07, Matt Palmer <mpalmer(a)hezmatt.org> wrote: > > > [If people think this is off-topic, please let me know and I'll take it to > private mail with Travis.] > > On Tue, May 08, 2007 at 07:32:18PM -0500, Travis H. wrote: > > Hey folks, I am following up to an ancient email because I'm curious > > if anyone has some SNMP-related resources. Basically, there's a lot > > of how-to or manpage sort of information, but I'm still unclear on > > what an MIB actually _is_, > > It's an overloaded term. Technically, I think it's the values which you > can > query by OID in an agent, but most people use the term to describe the > textual description of the OIDs and what they mean, especially when they > talk about "downloading a MIB". > > > what problem ASN.1 actually solves, > > How to encode the queries and responses. Unless you're actually writing > an > agent or low-level manager library, ignore it. Seriously, you don't need > the headache. > > > and > > more to the point how the whole shebang (I'm using net-snmpd) is > > typically used. > > Agent on device provides values, management app(s) collect data by polling > (and possibly via traps), sysadmin gets to go home on time for once. > > > I believe that what I need to do is get any/all MIBs for all "entities" > > (typically networking hardware devices) that I want to monitor, and > import > > them into the net-snmp configuration somehow, and then software that > calls > > on net-snmp can access the information from the devices. > > > > Is this accurate? > > Kinda-sorta. You don't actually need a MIB to be able to query a device > -- > you can, in theory, just walk it from the root and get all the OIDs (and > their values) that the agent provides. However, since all you'll get are > massive quantities of numbers, that'll be fairly useless, and the MIB file > you refer to will help you (and your agent software) decode the OIDs into > something more readable. That being said, if you only want to monitor a > few > OIDs, and you know the OIDs already, then the MIB is unnecessary. > > Where you put the MIBs to net-snmp can find them depends on where net-snmp > has been told to look for them. /usr/share/snmp/mibs is where they go on > my > system, but $DEITY knows where they might end up on some Unices. > > > Will I need to import MIBs to every net mgmt application? Should they > > If they use different OIDs, and you want to be able to use them easily, > yes. > This "using different OIDs" thing is depressingly common -- although there > are RFC standards for a lot of the "common" types of networking data, a > combination of "the RFCs don't define all our statistics" and NIH means > that > a lot of vendor equipment does it's own SNMP thing. > > > be carefully accounted for and synchronized, or can I treat them like > > a typical configuration file, where it is obvious if I need it and I > > get them as needed? > > They're not critical to the operation of the whole thing, merely the > comprehensibility, so don't get too obsessed over your MIBs. > > - Matt > > -- > Just because we work at a University doesn't mean we're surrounded by > smart > people. > -- Brian Kantor, in the monastery >

1 0

RE: Google wants to be your Internet
by michael.dillon＠bt.com 09 May '07

09 May '07

> We also see this with extranet/supply-chain-type connectivity > between large companies who have overlapping address space, > and I'm afraid it's only going to become more common as more > of these types of relationships are established. Fortunately, IP addresses are not intended for use on the Internet. Rather, they are intended for use with Internet Protocol (IP) implementations. That's why the RIRs, in alignment with RFC 2050, section 3(a), do give out IP address allocations to organizations who are connected to extranet-type networks. If you read RFC 1918, section 2, category 3, you will see that this is consistent. So if the power companies want to assign a unique network address to all power meters then there is no good reason to stop them. After all, it is consistent with the goals of the original IP designers to address every light switch and toaster. Just remember, IP addresses are *NOT* Internet addresses. They are Internet Protocol addresses. Connection to the Internet and public announcement of prefixes are totally irrelevant. --Michael Dillon

7 7

Google wants to be your Internet
by Mark Boolootian 09 May '07

09 May '07

Cringley has a theory and it involves Google, video, and oversubscribed backbones: http://www.pbs.org/cringely/pulpit/2007/pulpit_20070119_001510.html

39 74

Load balancing
by dan 08 May '07

08 May '07

Hello, I currently have 2 routers with a single gigabit link (and corresponding internal BGP session) between them. router1 <---------gigabit------->router2 Simple setup. Now that we have reached the limit on this gigabit link, we are adding a second gigabit link between the same 2 routers, and we wish to load balance across them. Traffic is about 5:1 ratio of out:in. router2 has bgp sessions with several upstreams, and router 1 has bgp sessions with further internal routers. What is the best way to balance across these 2 links? --- dan

6 5

barak-online.net icmp performance vs. traceroute/tcptraceroute, ssh, ipsec
by Joe Maimon 08 May '07

08 May '07

I was wondering if someone could shed some light on this little curiosity. US ping (sourced from different networks, including cable customer in NE) to the consumer grade residental israel dsl cpe (currently cisco 871) look really nice and sweet, gotomypc works alright, consumer is enjoying overall internet experience. vnc from customer to US is a non-starter. ssh from US almost never works. ipsec performance is horrid. traceroute/tcptraceroute show packet loss and MUCH higher rtt than the corresponding direct pings on the reported hop entries. Is this some sort of massaging or plain just "faking it"? Or is such things merely net-urban myth? Here is a traceroute snippet 8 dcr3-ge-0-2-1.newyork.savvis.net (204.70.193.98) 31.008 ms 31.539 ms 31.248 ms 9 208.173.129.14 (208.173.129.14) 62.847 ms 31.095 ms 30.690 ms 10 barak-01814-nyk-b2.c.telia.net (213.248.83.2) 30.529 ms 30.820 ms 30.495 ms 11 * * po1-3.bk3-bb.013bk.net (212.150.232.214) 277.722 ms 12 gi2-1.bk6-gw.013bk.net (212.150.234.94) 223.398 ms 235.616 ms 214.551 ms 13 * * gi11-24.bk6-acc3.013bk.net (212.29.206.37) 227.259 ms 14 212.29.206.60 (212.29.206.60) 244.369 ms013bk.net * 246.271 ms 15 89.1.148.230.dynamic.barak-online.net (89.1.148.230) 251.923 ms 256.817 ms * Compared to ICMP echo root@jml03:~# ping 89.1.148.230 PING 89.1.148.230 (89.1.148.230) 56(84) bytes of data. 64 bytes from 89.1.148.230: icmp_seq=1 ttl=240 time=190 ms --- 89.1.148.230 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 190.479/190.479/190.479/0.000 ms root@jml03:~# ping 89.1.148.230 PING 89.1.148.230 (89.1.148.230) 56(84) bytes of data. 64 bytes from 89.1.148.230: icmp_seq=1 ttl=240 time=186 ms 64 bytes from 89.1.148.230: icmp_seq=2 ttl=240 time=196 ms 64 bytes from 89.1.148.230: icmp_seq=3 ttl=240 time=187 ms 64 bytes from 89.1.148.230: icmp_seq=4 ttl=240 time=181 ms 64 bytes from 89.1.148.230: icmp_seq=5 ttl=240 time=184 ms 64 bytes from 89.1.148.230: icmp_seq=6 ttl=240 time=190 ms --- 89.1.148.230 ping statistics --- 6 packets transmitted, 6 received, 0% packet loss, time 5001ms rtt min/avg/max/mdev = 181.572/187.756/196.277/4.685 ms root@jml03:~# ping 212.29.206.60 PING 212.29.206.60 (212.29.206.60) 56(84) bytes of data. 64 bytes from 212.29.206.60: icmp_seq=1 ttl=241 time=179 ms 64 bytes from 212.29.206.60: icmp_seq=2 ttl=241 time=171 ms 64 bytes from 212.29.206.60: icmp_seq=3 ttl=241 time=171 ms --- 212.29.206.60 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2001ms rtt min/avg/max/mdev = 171.388/174.375/179.968/3.972 ms root@jml03:~# ping 212.29.206.37 PING 212.29.206.37 (212.29.206.37) 56(84) bytes of data. 64 bytes from 212.29.206.37: icmp_seq=1 ttl=242 time=177 ms 64 bytes from 212.29.206.37: icmp_seq=2 ttl=242 time=176 ms 64 bytes from 212.29.206.37: icmp_seq=3 ttl=242 time=175 ms --- 212.29.206.37 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 1999ms rtt min/avg/max/mdev = 175.412/176.516/177.187/0.858 ms Joe

8 21

Foundry/Cisco MM 100Base-T SFP in Philly?
by Robert Boyle 08 May '07

08 May '07

Hello all, Does anyone have a multi-mode 100Mbit SFP which I can borrow or purchase in the Philadelphia area? Preferably at 401 N. Broad, but anywhere in the Philly area will do. Tonight would be nice. Tomorrow will be fine too. It is for a Foundry XMR so I need the new dual-mode SFPs which work in a GigE port at 100Mbit. I will be happy to pay for or replace the equipment or to return the favor in any way possible. We are doing an upgrade and I didn't document that we have one MM fiber connection here so I didn't bring an SFP. If so, please call my cell 973-214-3626. Thanks! -Robert Tellurian Networks - Global Hosting Solutions Since 1995 http://www.tellurian.com | 888-TELLURIAN | 973-300-9211 "Well done is better than well said." - Benjamin Franklin

1 0

BOGON Announcement question
by Jason Lewis 07 May '07

07 May '07

I'm seeing this announced at CIXP Collector: CIXP Prefix: 128.0.0.0/2 Last update time: 2007-04-27 07:36:30Z Peer: 192.65.185.140 Origin: 29222 My question is, why am I not seeing more issues because of the announcement? Is it just not propagating out of the exchange? It's been announced for a few days and only seems to appear at the exchange. jas

9 10

RE: barak-online.net icmp performance vs. traceroute/tcptraceroute, ssh, ipsec
by Scott Weeks 07 May '07

07 May '07

--- ltd(a)interlink.com.au wrote: From: "Lincoln Dale" <ltd(a)interlink.com.au> To: "'Joe Maimon'" <jmaimon(a)ttec.com> > The standard control plane arguments dont apply > when the pattern holds all the way through to > equipment under your {remote-}control. : : it most certainly does. lets use an example : network of: : F : | :A---B---C---D---E : | : G : : : you are looking at ICMP/traceroute responses : through sending traffic to/from A & E. : :for all you know, there may be an ICMP DDoS attack What about something as simplistic as tcptraceroute? It won't give you path MTU info, but there're other tools that can. scott

3 2