- Test - lists.nanog.org

May be OT: Riverstone Configuration Issue
by Tom Daly 24 Dec '03

24 Dec '03

Hi, I'm trying to configure my Riverstone RS3000 v.8.0.0.0 to advertise a host route with a BGP community on it. Here is the cisco version of the command set: redistribute static route-map static-to-bgp ! route-map static-to-bgp permit 5 match tag 12345 set community additive XXX:12345 ! ip route 192.168.0.1 255.255.255.255 Null0 tag 12345 I'm spent 4 hours or so trying different configurations, route maps, and ip-policies on the RS, with no luck. The route is exported into BGP, but doesn't get tagged with the community. Suggestions off list would be appreciated. Thanks! -- Thomas J. Daly tom(a)dyndns.org Chief Infrastructure Officer Dynamic DNS Network Services, LLC. http://www.dyndns.org/

1 0

Cox.Net problems?
by Marius Strom 24 Dec '03

24 Dec '03

Any cox.net folks around this evening? Seems packets from various cox.net terminated sites to AT&T address space (12.0.0.0/8) is going to Singtel.net out of Singapore. Singtel.net is not permitting transit. Partial MTR below: 2. bcstbbrc01-vln30.ma.dl.cox-internet 0% 1 1 11 11 11 11 3. dllsbbrc01-gew0402.ma.dl.cox-intern 0% 1 1 18 18 18 18 4. dllsdsrc01-gew0303.rd.dl.cox.net 0% 1 1 60 60 60 60 5. dllsbbrc01-pos0101.rd.dl.cox.net 0% 1 1 16 16 16 16 6. chndbbrc02-pos0103.rd.ph.cox.net 0% 1 1 37 37 37 37 7. chndbbrc01-pos0100.rd.ph.cox.net 0% 1 1 44 44 44 44 8. lvxxbbrc01-pos0103.rd.lv.cox.net 0% 1 1 47 47 47 47 9. paltbbrj01-pos010000.r2.pt.cox.net 0% 1 1 64 64 64 64 10. g1-0-0.plapx-ar1.ix.singtel.com 0% 1 1 72 72 72 72 11. 203.208.182.21 0% 1 1 68 68 68 68 12. 203.208.182.129 0% 1 1 254 254 254 254 13. ??? If need be for troubleshooting at the source (connected via Cox), I can be reached via 979-575-1605. -- /-------------------------------------------------> Marius Strom | Always carry a short length of fibre-optic cable. Professional Geek | If you get lost, then you can drop it on the System/Network Admin | ground, wait 10 minutes, and ask the backhoe http://www.marius.org/ | operator how to get back to civilization. \-------------| Alan Frame |---------------------->

1 1

www.dhs.gov looking for input for future solicitations
by k claffy 23 Dec '03

23 Dec '03

