March 2004 - Test - lists.nanog.org

FW: hey had eric sent you
by Riley, Marty 19 Aug '04

19 Aug '04

I'm running short on theories and options, so I thought I would see if any other ISPs have seen this problem on your network(s). If so, what was the cure? mjr -----Original Message----- The Unknown problem. Symptoms: At random times dialup, dedicated, & internal network users are unable to pass TCP traffic to off network sites. ICMP and UDP appears to be uneffected by the outage which lasts anywhere from 2 to 5 minutes. The problem appears to be wide spread with similar reports from WVNET and other ISPS. nTelos is experiencing a similar problem but we have yet to confirm it is the same. Problem has changed in it's action but remained similar enough to consider it the same problem. Effected Platforms: Windows 2000 Pro, XP Home, XP Pro, & 2003 Server. Uneffected Platforms: Unix, MacOS (?) History: During the week of 2/9/04 the call center started recieving reports of users being unable to connect to sites off the CityNet network. Sites hosted on the internal network are uneffected by the outage. Initally it was thought to be a Internet Explorer problem possably caused by the KB832894 / IE SP1 or other updates but after further investigation it was found that Mozilla users were encountering the same problem. After several days of testing it was determined that during the outage any TCP session started on any port would fail. TCP sessions started before the outage continue to work and show no ill effects from the outage. After logging connection attempts at various intervals on many machines there appears to be no sort of pattern in the outages. Most machines encounter the problem, some more than others and a few do not encounter it at all. The duration and frequency of the outage is very fluid. During an outage, we can verify that the packet does seem to leave and reenter the network: Mar 5 22:28:04 pittpa-chaswv-ds3 17083: SLOT 2:6d20h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.14.174(3376) -> 216.41.224.3(80), 1 packet Mar 5 22:28:09 pittpa-chaswv-ds3 17084: SLOT 1:6d20h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.14.174(3376), 1 packet Mar 5 22:28:09 pittpa-chaswv-ds3 17085: SLOT 2:6d20h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.14.174(3378) -> 216.41.224.3(80), 1 packet Mar 5 22:28:09 pittpa-chaswv-ds3 17086: SLOT 1:6d20h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.14.174(3378), 1 packet Mar 5 22:33:24 pittpa-chaswv-ds3 17089: SLOT 1:6d20h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.14.174(3378), 7 packets Mar 5 22:33:24 pittpa-chaswv-ds3 17090: SLOT 1:6d20h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.14.174(3376), 17 packets Mar 5 22:33:58 pittpa-chaswv-ds3 17092: SLOT 2:6d20h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.14.174(3378) -> 216.41.224.3(80), 7 packets Mar 5 22:33:58 pittpa-chaswv-ds3 17093: SLOT 2:6d20h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.14.174(3376) -> 216.41.224.3(80), 18 packets Mar 5 00:58:30 pittpa-clarwv-ds3 16062: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3183) -> 216.41.224.3(80), 1 packet Mar 5 00:58:30 pittpa-clarwv-ds3 16063: SLOT 1:5d22h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.23.23(3183), 1 packet Mar 5 01:03:28 pittpa-clarwv-ds3 16067: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3217) -> 216.41.224.3(80), 1 packet Mar 5 01:03:28 pittpa-clarwv-ds3 16068: SLOT 1:5d22h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.23.23(3217), 1 packet Mar 5 01:03:34 pittpa-clarwv-ds3 16069: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3228) -> 216.41.224.3(80), 1 packet Mar 5 01:03:34 pittpa-clarwv-ds3 16070: SLOT 1:5d22h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.23.23(3228), 1 packet Mar 5 01:03:39 pittpa-clarwv-ds3 16072: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3239) -> 216.41.224.3(80), 1 packet Mar 5 01:03:47 pittpa-clarwv-ds3 16073: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3183) -> 216.41.224.3(80), 74 packets Mar 5 01:04:13 pittpa-clarwv-ds3 16075: SLOT 1:5d22h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.23.23(3183), 72 packets Mar 5 01:08:46 pittpa-clarwv-ds3 16078: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3218) -> 216.41.224.3(80), 4 packets Mar 5 01:08:46 pittpa-clarwv-ds3 16079: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3217) -> 216.41.224.3(80), 3 packets Mar 5 01:08:46 pittpa-clarwv-ds3 16080: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3221) -> 216.41.224.3(80), 19 packets Mar 5 01:08:46 pittpa-clarwv-ds3 16081: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3228) -> 216.41.224.3(80), 5 packets Mar 5 01:08:46 pittpa-clarwv-ds3 16082: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3229) -> 216.41.224.3(80), 6 packets Mar 5 01:08:46 pittpa-clarwv-ds3 16083: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3236) -> 216.41.224.3(80), 9 packets Mar 5 01:08:47 pittpa-clarwv-ds3 16084: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3233) -> 216.41.224.3(80), 12 packets Mar 5 01:08:47 pittpa-clarwv-ds3 16085: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3239) -> 216.41.224.3(80), 21 packets Mar 5 01:09:12 pittpa-clarwv-ds3 16087: SLOT 1:5d22h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.23.23(3239), 19 packets Mar 5 01:09:12 pittpa-clarwv-ds3 16088: SLOT 1:5d22h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.23.23(3228), 4 packets Mar 5 01:09:12 pittpa-clarwv-ds3 16089: SLOT 1:5d22h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.23.23(3217), 2 packets Mar 5 01:09:12 pittpa-clarwv-ds3 16091: SLOT 1:5d22h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.23.23(3218), 3 packets Mar 5 01:09:13 pittpa-clarwv-ds3 16092: SLOT 1:5d22h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.23.23(3221), 17 packets Mar 5 01:09:13 pittpa-clarwv-ds3 16093: SLOT 1:5d22h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.23.23(3229), 5 packets Mar 5 01:09:13 pittpa-clarwv-ds3 16094: SLOT 1:5d22h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.23.23(3236), 7 packets Mar 5 01:09:13 pittpa-clarwv-ds3 16096: SLOT 1:5d22h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.23.23(3233), 9 packets Network analysis showed significant amounts of spoofed multicast traffic and odd arp traffic. 10:17:16.416222 IP 192.168.1.1.1900 > 239.255.255.250.1900: udp 278 10:17:16.421886 IP 192.168.1.1.1900 > 239.255.255.250.1900: udp 334 10:17:16.423873 IP 192.168.1.1.1900 > 239.255.255.250.1900: udp 262 10:17:16.426948 IP 192.168.1.1.1900 > 239.255.255.250.1900: udp 254 10:17:16.432095 IP 192.168.1.1.1900 > 239.255.255.250.1900: udp 298 10:17:16.435921 IP 192.168.1.1.1900 > 239.255.255.250.1900: udp 274 10:17:16.439959 IP 192.168.1.1.1900 > 239.255.255.250.1900: udp 328 10:17:16.445317 IP 192.168.1.1.1900 > 239.255.255.250.1900: udp 326 10:17:16.449688 IP 192.168.1.1.1900 > 239.255.255.250.1900: udp 330 10:17:16.463537 IP 192.168.1.1.1900 > 239.255.255.250.1900: udp 322 Steps were taken to elminiate the spoofed traffic on the routers and access servers in the form of ACLs and filter lists. Neither have eliminiated the problem... but to what extent they might have helped has yet to be determined. The problem is still occuring, for some users the duration of the outage seems to have shortened other users notice no difference. It is not yet known if the filtering on the routers and access servers or the conversion to the 10.x.x.x network has made any difference. We should have a better idea in the upcoming days. What Doesn't help: Removing windows updates. Turning off XP firewall. Searching for malware. (SpyBot-SD, Adaware) Virus scanning (Various softwares) Specifying dns servers. Reinstalling windows.

