- Test - lists.nanog.org

Re: I-D on operational MTU/fragmentation issues in tunneling
by Joe Maimon 15 Oct '04

15 Oct '04

Stephen J. Wilcox wrote: >On Thu, 14 Oct 2004, Joe Maimon wrote: > > >>Sabri Berisha wrote: >> >> >>>On Mon, Oct 11, 2004 at 11:12:55AM +0300, Pekka Savola wrote: >>> >>>With the risk of stating the obvious I would say that normally, PMTUD >>>should do the trick. >>> >>> >>> >>> >>On todays internet everything is more reliable than PMTUD. >> >>How about replacing it completely with something more inband, less prone >>to firewall breakage? >> >> > >ok .. if you have access to the end hosts then Sabri's answer works fine but if >your an inbetween network as most are then stripping DF is a good option. > >not sure how to do this 'inband' .. the point of DF is it prevents the default >'inband' fragmentation. so actually - why dont vendors have a 'ignore df-bit' >option in their equipment? > > > A mix of schemes is needed. Some inband to the protocol conversation at hand and some not. Should one fail negotiation can still happen. In most cases traffic should still flow. I think the DF bit is a mistake and should not be used, except when probing with multiple packets on the wire. I think giving vendors a free pass on bad fragmentation performance is also a problem. Nothing that couldnt have been solved with the ooddles of cheaply available memory we have now. And by that I mean the vendors who consistently shipped routers that had only performance resources for bare bones routing. (OT Rant: The price margin of the routers being high enough that doubling the shipped memory load and enabling upgrades to limits comparably available to popular cheap computing equipment out there should not have broke the bank on these routers. There really was no excuse for 10K equipment coming in with a tenth of available computing resources that can be had at 1K. It boggles the mind the free pass they got on that. Saying performance is only required of the ASICS that switch was incredibly short sighted -- and selfish) (OT Rant #2: The whole firewall is not a router -- merely a copout because all these routers turn out to be wimps doing anything not limited to switching packets from one interface to another. The best place to handle policies and security detection for packets is where they are already being handled -- the router. ANd the reward for the copout? Big bucks for commodity computers with mediocre software.)(OT #3: How about a firewall protocol to exchange return traffic information between a set of firewalls so that assymetricity works again and firewalling can be done at the SP level. Does such a thing exist and if so who supports it) How about some more tcp or ip options so that machines can tell each other what packet sizes are actually coming in, fragmented or not? No dropping of packets. The larger they are when they come in the better. Any protocol that detects duplicate data can probe with multiple packets on the wire. Must be better for slow start, exponential back-off model. -- Inband How about a UDP port designated for IP packets with these options and magic cookie values to prevent spoofing? -- Completely outband Easy enough so that firewall vendors will have that on by default. How about an additional ICMP type dedicated precisely for this? "Packet was sent fragmented, to avoid this lower sending packet size to X". Kind of the opposite of Frag needed but DF set message.If this fails to work, well we have more fragments. Much better than having stalled traffic. -- a little different than current algorithm of drop first notify later It seem everyone keeps trying to figure out how to fix the implementation of PMTUD or to work around it. Perhaps a new solution will gain enough traction that the current mechanism will become obsolete. Problem solved. Add in some algorithm fixes as mentioned for the broken PMTUD of today and conversing hosts should have more tools than they can use to discover and take maximum advantage of pmtu, OR in the alternative, still exchange network traffic. Much better than a single mechanism for detecting PMTU which if fails can cause a blackhole of your packets. If we ever want to aggressively lift MTU's in tomorrows network we really need to solve this with enough nails and screws that it aint coming back out again. And I dont want to hear that ipv6 fixed this or that -- except if its possible to apply the lesson learned to the protocol most of us actually use. (not that I actually know if/how it works better in ipv6) because we all know that ipv4 is here to stay in its dominant position for at least 5-10 more years. It will need to be supported for possibley another 20. Joe >Steve > > > > >

1 0

The Cidr Report
by cidr-report＠potaroo.net 15 Oct '04

15 Oct '04