for those who don't speak inside-dc-beltway, the below is a request for information that a well-funded federal agency will use to write a proposal solicitation, to which folks (including but not limited to operators) then write proposals to get ops research funding. (and ultimately, presumably for implementations/ infrastructure.) so if you want to influence what the U.S. department of homeland security funds in the area of IPS (not my meme), jan 2004 is an opportunity to tell them what to ask for. you are encouraged to take it, lots of people there trying to do the right thing and could use help from experts regarding what exactly that is. formatted below, unreadable version of your very own at: http://www.fbodaily.com/archive/2003/11-November/23-Nov-2003/FBO-00474736.h… k --------------------------------------------------------------------------- NATIONAL COMMUNICATIONS SYSTEM INFORMATION ANALYSIS AND INFRASTRUCTURE PROTECTION DIRECTORATE, DEPARTMENT OF HOMELAND SECURITY INTERNET PRIORITY SERVICE (IPS) REQUEST FOR INFORMATION 1. INTRODUCTION 1.1 Scope The National Communications System (NCS) of the Department of Homeland Security is soliciting information regarding assured communications through the Internet. This information is with respect to services or products that carriers, vendors, and third parties can provide, or plan in the future to provide, applicable to designing/developing an Internet Priority Service (IPS) capability to support national security and emergency preparedness (NS/EP) communications. This request for information (RFI) seeks technical information regarding Internet-based assured communications for data, including Voice over Internet Protocol (VoIP). Responses from all organizations including commercial entities, academic institutions, and Government departments and agencies, are encouraged. 1.2 Background Under the provisions of Executive Order 12472, the NCS is responsible for ensuring that an NS/EP telecommunications infrastructure exists and is responsive to the needs of the President and the Federal departments and agencies using public and private telecommunications systems. In support of this mission, we have initiated several programs designed to overcome network failure and congestion during emergency situations, including the Government Emergency Telecommunications Service (GETS), Telecommunications Service Priority (TSP), and Wireless Priority Service (WPS) to address priority services for Federal, State, and local Critical Infrastructure leadership personnel during an emergency. The current implementations of priority service for NS/EP telecommunications consist of voice and voice-band data only in the circuit switched wire-line and wireless networks. Due to the ever-increasing use of the Internet for transmission of all types of communications, we are looking at ways to provide similar types of assured communications for data applications and voice or video applications running over the Internet. Information learned from this RFI will be used to help NCS achieve the following goals: _ Identify plans and emerging technologies for providing priority services through the Internet. _ Facilitate promising technologies as prototypes and proof-of-concept projects. _ Identify any new areas requiring standardization. _ Model technologies to determine what enhancements are required. _ Develop an Internet Priority Service (IPS) program plan. 2. AREAS OF INTEREST The following functional goals of an IPS concept should be considered: Enhanced Priority Treatment Secure Networks Ubiquitous Coverage International Connectivity Interoperable Scalable Bandwidth Mobility Voice Band Service Broadband Service Reliability/Availability Restorable Survivable Non-Traceable Affordable Ultimately, the service should be resilient to large-scale outages of the Internet infrastructure in addition to other infrastructures the Internet is dependent upon_such as electric power and telecommunications. It should also be resilient to cyber attacks originating within the Internet itself, such as denial of service, worms, etc. Solutions should have ubiquitous coverage in that they translate to various physical and link layer technologies, locations, applications, and network topologies. Specifically, we are looking for solutions that will work in inter-AS cross-provider environments, as well as within single provider networks. To enable interoperability, we have IPS standards efforts underway through the Parlay Group 4 requirements; however, a lack of standards should not preclude a response--we are also interested in concepts and implementations that may be proprietary in nature, and have not yet been standardized. Responders are encouraged to review the T1A1.2 committee_s _Roadmap Standards in Support of Emergency Telecommunications Service (ETS)_ under the project T1A1-19 _Reliability/Availability of IP-based Networks and Services,_ whose concepts are reflected throughout this RFI. An IPS should have a large set of capabilities to potentially be of service during disaster recovery activities. Since not all of the following features are currently available, responses are not expected to meet all of these criteria; however, IPS features and objectives could include the following: _ Multimedia and telephony services _ Rapid user authentication _ Security protection of user traffic _ Preferential access to telecomm facilities _ Preferential establishment of communications _ Preferential routing of traffic _ Preferential use of remaining operational resources _ Preferential completion of user traffic to destination _ Allowable degradation of service quality _ Interchange of critical telecomm service management information _ Optional preemption of non-emergency traffic (where permitted by regulation) The objective is to provide priority service for Internet applications critical to essential personnel during a crisis. Preliminary analysis shows that numerous approaches are possible due to the design of the protocol model and state that makes up the Internet; however, prioritized delivery of individual packets at the lower layers of the Internet protocol model does not guarantee that transactions will gain priority processing on end systems and servers. Since any single protocol is likely to be insufficient to guarantee priority, several approaches may need to be combined to form an operational system. In addition to end-to-end solutions, we are interested in individual submissions that may consist of building blocks for an overall IPS architecture. Responses should address how these building blocks fit within the traditional Internet model to eventually provide an end-to-end solution. Specifically, the following areas should be addressed: _ Link Layer. A large variety of layer 2 link level technologies are incorporated within the Internet. Enhancements applicable to priority services for High-speed optical backbone technologies such as SONET, Packet over SONET, MPLS, Gigabit Ethernet, DWDM, and ATM are of interest. Also of interest are enhancements applicable to access technologies such as DSL, cable modem, and fixed wireless, in addition to priority within mobile wireless protocols such as messaging, 3G cellular data, and satellite data. _ Network Layer. Internet Protocol (IP) makes up the entire network layer for the Internet. There are two versions of IP applicable to this RFI. IP Version 4 is the current protocol that operates the majority of the Internet. IP v6 will eventually replace IP v4, with superior addressing, security, priority and other features. We are interested in approaches that are applicable to either or both versions of IP. _ Transport Layer. Protocols designed to assure data transmission end-to-end or hop-by-hop through the Internet often are considered transport layer enhancements. The IETF has standardized a number of approaches, so implementations of these are of interest to us. Additional concepts and proprietary implementations in this area are also of interest. _ Application Layer. Applications control the Internet; as an example BGP and DNS are applications that are considered core infrastructure pieces of the Internet. Applications also make up the services that utilize the Internet. Of interest are application enhancements that will lead to one or more of the fourteen functional goals for an assured IPS. Applications of particular interest include (but are not limited to) email, messaging, web, VoIP, (transport and edge), and video. _ Standards and APIs. We are also interested in standards or APIs that have been developed in these areas, whether or not implemented in products or services. 3. RESPONSE GUIDELINES 3.1 Scope Most organizations do not have expertise or capabilities in all of the areas described above; therefore, responses addressing only a subset of or single identified area(s) of interest are also welcome. Responses should be clearly labeled with the areas of interest that are discussed. Length of responses should be limited to no more than 40 pages. 3.2 Structure Provide any materials, suggestions, and discussion you deem appropriate. In addition, please provide ample contact information, including telephone numbers and e-mail addresses, to facilitate any needed clarification or further discussion. Include, as appropriate, the following: _ Description of Products/Technologies/Research/Standards/APIs, including performance information _ Plans for commercial use of these technologies _ Corporate partners who will use the technology _ Feasibility Assessment _ Cost and Schedule Estimates _ Existing Government Contracts _ Corporate Expertise 3.3 Format Electronic and hard copy formats are both acceptable, although electronic submission is preferred. If provided electronically, submissions should be in a Microsoft Office compatible format or Adobe Acrobat. Copies may be emailed to Mr. Dave Nolan at noland(a)ncs.gov or mailed to the address below. 3.4 Deadline Responses are due 60 days after release of this RFI. 4. DISCLAIMER There is no bid package or solicitation document associated with this announcement. The requested information is for planning purposes and does not constitute a commitment, implied or otherwise, that a procurement action will be issued or a contract awarded. No entitlement to payment of direct or indirect costs or charges by the Government will arise as a result of the submission of information. Responses to the RFI will not be returned. The Government shall not be liable for or suffer any consequential damages for any improperly identified proprietary information. Proprietary information will be safeguarded in accordance with the applicable Government regulations. In accordance with FAR 15.202(e), responses to this notice are not an offer and cannot be accepted by the Government to form a binding contract. Responders are solely responsible for all expenses associated with responding to this RFI. 5. CONTACT INFORMATION Mr. David J. Nolan NCS/N2 701 South Court House Road Arlington, VA 22204-2198 (703) 607-6190 noland(a)ncs.gov ----- End forwarded message -----