7 6

Load Balancing Multiple DS3s (outgoing) on a 7500
by Drew Weaver 20 May '04

20 May '04

Does anyone know of an article, or documentation regarding load balancing the traffic on 3 or more FastEthernet interfaces on the outgoing direction? Right now we're running BGP internally, and the routes that are being chosen based upon the final BGP decision step or what I like to call the 'IP address tie breaker' which is not always optimal. We have a cisco 7500 that is connected to 4 other Cisco 7500s which each have 45Mbps ds3s to the Internet, we would like to load balance the outgoing traffic across all 4 of these 7500s, can anyone shine any advice my way? I noticed that there are instructions on Cisco's site regarding doing LB on 12000s. Anyways thanks in advance ;-) -Drew

10 11

RE: Cisco Router best for full BGP on a sub 5K bidget 7500 7200 or other vendor ?
by Alexander Hagen 27 Apr '04

27 Apr '04

Well this has been quite a stimulating discussion! It appears the sweet spot would be as follows: 7507 Dual A/C Power.....~ 750 Dual RSP4 with 256 MEM .~900 VIP2-50 with 128 MB RAM.~400 Now this can all be obtained for about 2000.00 perhaps... The problem is the Fast Ethernet Interfaces CX-FEIP-2TX ( 400?) PA-FE-TX (250) The PA-2FE-TX is about 1600.00- better to get a second PA-FE-TX with second VIP2-50 Now why is the CX-FEIP-2TX so much cheaper than the PA-2FE-TX ????? Alexander Hagen Etheric Networks Incorporated, A California Corporation 527 Sixth Street No 371261 Montara CA 94037 Main Line: (650)-728-3375 Direct Line: (650) 728-3086 Cell: (650) 740-0650 (Does not work at our office in Montara) Home: (Emgcy or weekends) 650-728-5820 fax: (650) 240-1750 http://www.etheric.net -----Original Message----- From: Roldan, Brad [mailto:BRoldan@covad.com] Sent: Sunday, February 08, 2004 12:40 PM To: Alexander Hagen Subject: RE: Cisco Router best for full BGP on a sub 5K bidget 7500 7200 or other vendor ? Alex, I used the RS3000 extensively in a previous life for a Metro E provider. These are great Layer 2 switches. When it comes to Layer 3 services, Riverstone has been lacking. The last firmware revision I looked at was in the 9.x series. At that time, routing protocols, such as BGP, were still evolving in terms of basic support. For instance, at the time BGP communities were not supported. I don't know hoe Riverstone's support for Layer 3 routing has evolved since 9.x. Hope this helps. Brad -- Covad Communications 2510 Zanker Road San Jose, CA 95131 +1-408-434-2048 broldan(a)covad.com -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Alexander Hagen Sent: Saturday, February 07, 2004 5:49 AM To: nanog(a)merit.edu Subject: RE: Cisco Router best for full BGP on a sub 5K bidget 7500 7200 or other vendor ? Montara is between Pacifica and Half Moon Bay. Everyone has a different perspective - but all valid. However I would say if you are going to go Cisco - and you have no other BGP gear under Smartnet - you might look at the 3725 maxed out. It is new and you will get support and available for 5,000.00 online, equipped with two onboard Fast Ethernet ports. You are likely to buy only single FE modules at 350.00 rather than 2FE's which are hard to find for cheap, and upgrading memory to 256 Megs DRAM is only an addl 150.00. With that said.... I found a rather stupid article that gave the Riverstone high marks. http://www.nwfusion.com/reviews/2003/0714rev.html?page=1 http://research.mwjournal.com/data/jspdetail?id=1025118725_252&type=PROD &src=mwave&x=841473789 The RS 3000 has 20 gbps non blocking. I am likely to go with the Riverstone. I think I can get it for under 2K with 24 10/100 ports, 256 MB of memory, and 20 gbps non blocking switching fabric. Although I will likely place a Cisco box behind it (eventually) for IPSec and the like. Platform Features Feature-rich Wire-speed Services * IP routing, unicast, and multicast * Routing in hardware on each line card * LSR and LER MPLS support in hardware * RSVP-TE and LDP label distribution and signaling * MPLS traffic engineering support * Security (ACLs, L2 filters) * Layer 4 application-flow switching and QoS * Network Address Translation (NAT) * Hardware-based Rate Limiting * Jumbo Frame support * VLANs based on port or protocol * Server Load Balancing (LSNAT) Highly Fault Tolerant * Redundant power supplies (RS 3000) * Hot-swappable media modules * Standards-based VRRP * Layer 2 and 3 redundant protocol support Extensive Management * Wire-speed full RMON/RMON2 * SNMP manageable * SSH * RADIUS * TACACS+ * RS-232 (out-of-band management) * Command Line Interface (CLI) Interfaces 10/100 Base-TX 100 Base-FX 1000 Base-SX 1000 Base-LX 1000 Base-TX 1000 Base-LH (70Km) T1/E1 T3/E3 ATM-OC-3c Up to 4,096 VLANs Up to 256,000 routes Up to 20,000 security/access control filters Up to 512,000 Layer 4 application flows Up to 256,000 Layer 2 MAC addresses RS 1000: 12 Gbps non-blocking switching fabric RS 1000: 4.6 million packets per second routing throughput RS 3000: 20 Gbps non-blocking switching fabric RS 3000: 9.5 million packets per second routing throughput MTBF (predicted) > 200,000 hours Physical Dimensions: 3.25" H x 17" W x 18.5" D (8.25 cm x 43.2 cm x 47 cm) Weight: 20 lbs. (9.1 kg) Environmental Specifications Operating Temp: +0º to +40ºC (32º to 104ºF) Non-operating Temp: -40º to +70ºC (-40º to 158ºF) Operating Relative 10% to 90% (non-condensing) Humidity: Non-operating 5% to 95% maximum Relative Humidity: (non-condensing) Altitude, Operating 10,000 ft (3,000 m) maximum and Non-operating: Shock and Vibration:GR63 Power Requirements AC Input current: 3.0 A - 1.5 A AC Input voltage: 100 to 240 VAC AC Frequency: 50 to 60 Hz DC Input current: 8.0 A DC Input voltage: -48 to -60 VAC Agency Standards and Specifications Safety: Certified UL1950, CSA C22.2 No. 950, EN60950, IEC950, and 72/73/EEC Electromagnetic Compliant with the requirements of compatibility: FCC Part 15, CSA C108.8, EN55022, VCCI, EN50082-1, and 89/336/EEC Standards Supported IETF Standards Support RFC No. Title RFC 768 UDP RFC 783 TFTPv2 RFC 791 IP RFC 792 ICMP RFC 793 TCP RFC 826 ARP RFC 854 Telnet RFC 951 BootP RFC 1058 RIP v1 RFC 1075 DVMRP RFC 1112 Host Extensions for IP Multicasting RFC 1157 SNMPv1 RFC 1195 Use of OSI IS-IS for Routing in TCP/IP and Dual Environments RFC 1245 OSPF Protocol Analysis RFC 1246 Experience with the OSPF Protocol RFC 1256 ICMP Router Discover Message RFC 1265 BGP Protocol Analysis RFC 1266 Experience with the BGP Protocol RFC 1267 BGP-3 RFC 1269 Definitions of Managed Objects for BGP-3 RFC 1332 PPP IPCP RFC 1349 Type of Service in the Internet Protocol Suite RFC 1397 Default Route Advertisement in BGP-2 and BGP-3 RFC 1403 BGP OSPF Interaction RFC 1519 CIDR: an Address Assignment and Aggregation Strategy RFC 1542 Clarifications and Extensions for the Bootstrap Protocol RFC 1552 PPP IPXCP RFC 1570 PPP LCP Extensions RFC 1586 Guidelines for Running OSPF Over Frame Relay Networks RFC 1587 OSPF NSSA Option RFC 1631 IP NAT RFC 1638 PPP BCP RFC 1657 Definitions of Managed Objects for BGP-4 using SMIv2 RFC 1661 PPP RFC 1662 PPP in HDLC-like Framing RFC 1745 BGP-4/IDRP for IP and OSPF Interaction RFC 1765 OSPF Database Overflow RFC 1771 BGP-4 RFC 1772 Application of BGP in the Internet RFC 1773 Experience with the BGP-4 Protocol RFC 1774 BGP-4 Protocol Analysis RFC 1793 Extending OSPF to Support Demand Circuits RFC 1812 Router Requirements RFC 1918 Address Allocation for Private Internet Space RFC 1923 RIPv1 Applicability Statement for Historic Status RFC 1930 Guidelines for creation, selection, and registration of an AS RFC 1966 BGP Route Reflection Alternative to full mesh IBGP RFC 1990 PPP MLP RFC 1997 BGP Communities Attribute RFC 1998 BGP Community Attribute in Multi-home Routing RFC 2082 RIP-2 MD5 Authentication RFC 2131 DHCP RFC 2225 Classical IP and ARP over ATM RFC 2236 Internet Group Management Protocol, Version 2 RFC 2270 Using a Dedicated AS for Sites Homed to a Single Provider RFC 2328 OSPFv2 RFC 2329 OSPF Standardization Report RFC 2236 IGMP-2 RFC 2338 VRRP RFC 2362 PIM-SM RFC 2370 OSPF Opaque LSA Option RFC 2385 Protection of BGP Sessions via the TCP MD5 Signature Option RFC 2390 Inverse Address Resolution Protocol RFC 2391 LSNAT Load Sharing using IP Network Address Translation RFC 2427 Multi-protocol Interconnect over Frame Relay RFC 2439 BGP Flap Damping RFC 2547 BGP/MPLS VPNs RFC 2453 RIPv2 RFC 2519 A Framework for Inter-Domain Route Aggregation RFC 2570 Introduction to Version 3 of the Internet-standard Network Management Framework RFC 2571 An Architecture for Describing SNMP Management Frameworks RFC 2572 Message Processing and Dispatching for the Simple Network Management Protocol (SNMP) RFC 2573 SNMP Applications RFC 2574 User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3) RFC 2575 View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP) RFC 2576 Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework RFC 2578 Structure of Management Information Version 2 (SMIv2) RFC 2579 Textual Conventions for SMIv2 RFC 2580 Conformance Statements for SMIv2 RFC 2615 PPP over SONET/SDH RFC 2684 Multi-protocol Encapsulation over ATM Adaptation Layer 5 RFC 2702 Requirements for Traffic Engineering over MPLS RFC 2763 Dynamic Hostname Exchange Mechanism for IS-IS RFC 2796 BGP Route Reflection Alternative to full mesh IBGP RFC 2842 Capabilities Advertisement with BGP-4 RFC 2858 Multi-protocol Extensions for BGP-4 RFC 2865 Remote Authentication Dial In User Service (RADIUS) RFC 2866 RADIUS Accounting RFC 2918 Route Refresh Capability for BGP-4 RFC 2925 Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations RFC 2963 Dynamic Hostname Exchange Mechanism for IS-IS RFC 2966 Domain-wide Prefix Distribution with Two-Level IS-IS RFC 2973 IS-IS Mesh Groups RFC 3031 Multi-protocol Label Switching Architecture RFC 3032 MPLS Label Stack Encoding RFC 3036 LDP Specification RFC 3065 Autonomous System Confederations for BGP RFC 3137 OSPF Stub Router Advertisement RFC 3209 RSVP-TE Extensions to RSVP for LSP Tunnels RFC 3210 Applicability Statement for Extensions to RSVP for LSP Tunnels IETF Standards MIB Support RFC No. Title RFC 1471 PPP-LCP-MIB RFC 1472 PPP-Sec-MIB RFC 1473 PPP-IP-NCP-MIB RFC 1474 PPP-Bridge-NCP-MIB RFC 1493 Bridge-MIB RFC 1657 BGP4 using SMIv2-MIB RFC 1595 SONET/SDH Interface Type-MIB RFC 1695 ATM-MIB RFC 1757 RMON-MIB RFC 1724 RIPv2-MIB RFC 1850 OSPFv2-MIB RFC 1907 SNMPv2-MIB RFC 2011 IP-MIB RFC 2012 UDP-MIB RFC 2013 TCP-MIB RFC 2021 RMON2 using SMIv2-MIB RFC 2096 IP-Forward-MIB RFC 2115 Frame-Relay-MIB RFC 2233 IF using SMIv2-MIB RFC 2358 EtherLike-MIB RFC 2495 DS1, E1, DS2, E2 Interface Types-MIB RFC 2496 DS3/E3-MIB RFC 2618 Radius-Auth-Client-MIB RFC 2668 IEEE 802.3 Medium Attachment Units (MAUs)-MIB RFC 2674 P-Bridge-MIB, Q-Bridge-MIB RFC 2787 VRRP-MIB Standards and Protocols IP routing: RIPv1/v2, OSPF, BGP-4, IS-IS Multicast support: IGMP, DVMRP, PIM-DM, PIM-SM QoS: Application level, RSVP IEEE 802.1D IEEE 802.1p IEEE 802.1Q IEEE 802.1x IEEE 802.3 IEEE 802.3ad IEEE 802.3u IEEE 802.3x IEEE 802.3z Alexander Hagen Etheric Networks Incorporated, A California Corporation 527 Sixth Street No 371261 Montara CA 94037 Main Line: (650)-728-3375 Direct Line: (650) 728-3086 Cell: (650) 740-0650 (Does not work at our office in Montara) Home: (Emgcy or weekends) 650-728-5820 fax: (650) 240-1750 http://www.etheric.net -----Original Message----- From: william(a)elan.net [mailto:william@elan.net] Sent: Saturday, February 07, 2004 5:19 AM To: Alexander Hagen Subject: Re: Cisco Router best for full BGP on a sub 5K bidget 7500 7200 or other vendor ? 7500 is your best option indeed, I'm using several of these and have close to 300Mb passing through at max, primarily ethernet, but also have serial and ATM interfaces; multiple BGP feeds with full table and quite complex access lists - and its all WORKING! One thing to remember is that while 7500 line was started long ago, there have been new router cards and VIP cards released. So if you have 7500 with RSP4 or RSP8 and use VIP2-50 with newear PA modules, you're really not in 1995 any more... For VOIP you'll need different routers but I don't think you were talking about using your core router to provide voip handoffs. Traffic accounting is working fine with 7500 and external unix system that actually does it though SNMP. P.S. Where is Montara located? I see familar 650 area code and I though I knew all the cities nearby, but definetly never been to Montara... On Sat, 7 Feb 2004, Alexander Hagen wrote: > > I have been looking for a sub 5K router on the used market to support > around 30-50 megs peak traffic. > > I have found the 7507/7513 but these things appear to have been > manufactured in 1995 ! > > Then there is the 7206 and the 7206 VXR - I guess the 7206 itself is > just as old as the 7507 and 7513 and the same price at the least - > perhaps because of its form factor. > > The 7206 VXR makes me feel a little better - as it was manufactured in > 1999? > > We are looking at a pure Ethernet environment - but with the desire to > support a lot of value added services - such as IPSEC, VoIP, traffic > accounting. Cisco's have traditionally been good at PRI and T-1 and T-3 > type interfaces - which we don't really need -which leads me to think > Foundry might be an option. > > Juniper appears to be at least 7,000.00 - and I am worried about support > - based on other articles I have seen. > > So the question is would a layer 3 switch be a good idea with a lot of > memory - for example the Cat 6509 ? > > Perhaps foundry BigIron with Jetware ? > > Please give me your thoughts - it is hard to believe that the 7507 and > 7513 are my best options.... > > Alexander Hagen > Etheric Networks Incorporated, A California Corporation > 527 Sixth Street No 371261 > Montara CA 94037 > Main Line: (650)-728-3375 > Direct Line: (650) 728-3086 > Cell: (650) 740-0650 (Does not work at our office in Montara) > Home: (Emgcy or weekends) 650-728-5820 > fax: (650) 240-1750 > http://www.etheric.net