This report has been generated at Fri Oct 15 21:44:38 2004 AEST. The report analyses the BGP Routing Table of an AS4637 (Reach) router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org/as4637 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 08-10-04 146340 100463 09-10-04 146514 100158 10-10-04 145998 100388 11-10-04 146398 100399 12-10-04 146471 100537 13-10-04 146629 100516 14-10-04 146719 100627 15-10-04 146802 100866 AS Summary 18190 Number of ASes in routing system 7415 Number of ASes announcing only one prefix 1397 Largest number of prefixes announced by an AS AS7018 : ATTW AT&T WorldNet Services 86747136 Largest address span announced by an AS (/32s) AS721 : DNIC DoD Network Information Center Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 15Oct04 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 146968 100968 46000 31.3% All ASes AS18566 746 7 739 99.1% CVAD Covad Communications AS4134 817 181 636 77.8% CHINANET-BACKBONE No.31,Jin-rong Street AS4323 794 221 573 72.2% TWTC Time Warner Telecom AS7018 1397 970 427 30.6% ATTW AT&T WorldNet Services AS6197 805 421 384 47.7% BNS-14 BellSouth Network Solutions, Inc AS22773 392 19 373 95.2% CXA Cox Communications Inc. AS22909 394 33 361 91.6% CMCS Comcast Cable Communications, Inc. AS27364 399 41 358 89.7% ARMC Armstrong Cable Services AS701 1242 898 344 27.7% UU UUNET Technologies, Inc. AS6478 406 92 314 77.3% ATTW AT&T WorldNet Services AS1239 946 634 312 33.0% SPRN Sprint AS17676 367 63 304 82.8% JPNIC-JP-ASN-BLOCK Japan Network Information Center AS9929 335 33 302 90.1% CNCNET-CN China Netcom Corp. AS4355 381 99 282 74.0% ERSD EARTHLINK, INC AS4766 532 266 266 50.0% KIXS-AS-KR Korea Telecom AS21502 269 3 266 98.9% ASN-NUMERICABLE NUMERICABLE is a cabled network in France, AS14654 258 6 252 97.7% WAYPOR-3 Wayport AS9443 357 108 249 69.7% INTERNETPRIMUS-AS-AP Primus Telecommunications AS6140 367 121 246 67.0% IMPSA ImpSat AS7843 493 265 228 46.2% ADELPH-13 Adelphia Corp. AS25844 244 16 228 93.4% SASMFL-2 Skadden, Arps, Slate, Meagher & Flom LLP AS2386 845 618 227 26.9% ADCS-1 AT&T Data Communications Services AS15557 330 103 227 68.8% LDCOMNET LDCOM NETWORKS AS1221 809 583 226 27.9% ASN-TELSTRA Telstra Pty Ltd AS6198 431 219 212 49.2% BNS-14 BellSouth Network Solutions, Inc AS13083 217 8 209 96.3% Mannesmann Datenverarbeitung Autonomes System AS22291 279 71 208 74.6% CC04 Charter Communications AS721 722 516 206 28.5% DNIC DoD Network Information Center AS3356 645 445 200 31.0% LEVEL3 Level 3 Communications AS5668 403 206 197 48.9% CIH-12 CenturyTel Internet Holdings, Inc. Total 16622 7266 9356 56.3% Top 30 total Possible Bogus Routes 24.138.80.0/20 AS11260 AHSICHCL Andara High Speed Internet c/o Halifax Cable Ltd. 24.246.0.0/17 AS7018 ATTW AT&T WorldNet Services 24.246.38.0/24 AS25994 NPGCAB NPG Cable, INC 24.246.128.0/18 AS7018 ATTW AT&T WorldNet Services 64.46.4.0/22 AS11711 TULARO TULAROSA COMMUNICATIONS 64.46.27.0/24 AS8674 NETNOD-IX Netnod Internet Exchange Sverige AB 64.46.34.0/24 AS3408 64.46.63.0/24 AS7850 IHIGHW iHighway.net, Inc. 64.83.96.0/19 AS26956 NETFR NetFree Communications 64.127.0.0/18 AS7018 ATTW AT&T WorldNet Services 66.114.0.0/19 AS16526 BIRCHT Birch Telecom, Inc. 69.26.32.0/19 AS17307 VIRTEL-15 Virtela Communications 132.0.0.0/10 AS721 DNIC DoD Network Information Center 137.0.0.0/13 AS721 DNIC DoD Network Information Center 138.136.0.0/13 AS721 DNIC DoD Network Information Center 158.0.0.0/13 AS721 DNIC DoD Network Information Center 192.30.93.0/24 AS17757 HPAUS-AP HP Australia 192.30.94.0/24 AS17757 HPAUS-AP HP Australia 192.30.127.0/24 AS719 LANLINK Elisa Oyj 192.40.105.0/24 AS5515 SONERA-GLOBAL-IP Sonera Solution Autonomous System 192.44.0.0/19 AS702 AS702 MCI EMEA - Commercial IP service provider in Europe 192.70.164.0/24 AS25689 NRCC-2 National Research Council of Canada 192.81.182.0/24 AS719 LANLINK Elisa Oyj 192.81.183.0/24 AS719 LANLINK Elisa Oyj 192.81.184.0/24 AS719 LANLINK Elisa Oyj 192.119.135.0/24 AS270 NASA National Aeronautics and Space Administration 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.133.6.0/24 AS4004 GLOBALONE-EQUANT-UK Equant UK & Greece Autonomous System 192.135.50.0/24 AS7018 ATTW AT&T WorldNet Services 192.153.144.0/21 AS721 DNIC DoD Network Information Center 192.172.0.0/19 AS721 DNIC DoD Network Information Center 192.188.208.0/20 AS721 DNIC DoD Network Information Center 192.243.32.0/23 AS2044 PALINA Palin Aquisitions Inc. 196.2.95.0/24 AS8668 TELONE-AS TelOne Zimbabwe P/L 198.23.26.0/24 AS4390 BELLAT-7 Bell Atlantic, Inc. 198.97.72.0/21 AS721 DNIC DoD Network Information Center 198.97.80.0/20 AS721 DNIC DoD Network Information Center 198.97.88.0/24 AS89 NUSC-1 Naval Underwater Systems Center 198.97.240.0/20 AS721 DNIC DoD Network Information Center 198.97.247.0/24 AS3475 DEPART-52 Department of the Navy 198.101.4.0/22 AS721 DNIC DoD Network Information Center 198.136.32.0/20 AS19329 MCBCC Martin County Board of County Commissioners 198.144.32.0/19 AS3998 CITY CityNet, Inc. 198.161.87.0/24 AS6539 GTGR GT Group Telecom Services Corp. 198.161.165.0/24 AS852 AGTA Telus Advanced Communications 198.163.155.0/24 AS684 MRN Manitoba Regional Network 198.167.0.0/16 AS7456 INS-51 Interhop Network SERVICES Inc. 198.167.163.0/24 AS15290 ACCA-2 Allstream Corp. Corporation Allstream 198.168.0.0/16 AS701 UU UUNET Technologies, Inc. 198.169.0.0/16 AS803 SASK SaskTel 198.232.133.0/24 AS23075 SKOTOS Skotos Tech, Inc 199.10.0.0/16 AS721 DNIC DoD Network Information Center 199.60.0.0/20 AS271 UBC-3 University of British Columbia 199.96.44.0/23 AS19092 360NE-1 360Networks (USA) Inc. 199.96.46.0/24 AS19092 360NE-1 360Networks (USA) Inc. 199.114.0.0/18 AS568 DISOUN DISO-UNRRA 199.114.0.0/21 AS721 DNIC DoD Network Information Center 199.114.128.0/18 AS721 DNIC DoD Network Information Center 199.114.130.0/24 AS721 DNIC DoD Network Information Center 199.114.132.0/24 AS721 DNIC DoD Network Information Center 199.114.134.0/24 AS1913 DLA-8 Defense Logistics Agency 199.114.136.0/24 AS1913 DLA-8 Defense Logistics Agency 199.114.138.0/24 AS721 DNIC DoD Network Information Center 199.114.140.0/24 AS3544 DISAUN DISA/UNRRA 199.114.142.0/24 AS721 DNIC DoD Network Information Center 199.114.144.0/24 AS721 DNIC DoD Network Information Center 199.114.148.0/24 AS721 DNIC DoD Network Information Center 199.114.150.0/24 AS721 DNIC DoD Network Information Center 199.114.152.0/24 AS1913 DLA-8 Defense Logistics Agency 199.114.154.0/24 AS1733 ADP-41 AF DDN PMO 199.114.156.0/24 AS1913 DLA-8 Defense Logistics Agency 199.114.160.0/24 AS1733 ADP-41 AF DDN PMO 199.120.32.0/19 AS16582 NXLI NEXTLEVEL INTERNET, INC. 199.121.0.0/16 AS721 DNIC DoD Network Information Center 199.123.0.0/18 AS721 DNIC DoD Network Information Center 199.123.16.0/20 AS721 DNIC DoD Network Information Center 199.123.80.0/21 AS721 DNIC DoD Network Information Center 199.189.32.0/19 AS7332 IQUEST IQuest Internet 199.197.8.0/22 AS21814 PARSON-18 Parsons Corp. 199.202.0.0/16 AS701 UU UUNET Technologies, Inc. 202.47.1.0/24 AS7491 PI-PH-AS-AP PI-PHILIPINES 202.70.28.0/24 AS4515 ERX-STAR Star Internet Services Ltd. 202.73.128.0/22 AS4058 LINKAGENET-AP CPCNet Hong Kong Ltd. 202.93.0.0/20 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 202.133.3.0/24 AS9335 CIP-JAPAN-AS-AP ATT IPlus 202.164.224.0/19 AS7599 IPXC-AS-AP IP Exchange 203.32.4.0/23 AS7617 203.62.0.0/17 AS7572 AARNET-ACT-RNO Australian Academic and Reasearch Network (AARNet) 203.84.192.0/19 AS17433 PHILWEB-AP PhilWeb.Com, Inc. 203.84.192.0/20 AS17433 PHILWEB-AP PhilWeb.Com, Inc. 203.84.208.0/20 AS17433 PHILWEB-AP PhilWeb.Com, Inc. 203.170.14.0/23 AS6648 ASN-SKYINTERNET ASs peering of Sky Internet 203.210.69.0/24 AS17536 PRODIGY-AS-AP Prodidgy Telecommunications 204.154.125.0/24 AS3952 TELLAB-1 TELLABS Operations, Inc. 204.154.126.0/24 AS3952 TELLAB-1 TELLABS Operations, Inc. 204.154.127.0/24 AS3952 TELLAB-1 TELLABS Operations, Inc. 204.194.110.0/23 AS30653 EXOBI Exobit Networks Inc. 205.150.0.0/15 AS701 UU UUNET Technologies, Inc. 205.159.72.0/24 AS1660 ANSCOM-5 ANS Communications 206.167.57.0/24 AS376 RISQR-3 Reseau Interordinateurs Scientique Quebecois (RISQ) 206.191.64.0/18 AS15290 ACCA-2 Allstream Corp. Corporation Allstream 206.251.69.0/24 AS27429 TIL-33 Telesat International Ltd. 206.253.190.0/23 AS8123 POLYBA Polybase 207.47.254.0/24 AS701 UU UUNET Technologies, Inc. 207.231.96.0/19 AS11194 NUNETI NuNet Inc 208.81.187.0/24 AS19194 SNL-8 Sentris Network LLC 209.172.0.0/18 AS7770 TRTI Triton Technologies, Inc. 209.205.69.0/24 AS21578 Universidad autonoma de Bucaramanga 209.205.70.0/24 AS21578 Universidad autonoma de Bucaramanga 209.205.81.0/24 AS15066 SkyNet de Colombia S.A. 209.205.82.0/24 AS15066 SkyNet de Colombia S.A. 209.205.84.0/24 AS15066 SkyNet de Colombia S.A. 209.213.32.0/19 AS10629 INS-52 Inter-Pacific Network Services 209.213.48.0/24 AS10629 INS-52 Inter-Pacific Network Services 209.213.49.0/24 AS10629 INS-52 Inter-Pacific Network Services 209.213.50.0/24 AS10629 INS-52 Inter-Pacific Network Services 209.213.55.0/24 AS10629 INS-52 Inter-Pacific Network Services 209.213.56.0/24 AS10629 INS-52 Inter-Pacific Network Services 209.251.0.0/19 AS11036 SISCOM-1 SISCOM, Inc 216.37.110.0/23 AS4264 CERFN California Education and Research Federation Network 216.96.128.0/18 AS7018 ATTW AT&T WorldNet Services 216.145.130.0/23 AS11937 TRXI TRX Inc. 216.145.132.0/22 AS11937 TRXI TRX Inc. 216.145.156.0/24 AS20304 JIS-32 JVLNET Internet Services 216.145.158.0/24 AS20304 JIS-32 JVLNET Internet Services 216.145.176.0/21 AS20304 JIS-32 JVLNET Internet Services 216.145.177.0/24 AS20304 JIS-32 JVLNET Internet Services 216.145.178.0/24 AS20304 JIS-32 JVLNET Internet Services 216.145.184.0/21 AS10758 INWAVE INWave Internet, Inc 216.145.200.0/21 AS20304 JIS-32 JVLNET Internet Services 216.186.151.0/24 AS3356 LEVEL3 Level 3 Communications 216.186.152.0/21 AS3356 LEVEL3 Level 3 Communications 216.186.160.0/23 AS3356 LEVEL3 Level 3 Communications 216.186.164.0/22 AS3356 LEVEL3 Level 3 Communications 216.186.192.0/22 AS3356 LEVEL3 Level 3 Communications 216.186.198.0/23 AS3356 LEVEL3 Level 3 Communications 216.186.248.0/23 AS3356 LEVEL3 Level 3 Communications Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog(a)merit.edu eof-list(a)ripe.net apops(a)apops.net routing-wg(a)ripe.net afnog(a)afnog.org swinog(a)swinog.ch