2 1

201/8 block
by Ricardo G Patara 23 Dec '03

23 Dec '03

Hello, As many of you all might known, LACNIC has been allocated the block 201/8 from IANA back in April/2003: http://www.iana.org/assignments/ipv4-address-space it was announced in this mailing list: http://answerpointe.cctec.com/maillists/nanog/current/msg01094.html But, some users are facing problems with addresses in this range due to old filters in some backbones. There was recommendations and routes configurations tips in which the 201/8 block used to be referred as bogus route. At the time those documents were created, the mentioned blocks was not allocated by IANA yet. What is not true since April/2003. Based on this, we would like to ask to network administrators in general to revise their router configuration to make sure they are not filtering valid routes, like networks into 201/8 block. Thank you. Hostmaster // Registration Service ---------------------------------- Latin America and Caribbean Region Internet Addresses Registry http://www.lacnic.net ----------------------------------

3 4

.ORG Registrar ID List (was: Stupid .org registry code change)
by Bruce Beckwith 23 Dec '03

23 Dec '03

Mike, You should deal with a registrar for this information, since that is one of the services they can provide for you. If you are interested in the cross-reference list, please see http://www.pir.org/whois_search/registrar_whois_ids, which can be accessed via the link at http://www.pir.org/whois_search/. In addition, if you choose to use the web-based whois, then you can use the link on the whois output for the registrar - so for example, the domain nanog.org is at http://www.pir.org/cgi-bin/whois.cgi?yes_popup_flag=0&whois_query_field= domain+NANOG.ORG, and using the link for Sponsoring Registrar, in this example "NSI(R63-LROR)" will give information on how to reach the registrar - see http://www.pir.org/cgi-bin/whois.cgi?yes_popup_flag=0&whois_query_field= registrar+id+R63-LROR. I will pass on your offer of career advice ;-) Regards, Bruce Bruce W. Beckwith VP, Operations Public Interest Registry 1775 Wiehle Avenue Suite 102A Reston, VA 20190 v: +1 703.464.7005 x105 bbeckwith(a)pir.org -----Original Message----- From: Michael Lewinski [mailto:mike@rockynet.com] Sent: Monday, December 22, 2003 6:19 PM To: nanog(a)nanog.org Subject: Stupid .org registry code change During the recent changes to .org, whois stopped being useful for what I need. > Sponsoring Registrar:R11-LROR All I really want to know is the Registrar's name/URL to tell my client so they can modify their nameservers. Does anyone have: 1) A URL to the table that will allow me to lookup a name from the above code (or better, a hack to whois that will do said lookup for me)? 2) The e-mail address where I should my suggestion that the person who came up with this brilliant scheme needs to pursue a new career in a non-IT related field? TIA, Mike