10 12

MLPPP Follow Up - How we fixed the problem
by Richard J. Sears 01 Apr '04

01 Apr '04

I asked the group some time ago about some problems we were seeing with MLPPP on our Cisco 7513s. I have had 5 or 6 people contact me off list to ask how we solved the problem, so I figured I would post "our" solution to the group. I am sure there may be other fixes, however this works great for us and we have not had a problem in months since converting all MLPPP customers over. Basically we shut down MLPPP and went with (ip load-sharing per-packet) Here is what our config looks like: interface Serial1/0/0/13:0 description Customer #4144 (San Diego) #1 UPDATE [4144] ip address X.X.X.X 255.255.255.252 no ip directed-broadcast ip load-sharing per-packet ip route-cache distributed no cdp enable interface Serial2/1/0/14:0 description Customer #4144 (San Diego) #2 UPDATE [4144] ip address X.X.X.X 255.255.255.252 no ip directed-broadcast ip load-sharing per-packet ip route-cache distributed no cdp enable ip route X.X.X.X 255.255.255.252 Serial1/0/0/13:0 ip route X.X.X.X 255.255.255.252 Serial2/1/0/14:0 The only problem that we ran into was that we had to use the Serial designator of the interface in our route statement otherwise it will not work (or at least it did not for us). Since converting our customers (all MLPPP customers) to ip load-sharing per-packet - we have had no further problems. Hope this helps someone.... ****************************************** Richard J. Sears Vice President American Digital Network ---------------------------------------------------- rsears(a)adnc.com http://www.adnc.com ---------------------------------------------------- 858.576.4272 - Phone 858.427.2401 - Fax ---------------------------------------------------- I fly because it releases my mind from the tyranny of petty things . . "Work like you don't need the money, love like you've never been hurt and dance like you do when nobody's watching."