1 0

RE: Savings on T1 DS-3 and OC-3 for ISPs
by Damian Lennon 15 Oct '04

15 Oct '04

When did this become a marketing list??? Regards, ----------------------------------------- Damian Lennon Network Operations Director Frontline Communications Corp. v. 888.376.6854/1117 f. 845.623.8669 dlennon(a)fcc.net http://www.fcc.net/ ----------------------------------------- -----Original Message----- From: noclist(a)fcc.net [mailto:noclist@fcc.net] On Behalf Of jsam(a)broadband.com Sent: Thursday, October 14, 2004 3:23 PM To: noclist(a)fcc.net Subject: Savings on T1 DS-3 and OC-3 for ISPs Noticed that your company provides ISP services. Broadband.com is partnered with over 30 providers nationwide including: AT&T, Sprint, MCI, Broadwing, Verio, Qwest, Internap, and Savvis Communications. We have been very successful in assisting ISP's in finding cost effective backbone solutions from leading national providers. We currently have some very aggressive promotions going on through the month of October Full Internet T1 Pricing starts at $420/month Includes Local Loop Includes Router Free Installation NEW Flat Rate Multi Meg/Bonded T1 Pricing (All bundles are include local loop costs, and free install) * 3.0 Mbps- $899/month * 4.5 Mbps- $1299/month * 6.0 Mbps- $1,599/month Optional Cisco Router - $50/month Full Internet DS-3(45Mbps)- starting at $2,500/month Full Internet OC-3(155Mbps)- starting at $7,500/month Additional DS-3 discounts for heavy "pull" ISPs * 2:1 Pull Ratio - $1927/month for Full DS-3 * 3:1 Pull Ratio - $1284/month for Full DS-3 Flat Rate Instate Private Line T1 $500/month -Includes both local loops -Free Installation -Tier 1 Provider Please let me know if we can be of any assistance in pricing data and internet solutions for your company's needs. If you are not currently in the market for bandwidth feel free to forward this to other ISPs that may be able to take advantage of these significant discounts. We also have a lucrative partner program that can provide your ISP with additional revenue by using our brokering services for locations outside of your coverage area. This program pays up to 12% recurring revenue when you recommend solutions including dsl, T1, ds-3 etc to customers you cannot currently reach. Joel Sam Technology Brokerage, LLC/Broadband.com Phone: 301-273-2096 Mobile: 202.441.7680 eFAX: 202.478.1722 AIM: bandwidthrfq3 email: jsam(a)technologybrokerage.com Web Portal: http://www.broadband.com Corporate: http://www.technologybrokerage.com "Guaranteed Lowest Rates on DSL, T1, DS-3" <br> CONFIDENTIALITY NOTICE: This electronic message is intended to be viewed only by the individual or entity to whom it is addressed. It may contain information that is privileged, confidential and exempt from disclosure under applicable law. Any dissemination, distribution or copying of this communication is strictly prohibited without our prior permission. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, or if you have received this communication in error, please notify us immediately by return e-mail and delete the original message and any copies of it from your computer system.