4 3

RE: Router Server problem
by Burns, Keith 23 Dec '03

23 Dec '03

Complete shot in the dark... next-hop reachability? Keith Burns Principal Network Architect ICG Telecommunications IP Ph: 303-414-5385 Cell: 303-912-3777 "The dogs may bark, but the caravan rolls on...." > -----Original Message----- > From: pramod babu G [mailto:pramod@lantana.tenet.res.in] > Sent: Saturday, December 20, 2003 10:46 PM > To: nanog(a)merit.edu > Subject: Router Server problem > > > > hai all, > I am simulating an IXP and this has 4 router servers which > are connected > to the ISP routers. > I connected the 4 router server by means of Internal Bgp. > This is as shown > below > IBGP > ISP1------ RS1------- RS2 ------ ISP3 > | | > ISP2------ --------ISP4 > > Now the routes injected by ISP1 into R1 are received by ISP2. > And there is > exchange of routes between ISP3 and 4. But the routes send by > ISP3 are not > seen by ISP1 and ISP2. But RS1 has got those routes in its data base. > These routes are not selected as best routes in the RS1 bgpd > > So to overcome this do u have any suggestions ?? > >

1 0

RE: Trace and Ping with Record Option on Cisco Routers
by Danny.Andaluz＠triaton-na.com 23 Dec '03

23 Dec '03