4 4

SMTP behavior: 553 5.5.2 Bad command format(h)
by Miguel Mata-Cardona 31 Mar '04

31 Mar '04

WTF? can anyone please explain me why must I enclose my address between the "<>"? 220 cassiopeia.remeyewear.com ESMTP service helo me.intercom.com.sv 250 cassiopeia.remeyewear.com talking to ip168-243-227-1 .243.227.171]) mail from:postmaster@intercom.com.sv 553 5.5.2 Bad command format(h) mail from: postmaster(a)intercom.com.sv 553 5.5.2 Bad command format(h) mail from:<postmaster(a)intercom.com.sv> 250 OK - mail from <postmaster(a)intercom.com.sv> quit 221 cassiopeia.remeyewear.com connection Connection to host lost. -- Miguel Mata-Cardona Intercom El Salvador mmata(a)intercom.com.sv voz: ++(503) 278-5068 fax: ++(503) 265-7024

4 3

SWIP vs. RWHOIS
by Eric Krichbaum 31 Mar '04

31 Mar '04

Has anyone run into other providers that refuse to take RWHOIS information? As I understand the general goings on, ARIN just wants the information available so that we can generally contact the correct people to deal with issues as the arise. Now, I'm having an issue where verizon is telling a customer of mine that they can't use an assigned block because it isn't in SWIP form. And they're quoting back ARIN to us. " PLEASE DO NOT RESPOND TO THIS EMAIL ADDRESS. PLEASE USE THE business-support(a)verizon.com EMAIL ADDRESS for ALL correspondence While I understand your point, it is currently the Verizon policy to have the SWIP beforehand. It is possable to have the greater range with one name and the subdomain regestered to you. For example look at 162.84.100.160 on ARIN's site. Search results for: 162.84.100.160 Verizon Internet Services VIS-162-84 (NET-162-84-0-0-1) 162.84.0.0 - 162.84.255.255 Performance Group INC VZ-PRFMNCG-1 (NET-162-84-100-160-1) 162.84.100.160 - 162.84.100.191 # ARIN WHOIS database, last updated 2004-03-29 19:15 # Enter ? for additional hints on searching ARIN's WHOIS database. Also look at this link : http://www.arin.net/library/guidelines/swip.html If you have any questions, please contact the Network Support Center at 1.800.475.7840 Option 1, 1, 1 or e-mail business-support(a)verizon.com Regards Charles Leitner business-support(a)verizon.com Verizon Enterprise Customer Service 1.800.475.7840 Option 1, 1, 1 " Have they ignored: http://www.arin.net/tools/rwhois.html and the policy itself says "ISPs must provide reassignment information on the entire previously allocated block(s) via SWIP or RWhois server for /29 or larger blocks." Am I wrong for assuming that they are unreasonable in this? Eric Krichbaum Chief Engineer Citynet