3 3

RE: Another one bites the dust
by Gregory Hicks 14 Oct '04

14 Oct '04

> From: "Scott Morris" <swm(a)emanon.com> > To: "'Husan Sarris'" <husansarris(a)gmail.com>, <nanog(a)merit.edu> > Subject: RE: Another one bites the dust > Date: Thu, 14 Oct 2004 13:26:55 -0400 > > > Now perhaps this is a little off, but given the logic that you suggest his > mention of He Who Had a Short Mustache might be offensive (by merely > mentioning the name)... Aren't you therefore guilty of the same offensive > violation? Gratuitous mentioning does imply that there is a context, and > the context is something that would/should/could become offensive. > > *shrug* > > Seems odd. Humor is good occasionally. Oblique and non-meritorious > censorship, however, is not. > > Bear in mind, I apparantly haven't paid attention or noticed any of his past > behavior that may have warranted this. But it seems equally > counter-productive to the operation of the list for what he did as what you > did in order to let him know that. I doubt very much that Susan is actually writing these messages. > > IMHO, > > Scott > > -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of > Husan Sarris > Sent: Thursday, October 14, 2004 1:03 PM > To: nanog(a)merit.edu > Subject: Another one bites the dust > > > Stephen - although you have often been a valuable contributor to the NANOG > list, you received your "last warning" about list AUP violations last > spring. Because of your non-operational post below, and your gratuitous > mention of Hitler, which could be offensive to some, we have removed your > posting privileges from the NANOG list for a period of four months. > Please refer to the AUP: > > http://www.nanog.org/aup.html > > Susan Harris, Ph.D. > Merit Network/Univ. of Mich. > > > On Wed, 13 Oct 2004, Stephen J. Wilcox wrote: > > > > > On Wed, 13 Oct 2004, Christian Malo wrote: > > > > > FREE RICHARD > > > > Of course my understanding of revoking posting privileges is that you > > cant post to the list.. not you are imprisoned in the merit dungeons, > > i think that punishment is reserved for Bandy/Husan/etc > > > > However I do like some humor being injected onto the list, so long as > > the SNR doesnt diminish too much it can help to inject some life > > inbetween the 'paging bob smith' / 'anyone help me configure bgp' / path > mtu / urpf cyclical debates.. > > actually we've not had Hitler discussed for a while, perhaps I can > > start a thread... ooops > > > > Steve > ------------------------------------------------------------------- Gregory Hicks | Principal Systems Engineer Cadence Design Systems | Direct: 408.576.3609 555 River Oaks Pkwy M/S 6B1 | Fax: 408.894.3400 San Jose, CA 95134 | Internet: ghicks(a)cadence.com I am perfectly capable of learning from my mistakes. I will surely learn a great deal today. "A democracy is a sheep and two wolves deciding on what to have for lunch. Freedom is a well armed sheep contesting the results of the decision." - Benjamin Franklin "The best we can hope for concerning the people at large is that they be properly armed." --Alexander Hamilton