That's exactly it, Crist. I did a little research and that the PIX drops any packets with IP Options turned on. Currently there is no workaround. This is IP Option 7 to be exact. Thanks, Danny -----Original Message----- From: Crist Clark [mailto:crist.clark@globalstar.com] Sent: Monday, December 22, 2003 6:18 PM To: Andaluz, Danilo, Triaton/NA Cc: nanog(a)merit.edu Subject: Re: Trace and Ping with Record Option on Cisco Routers > Danny.Andaluz(a)triaton-na.com wrote: > > Hey, Group. > > In my production network, I'm trying to do some extended traces and > pings with the record option turned on to see what route my packets > take going and returning. It's not working. If I do the extended > traceroute or ping without the record option, it works fine. There is > a firewall (PIX) a few hops in front of the destination I'm trying to > record the route for. What part of ICMP is this that needs to be > opened on the firewall to allow this to come back? First time I'm > coming across this. It's not ICMP. It's the IP Options. Most firewalls will drop any packet with an IP Options. Many firewalls will not let you turn this off. I do not know how to allow IP Options through a PIX, but I know how to do it in Cisco IOS. -- Crist J. Clark crist.clark(a)globalstar.com Globalstar Communications (408) 933-4387

1 0

Packet loss and inexplicable delays
by Constantinos A. Kotsokalis 23 Dec '03

23 Dec '03

Hello All, In the process of testing certain circuits delivered as parts of a WAN, we have found that two links are having serious packet loss and (inexplicable!) delays. To be more specific, they have packet loss on one direction, and huge delays on the other direction. The following diagram shows the situation (all equipment is made by Cisco): 1. Site A <-> Site B: Delay -----------> -------- ATM -------- ATM ------- E3 -------------- | 7500 | <---> | 7200 | <---> | GSR | <----> | 6500/MSFC2 | -------- -------- ------- -------------- <----------- Packet loss The GSR connects to the E3 with an Engine0 12E3-SMB LC. The ATM link between the 7500 and the 7200 is shaped at 58 Mbps (ATM rate), while the link between the 7200 and the GSR is 155 Mbps. The E3 is an HDLC circuit. During the test, we noticed interface resets on the E3 link (line down). We thought that maybe the MSFC2 has prioritization problems (i.e. PPP keepalives are not prioritized over normal traffic), but that does not seem to be the case according to documentation found. LDP between the GSR and the 6500 was also dropped a few times (this is an MPLS Carrier-supporting-Carrier scheme). 2. Site A <-> Site C: Packet loss -----------> -------- ATM -------- ATM -------- E3 ------- | 7500 | <---> | 7200 | <---> | 7200 | <----> | GSR | -------- -------- -------- ------- <----------- Delay The GSR connects to the E3 (HDLC) with an Engine0 6E3-SMB LC. The 7500<->7200 ATM subinterface is shaped at 40 Mbps (which, if I am correct, does explain packet loss for small packets, but not for large --i.e. 1500 byte-- packets due to cell tax). Interface/LPD resets did not happen during this experiment. The packet loss is about 5% from end to end, and the delays vary (they grow up to 10 seconds!). The testing tool we are using is Rude/Crude, and the test PCs seem to handle the load in general. These test PCs are connected on the two end-routers through FastEthernet interfaces. The send-rate used for the two tests is 34 Mbps, in both directions. It is probably useful to mention that the delay is increasing as the packet size increases. The two GSRs are running IOS 12.0(26)S, which according to the caveats list does not seem to have any problems with HDLC E3 links under any circumstances. Any ideas/insight at all, would be greatly welcome! Thank you in advance, Costas -- Constantinos A. Kotsokalis || ckotso(a)grnet.gr Greek Research and Technology Network || http://www.grnet.gr 56 Mesogeion Av., Ampelokipi, 11527 Athens, Greece Tel: +30-210-7474249 || Cell: +30-697-7606620 || Fax: +30-210-7474490

1 0

northeast fiber cut
by Alex Rubenstein 23 Dec '03

23 Dec '03

Circuits we had that were affected by the fiber cut in NJ/PA have been coming up over the last hour. two notes: a) anyone know of where this happened, specifically, and also what actually happened? I heard ?langhorne?, pa, and two 288 bundles were affected, MFN had to dig to find it -- if thats the case, what cuases fiber to magically go boom? b) is it me, or does it seem the number of fiber cuts per time period is decreasing, or does sean donelan no longer have an email client?

2 1

Bay area Earthquake
by Brennan_Murphy＠NAI.com 23 Dec '03

23 Dec '03

foxnews reporting 6.5 on the richter scale cant get more info than that

2 1