1 0

DSL and/or Routing Problems
by Jon.Kibler＠aset.com 31 Mar '04

31 Mar '04

Greetings NANOGers, Yesterday we starting noticing long delays on an ADSL connection. I spent most of the day trying to track down the problem and getting no where. Telco says they do not detect any problem on the line... so I am kind of lost. Anyone here have any ideas? Here are the specifics: This connection uses a Cisco 827 ADSL router and has several static IPs. All IPs show identical delays. Using other circuits between the same two locations, we do not see any delays. Normally on this DSL connection, local can ping remote with packet transit times around 60-70ms. Here is what we are seeing now: # ping -s SOMEHOST 68 25; sleep 1; ping -s SOMEHOST 68 25 PING SOMEHOST: 68 data bytes 76 bytes from SOMEHOST (w.x.y.z): icmp_seq=0. time=105. ms 76 bytes from SOMEHOST (w.x.y.z): icmp_seq=1. time=9132. ms 76 bytes from SOMEHOST (w.x.y.z): icmp_seq=2. time=8132. ms 76 bytes from SOMEHOST (w.x.y.z): icmp_seq=3. time=7132. ms 76 bytes from SOMEHOST (w.x.y.z): icmp_seq=4. time=6132. ms 76 bytes from SOMEHOST (w.x.y.z): icmp_seq=5. time=5133. ms 76 bytes from SOMEHOST (w.x.y.z): icmp_seq=6. time=4133. ms 76 bytes from SOMEHOST (w.x.y.z): icmp_seq=7. time=3133. ms 76 bytes from SOMEHOST (w.x.y.z): icmp_seq=8. time=2133. ms 76 bytes from SOMEHOST (w.x.y.z): icmp_seq=9. time=1133. ms 76 bytes from SOMEHOST (w.x.y.z): icmp_seq=10. time=133. ms 76 bytes from SOMEHOST (w.x.y.z): icmp_seq=11. time=104. ms 76 bytes from SOMEHOST (w.x.y.z): icmp_seq=12. time=110. ms 76 bytes from SOMEHOST (w.x.y.z): icmp_seq=13. time=109. ms 76 bytes from SOMEHOST (w.x.y.z): icmp_seq=14. time=112. ms 76 bytes from SOMEHOST (w.x.y.z): icmp_seq=15. time=106. ms 76 bytes from SOMEHOST (w.x.y.z): icmp_seq=16. time=114. ms 76 bytes from SOMEHOST (w.x.y.z): icmp_seq=17. time=107. ms 76 bytes from SOMEHOST (w.x.y.z): icmp_seq=18. time=109. ms 76 bytes from SOMEHOST (w.x.y.z): icmp_seq=19. time=106. ms 76 bytes from SOMEHOST (w.x.y.z): icmp_seq=20. time=112. ms 76 bytes from SOMEHOST (w.x.y.z): icmp_seq=21. time=106. ms 76 bytes from SOMEHOST (w.x.y.z): icmp_seq=22. time=108. ms 76 bytes from SOMEHOST (w.x.y.z): icmp_seq=23. time=106. ms 76 bytes from SOMEHOST (w.x.y.z): icmp_seq=24. time=110. ms ----SOMEHOST PING Statistics---- 25 packets transmitted, 25 packets received, 0% packet loss round-trip (ms) min/avg/max = 104/1918/9132 PING SOMEHOST: 68 data bytes 76 bytes from SOMEHOST (w.x.y.z): icmp_seq=0. time=112. ms 76 bytes from SOMEHOST (w.x.y.z): icmp_seq=1. time=9131. ms 76 bytes from SOMEHOST (w.x.y.z): icmp_seq=2. time=8132. ms 76 bytes from SOMEHOST (w.x.y.z): icmp_seq=3. time=7132. ms 76 bytes from SOMEHOST (w.x.y.z): icmp_seq=4. time=6132. ms 76 bytes from SOMEHOST (w.x.y.z): icmp_seq=5. time=5132. ms 76 bytes from SOMEHOST (w.x.y.z): icmp_seq=6. time=4133. ms 76 bytes from SOMEHOST (w.x.y.z): icmp_seq=7. time=3132. ms 76 bytes from SOMEHOST (w.x.y.z): icmp_seq=8. time=2133. ms 76 bytes from SOMEHOST (w.x.y.z): icmp_seq=9. time=1133. ms 76 bytes from SOMEHOST (w.x.y.z): icmp_seq=10. time=133. ms 76 bytes from SOMEHOST (w.x.y.z): icmp_seq=11. time=111. ms 76 bytes from SOMEHOST (w.x.y.z): icmp_seq=12. time=106. ms 76 bytes from SOMEHOST (w.x.y.z): icmp_seq=13. time=109. ms 76 bytes from SOMEHOST (w.x.y.z): icmp_seq=14. time=116. ms 76 bytes from SOMEHOST (w.x.y.z): icmp_seq=15. time=108. ms 76 bytes from SOMEHOST (w.x.y.z): icmp_seq=16. time=107. ms 76 bytes from SOMEHOST (w.x.y.z): icmp_seq=17. time=113. ms 76 bytes from SOMEHOST (w.x.y.z): icmp_seq=18. time=106. ms 76 bytes from SOMEHOST (w.x.y.z): icmp_seq=19. time=107. ms 76 bytes from SOMEHOST (w.x.y.z): icmp_seq=20. time=108. ms 76 bytes from SOMEHOST (w.x.y.z): icmp_seq=21. time=108. ms 76 bytes from SOMEHOST (w.x.y.z): icmp_seq=22. time=105. ms 76 bytes from SOMEHOST (w.x.y.z): icmp_seq=23. time=109. ms 76 bytes from SOMEHOST (w.x.y.z): icmp_seq=24. time=106. ms ----SOMEHOST PING Statistics---- 25 packets transmitted, 25 packets received, 0% packet loss round-trip (ms) min/avg/max = 105/1918/9131 What really has me bugged is the pattern shown by the first dozen packets... why the relatively quick first time, followed by a long but decreasing delay which repeats every time you restart the ping (that's why I provided 2 samples)? Despite the fact that Telco says there are not any line problems, we are seeing a change in DSL performance compared to our benchmark. When we first started noticing the problem yesterday, both in and out connections were using the Fast path, but compared to the benchmark, the inbound speed had dropped to 576 and the Capacity had jumped to 99%, plus we had some RS and CRC errors on both in and out connections. Later in the day, the connection switched from using the Fast path to the Interleave path (we did nothing on our end to cause this to change) and the performance settled down to what is shown below under "DSL NOW." DSL BENCHMARK: ============== ATU-R (DS) ATU-C (US) Capacity Used: 72% 21% Interleave Fast Interleave Fast Speed (kbps): 0 960 0 256 Reed-Solomon EC: 0 0 0 0 CRC Errors: 0 0 0 0 Header Errors: 0 0 0 0 Bit Errors: 0 0 BER Valid sec: 0 0 BER Invalid sec: 0 0 DSL NOW: ======== ATU-R (DS) ATU-C (US) Capacity Used: 94% 63% Interleave Fast Interleave Fast Speed (kbps): 736 0 256 0 Reed-Solomon EC: 99 0 4 0 CRC Errors: 4 0 1 0 Header Errors: 3 0 0 0 Bit Errors: 0 0 BER Valid sec: 0 0 BER Invalid sec: 0 0 This leaves me with a few questions... 1) What exactly is the difference between the Fast and Interleave paths? 2) At the same data rates, should both Fast and Interleave show similar throughput? 3) What would cause a switch from Fast to Interleave to occur? 4) If the Telco cannot find any line problems, what can account for the increased capacity use, the decreased data rates, and the data errors? And the bottom line is: Why the bizarre ping times, and could the changes observed in DSL performance account for that... plus the near doubling of average ping transit times? TIA for everyone's expert thoughts on this problem! Jon R. Kibler A.S.E.T., Inc. Charleston, SC USA (843) 849-8214 ================================================== Filtered by: TRUSTEM.COM's Email Filtering Service http://www.trustem.com/ No Spam. No Viruses. Just Good Clean Email.