2 1

3 Mb question
by Gerald 14 Oct '04

14 Oct '04

I've got what seems to me like an innocuous question for this list... Someone is requesting access to about 3 mb of traffic up/dn. I figure 2 T1s will give them the 3 Mb I need, but I'm looking for suggestions on either efficiently combining those 2 to get the most bandwidth for their buck or else I have to look at getting them a ds3 and scaling back to what they need. Is there an good low end suggestion for making effective use of 2 T1s to give 3 Mb of bandwidth? In practice, I've seen 2 T1s load balanced with CEF not do very well at giving a full 3 Mb. (This was without turning on per-packet CEF) I'm not personally experienced with MLPPP or mux hardware if that helps, but I could get it set up if that's the consensus as the best option. The NRC of something that would effectively couple the 2 T1s would easily beat the MRC of a DS3 which I think might be overkill for just 3 Mb. Thanks for suggestions and tips. Gerald

7 11

Another one bites the dust
by Husan Sarris 14 Oct '04

14 Oct '04

Stephen - although you have often been a valuable contributor to the NANOG list, you received your "last warning" about list AUP violations last spring. Because of your non-operational post below, and your gratuitous mention of Hitler, which could be offensive to some, we have removed your posting privileges from the NANOG list for a period of four months. Please refer to the AUP: http://www.nanog.org/aup.html Susan Harris, Ph.D. Merit Network/Univ. of Mich. On Wed, 13 Oct 2004, Stephen J. Wilcox wrote: > > On Wed, 13 Oct 2004, Christian Malo wrote: > > > FREE RICHARD > > Of course my understanding of revoking posting privileges is that you cant post > to the list.. not you are imprisoned in the merit dungeons, i think that > punishment is reserved for Bandy/Husan/etc > > However I do like some humor being injected onto the list, so long as the SNR > doesnt diminish too much it can help to inject some life inbetween the 'paging > bob smith' / 'anyone help me configure bgp' / path mtu / urpf cyclical debates.. > actually we've not had Hitler discussed for a while, perhaps I can start a > thread... ooops > > Steve