7 6

publishing venue
by Steve Bellovin 31 Mar '04

31 Mar '04

I've been talking to the folks at Usenix about a venue for papers of interest to this group. They've very eager to have such papers at the LISA (Large Installation System Administration) conference. Timing is tight for this year -- the deadline is in three weeks ( http://www.usenix.org/events/lisa04/ ). For those who aren't familiar with LISA, this is a conference with that publishes proceedings of refereed papers. The success, of course, depends on members of this community submitting papers, this year and next -- that's what will make the conference interesting to this community. I'm working on a journal, too. --Steve Bellovin, http://www.research.att.com/~smb

3 2

Re: DSL and/or Routing Problems
by Stewart, William C (Bill), RTSLS 31 Mar '04

31 Mar '04

> ping did _this_ Ping is not very informative or accurate. If you run a traceroute, which is also not very accurate, you can get some idea about where the delay appears to be. Is it the DSL segment? Is it somewhere else that traceroute can show you? The nice thing about delays that are this long is that 9000 ms is long enough it won't just be lost in the noise... It wouldn't be surprising if it's in your DSL, and if your DSL has changed to a lower speed (which looks like it might have happened), then maybe something _is_ wrong with your DSL, or maybe the slower speed is causing traffic backups that weren't a problem when you were getting 512 kbps, or you're getting TCP retransmissions, but maybe the problem is somewhere else in the network.

2 1

Re: UPS and generator interaction?
by David Lesher 30 Mar '04

30 Mar '04

Oh, another detail. Some 98% of the UPSi around are "standby" units. They sit and trickle their batteries until the line fails, then quickly kick in. They take 'n' hours to recharge when the line returns. But there exist another genus. These 'full time' units ALWAYS run the load from the UPS inverter; and have a big AC line->DC "battery charger" -- big enough so as to keep up. The advantage is a very high degree of line isolation. Any surge, sag, glitch, spike may affect the AC->DC side of the equation, but will have to get past the battery plant and inverter for the load to see it. Note it does not even care what the input frequency is. I know of one large unit that was sent to Mexico City. At the time, it was 50Hz, but there was some announced plan for the city to go to 60, Real Soon Now. The UPS "battery charger" ran on anything between say 40-70 Hz, but the inverter made 60.0 Hz, period. Such units are not common or cheap. In the low end, Sola Corp used to make some in the low (1-3?) KVA range. Top end, how many KVA do you need? I think the one going to Mexico City was 500KVA. If your power is really rotten [Here, Guyana comes to mind...] you may want to spend more up front. Side thought, but not a NANOG topic. What in your data center really cares if your generator puts out 57 or 63 Hz, not 60.0? Why? -- A host is a host from coast to coast.................wb8foz(a)nrk.com & no one will talk to a host that's close........[v].(301) 56-LINUX Unless the host (that isn't close).........................pob 1433 is busy, hung or dead....................................20915-1433

6 6