3 3

Contact
by Husan Sarris 14 Oct '04

14 Oct '04

BTW I've been told that Susan reports to bburke(a)merit.edu, so I'd suggest mailing her with any issues you may have with her censorship, and overall lack of diplomacy and technical knowledge needed to run the NANOG list and meetings.

1 0

Re: BCP38 making it work, solving problems
by Fred Baker 14 Oct '04

14 Oct '04

At 08:39 AM 10/12/04 +0530, Suresh Ramasubramanian wrote: >Yes I know that multihoming customers must make sure packets going out to >the internet over a link match the route advertised out that link .. but >stupid multihoming implementations do tend to ensure that lots of people >will yell loudly, and yell loudly enough for several tickets to be >escalated well beyond tier 1 NOC support desks, for ISPs to kind of think >twice before they put uRPF filters in .. You might want to take a glance at RFC 3704, which looks at a number of the issues that have been raised in this thread, including the routing of traffic to appropriate enterprise egress points. In my heart of hearts, I would like enterprises to (as a default) match layer 2 and layer 3 addresses on the originating LAN, and quarantine-as-busted any machine that sends an address other than assigned on an interface. It seems that the few cases where a device legitimately sends multiple addresses are exception cases that can be handled separately. Handling it that close to the source solves the problem for everyone. Practically, that is difficult. If you think getting all of the service providers (who wind up having to fix ddos attacks, and pay for bandwidth and services related to ddos attacks) to manage networks well is difficult, consider the prospect of getting all the edge networks to do so... As simple solution is, as someone suggested, pose an idiot tax and bill the customers for doing stupid things. Egress traffic filtering in the enterprise is relatively simple for the average enterprise - it has at most a few prefixes and can write a simple ACL on its upstream router. It can use the ACL either to discard offending packets or to route them to the right egress. It is also relatively simple for the average enterprises' ISP: it knows what prefix(es) it agreed to accept traffic from and can write an ACL. It gets a little dicier when the customer is a lower tier ISP. In that case, there are potentially many prefixes, and they change more frequently. That is the argument for something like uRPF. No, it is not a "sure fix", but it handles that case more readily, both in the sense of being a fast lookup and in the sense of maintaining the table. The problem is, of course, in the asymmetry of routing - it has to be used with the brain engaged. From an ISP perspective, I would think that it would be of value to offer *not* ingress filtering (whether by ACL or by uRPF) as a service that a customer pays for. Steve Bellovin wrote an April Fool's note suggesting an "Evil Bit" (ftp://ftp.rfc-editor.org/in-notes/rfc3514.txt) I actually think that's not such a dumb idea if implemented as a "Not Evil" flag, using a DSCP or extending the RFC 3168 codes to include such, as Steve Crocker has been suggesting. Basically, a customer gets ingress filtered (by whatever means) and certain DSCP settings are treated as "someone not proven to have their act together". Should a ddos happen, such traffic is dumped first. But if the customer pays extra, their traffic is marked "not evil", protected by the above, and ingress filtering may be on or off according to the relevant agreement. The agreement would need to include a provision to the effect that once a ddos is traced in part to the customer, their traffic is marked as "evil" for a period of time afterwards. What the customer is paying for, if you will, is the ability to do their thing during a ddos in a remote part of the network, such as delivering a service to a remote peer. Address spoofing is just one part of the ddos problem; to nail ddos, we also need to police a variety of application patterns. One reason I like the above is that it gives us a handle on what traffic might possibly be "not evil" - someone has done something that demonstrates that it is from a better managed source.

4 5

Excessive DNS Requests
by Anderson, Ian 14 Oct '04

14 Oct '04

Anyone else seeing excessive DNS requests hammering their local forwarders this evening. We've just taken our residence network off-line owing to the level of port 53 traffic coming from it. Can't see anything in the usual places regarding this.... Cheers Ian -- Ian Anderson Network Support Lancaster University t: 01524 593393 ~ IP: 01524 510101 ~f: 01524 525125 mailto:i.anderson@lancs.ac.uk

4 3

can someone who runs AS 7018 contact me off list asap
by Richard Gross 14 Oct '04

14 Oct '04

Our space is hi-jacked at this moment, and I need some help. 207.182.224.0/19 does not belong to you. richg

1 0