Re: Blackhole Routes
Richard A Steenbergen wrote: That said, it is still absolutely silly that we can't standardize on a globally accepted blackhole community. A provider with many transit upstreams who wishes to pass on blackhole routes for their customers could quickly find themselves with some very messy configs and announcements trying to get everyones' specific blackhole community in place. I know we've all been tossing this idea around for a number of years, but if it hasn't been done already will someone please get this put into a draft already. The problem with this is authentication. I can authenticate prefixes my customers advertise me (as much as currently possible anyway). I can't authenticate a prefix coming in from a peer that is not filtered. If an ISP were to accept any prefix with 65535:666 as a triggered blackhole, how do you trust that? As much as I agree that a global blackhole community would be nice, that's a big gotcha with potential liability attached.
Re: Phishing (Was Re: WashingtonPost computer security stories)
Christopher L. Morrow wrote: On Mon, 16 Aug 2004, Niels Bakker wrote: It's disheartening to see that this website is still online after several days (I received the scam mail received Friday morning). out of curiosity, you did send in a complaint to CitiBank's proper alias for spoofing/phishing/blah, and a followup to Savvis who is providing transit as you see from your perspective? and a sprint+sbc as it's their customer 'hosting' the original page? If no complaint is lodged citibank/sbc/sprint/savvis are non-the-wiser to the problem, eh? > /dev/null passing to abuse, sorry for missing missing the original comments neils. mark
Re: C&W Support Number
Brent, You should be able to reach support at 888-638-6771. Also, [EMAIL PROTECTED] and/or [EMAIL PROTECTED] will work. Though I believe [EMAIL PROTECTED] is being deprecated with [EMAIL PROTECTED] remaining. Regards, Mark Kasten Savvis [EMAIL PROTECTED] wrote: All, What is the new # for the Cable and Wireless support center for Internet Circuits. (800) 663-9932 is just ringing busy. Thanks, Brent
Re: yo, savvis, cox, comcast, and armstrong! (Re: The Cidr Report)
yeah, we(being savvis) are aware. this will all disappear when AS6347
is integrated to AS3561. AS3561 is, for the most part clean, and it
will stay that way. AS6347 will drop off the map in the coming months.
have patience. ;-)
thx,
mark
Paul Vixie wrote:
[EMAIL PROTECTED] writes:
This report has been generated at Fri Jun 4 21:43:44 2004 AEST.
...
Recent Table History
Date PrefixesCIDR Agg
...
03-06-04137774 96139
04-06-04137884 95196
ok, so in one day we saw the addition of 110 prefixes, but they were aligned
such that the size of a properly cidr-aggregated table dropped by 943. this
is quite a trick. what does it all mean?
...
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').
and who's doing it?
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 136767951724159530.4% All ASes
AS6347 940 160 78083.0% SAVV SAVVIS Communications
Corporation
yo, savvis! you're putting 940 routes into the global routing table, and
when somebody did "sort -u" on the as-paths, they found that with no change
to your transit policies, you could be sending just 160 instead. "help?"
AS22909 390 33 35791.5% CMCS Comcast Cable
Communications, Inc.
yo, comcast!
AS22773 378 58 32084.7% CXAB Cox Communications Inc.
Atlanta
AS27364 360 44 31687.8% ARMC Armstrong Cable Services
yo, cox and armstrong!
AS11172 351 56 29584.0% Servicios Alestra S.A de C.V
AS17676 339 50 28985.3% JPNIC-JP-ASN-BLOCK Japan
Network Information Center
AS9929 316 33 28389.6% CNCNET-CN China Netcom Corp.
AS6478 305 48 25784.3% ATTW AT&T WorldNet Services
AS25844 243 16 22793.4% SASMFL-2 Skadden, Arps, Slate,
Meagher & Flom LLP
AS14654 2305 22597.8% WAYPOR-3 Wayport
AS6327 208 28 18086.5% SHAWC-2 Shaw Communications
Inc.
yo! yo! yo! (i've only listed those who could reduce their impact on the
global routing table by 80% or more... as you all saw, the list *was* longer.)
there are any number of unemployed bgp experts haunting this mailing list
looking for post-dotbomb work. many of them would accept work as short term
consultants to help you folks get down under the 80% level. just ask!
Re: BellNexxia to C&W problems in NY ? (AS577 - AS3561)
Mike, It does appear that this interconnect is running a bit hot. If there is anyone from Bell Nexxia/AS577 listening, feel free to ping me offline and I'll see what I can do to help out. But, to be honest, this is an issue that could/should be handled your upstream and [EMAIL PROTECTED] I don't see any emails from you sent to [EMAIL PROTECTED] Regards, Mark Kasten Mike Tancsa wrote: I have a few users exchanging data with sites inside Bell Canada call in to complain today with various symptoms (eg. VPNs timing out, transfers taking a long time). After a bit of narrowing down, it would seem that when the traffic comes at me via C&W from Bell (2 of my 3 transit providers 852 and 6539 talk to parts of Bell this way) the problems are acute. Looking at traceroutes between C&W and Bell IP space, there does indeed seem to be some issue between their exchange point in NY The 2 snippets being From bell to cw 6 bx2-newyork83-pos3-0.in.bellnexxia.net (206.108.103.194) 20 msec 20 msec 16 msec 7 iar4-so-2-3-0.NewYork.cw.net (208.173.135.185) [AS 3561] 172 msec 176 msec 176 msec From cw to bell 6 iar4-loopback.NewYork.cw.net (206.24.194.39) 68 msec 68 msec 72 msec 7 teleglobe.NewYork.cw.net (208.173.135.186) 208 msec 208 msec 208 msec At one point in the day, it was adding about 400 to 500ms of latency Type escape sequence to abort. Tracing the route to route-server.cw.net (209.1.220.234) 1 dis40-toronto63-fe5-0-0.in.bellnexxia.net (205.207.238.210) 32 msec 0 msec 232 msec 2 core2-toronto63-pos11-5.in.bellnexxia.net (206.108.98.141) 0 msec 0 msec 0 msec 3 core3-toronto63-pos6-0.in.bellnexxia.net (64.230.242.101) 0 msec 0 msec 0 msec 4 core4-montreal02-pos13-1.in.bellnexxia.net (64.230.243.237) 28 msec 204 msec 208 msec 5 core1-newyork83-pos0-0.in.bellnexxia.net (206.108.99.190) 20 msec 20 msec 16 msec 6 bx2-newyork83-pos3-0.in.bellnexxia.net (206.108.103.194) 20 msec 20 msec 16 msec 7 iar4-so-2-3-0.NewYork.cw.net (208.173.135.185) [AS 3561] 172 msec 176 msec 176 msec 8 agr2-loopback.NewYork.cw.net (206.24.194.102) [AS 3561] 184 msec 176 msec 180 msec 9 dcr1-so-6-1-0.NewYork.cw.net (206.24.207.53) [AS 3561] 184 msec 180 msec 184 msec 10 dcr2-loopback.SantaClara.cw.net (208.172.146.100) [AS 3561] 248 msec 248 msec 248 msec 11 bhr1-pos-0-0.SantaClarasc8.cw.net (208.172.156.198) [AS 3561] 256 msec 244 msec 244 msec 12 bhr2-ge-2-0.SantaClarasc8.cw.net (208.172.147.54) [AS 3561] 252 msec 248 msec 248 msec 13 209.1.169.177 [AS 3561] 172 msec 184 msec * route-server.cw.net>traceroute looking-glass.in.bellnexxia.net Translating "looking-glass.in.bellnexxia.net"...domain server (64.41.189.214) [OK] Type escape sequence to abort. Tracing the route to looking-glass.in.bellnexxia.net (205.207.237.50) 1 209.1.169.178 0 msec 0 msec 0 msec 2 bhr1-ge-2-0.SantaClarasc8.cw.net (208.172.147.53) 0 msec 0 msec 0 msec 3 dcr2-so-3-0-0.SantaClara.cw.net (208.172.156.197) 0 msec 4 msec 0 msec 4 dcr1-loopback.NewYork.cw.net (206.24.194.99) 76 msec dcr2-loopback.NewYork.cw.net (206.24.194.100) 72 msec dcr1-loopback.NewYork.cw.net (206.24.194.99) 68 msec 5 agr1-so-0-0-0.NewYork.cw.net (206.24.207.50) 68 msec 72 msec 68 msec 6 iar4-loopback.NewYork.cw.net (206.24.194.39) 68 msec 68 msec 72 msec 7 teleglobe.NewYork.cw.net (208.173.135.186) 208 msec 208 msec 208 msec 8 core1-newyork83-pos1-1.in.bellnexxia.net (206.108.103.193) 260 msec 332 msec 216 msec 9 core4-montreal02-pos6-3.in.bellnexxia.net (206.108.99.189) 196 msec 204 msec 200 msec 10 64.230.243.238 208 msec 296 msec 460 msec 11 core2-torontodc-pos3-1.in.bellnexxia.net (206.108.104.2) [AS 577] 432 msec 404 msec 404 msec 12 dis4-torontodc-Vlan82.in.bellnexxia.net (206.108.104.30) [AS 577] 400 msec 240 msec 440 msec 13 looking-glass.in.bellnexxia.net (205.207.237.50) [AS 577] 452 msec 236 msec 244 msec route-server.cw.net> Anyone know whats up ? ---Mike Mike Tancsa,tel +1 519 651 3400 Sentex Communications, [EMAIL PROTECTED] Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike
Re: UUNet Offer New Protection Against DDoS
We actually accept up to the customers aggregate. So if they have a /16, they can tag the whole /16. And we do not tag no-export. I saw some time ago on a list, and I think Bill Manning suggested it, that if you are getting bits for unused address space, to announce that address space (up to host specific) with the DDoS community string. That keeps the packets off of your link and thus you don't get charged for them. The same can be done in reverse. We have a customer that is advertising their larger block with the DDoS community string, and then advertising the addresses they are actually using more specifically, so we blackhole everything less specific. These are a couple of applications that can be utilized if you don't tag no-export and accept more than just /32's within their address space. FWIW. Also, we are utilizing Juniper's DCU for tracebacks, which makes life MUCH easier when tracing an attack. :-) SNMP polling the DCU counters every few minutes is relatively fast and painless, and provides quick results. Mark Lumenello, Jason wrote: Oh, and I strip their communities, and apply no-export, on the first term of my route map so the /32 does not get out. Of course my peer facing policy requires specific communities to get out as well (belt and suspenders). This method works very well, and you do not have to give up length restrictions or maintain two sets of customer prefix/access lists. Jason -Original Message- From: Lumenello, Jason Sent: Wednesday, March 03, 2004 4:52 PM To: 'Stephen J. Wilcox'; james Cc: [EMAIL PROTECTED] Subject: RE: UUNet Offer New Protection Against DDoS I struggled with this, and came up with the following. We basically use a standard route-map for all customers where the first term looks for the community. The customer also has a prefix-list on their neighbor statement allowing their blocks le /32. The following terms (term 2 and above) in the route-map which do NOT look for the customer discard community, have a different standard/generic prefix-list evaluation which blocks cruft and permits 0.0.0.0/0 ge 8 le 24. By doing this, I only accept a customer /32 from his dedicated prefix-list when it has the DOS discard community, otherwise I catch them with the ge 8 le 24 in the following terms. Jason Lumenello IP Engineering XO Communications -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Stephen J. Wilcox Sent: Wednesday, March 03, 2004 3:48 PM To: james Cc: [EMAIL PROTECTED] Subject: Re: UUNet Offer New Protection Against DDoS I'm puzzled by one aspect on the implementation.. how to build your customer prefix filters.. that is, we have prefix-lists for prefix and length. Therefore at present we can only accept a tagged route for a whole block.. not good if the announcement is a /16 etc ! Now, I could do as per the website at secsup.org which means we have a route-map entry to match the community before the filtering .. but that would allow the customer to null route any ip. What we need is one to allow them to announce any route including more specifics of the prefix list - how are folks doing this? Steve On Wed, 3 Mar 2004, james wrote: Global Crossing has this, already in production. I was on the phone with Qwest yesterday & this was one of this things I asked about. Qwest indicated they are going to deploy this shortly. (i.e., send routes tagged with a community which they will set to null) James Edwards Routing and Security [EMAIL PROTECTED] At the Santa Fe Office: Internet at Cyber Mesa Store hours: 9-6 Monday through Friday 505-988-9200 SIP:1(747)669-1965
Re: UUNet Offer New Protection Against DDoS
We still implement exact match prefix filtering, but also generate a second "aggregated" prefix-list for customers to match more specifics. If a prefix matches 3561:666 _and_ falls within the DDoS/aggregated prefix-list, we accept it and blackhole it. If a customer announces the more specific without the community, we won't accept it. (No flame wars about exact match filtering please). Yes, that means we maintain two prefix-lists for each customer. uRPF is another matter. We use policies for prefix-lists on Junipers and prefix-lists on Cisco's, which means that if we want to do strict uRPF for customers we have to generate a third prefix-list/acl? Regards, Mark Kasten C&W^H^H^H^Savvis . Stephen J. Wilcox wrote: I'm puzzled by one aspect on the implementation.. how to build your customer prefix filters.. that is, we have prefix-lists for prefix and length. Therefore at present we can only accept a tagged route for a whole block.. not good if the announcement is a /16 etc ! Now, I could do as per the website at secsup.org which means we have a route-map entry to match the community before the filtering .. but that would allow the customer to null route any ip. What we need is one to allow them to announce any route including more specifics of the prefix list - how are folks doing this? Steve On Wed, 3 Mar 2004, james wrote: Global Crossing has this, already in production. I was on the phone with Qwest yesterday & this was one of this things I asked about. Qwest indicated they are going to deploy this shortly. (i.e., send routes tagged with a community which they will set to null) James Edwards Routing and Security [EMAIL PROTECTED] At the Santa Fe Office: Internet at Cyber Mesa Store hours: 9-6 Monday through Friday 505-988-9200 SIP:1(747)669-1965
Re: Cable & Wireless, Verio and/or Level 3 port blocking?
Cable & Wireless is not doing any port filtering, with the possible exception of specific customer requests. Regards, Mark William Devine, II wrote: Can anyone from these three carriers tell me if you're doing port blocking on the Windows file/print ports (135-139, 445 & 593) ? A client of ours (in the US), against our recommendation, still wants to connect to their Exchange server in the UK without a VPN. We're not blocking their IP#'s from anything but somewhere in between it's getting blocked. We use C&W directly and Verio/Level3 through a peer. Thanks! william
Re: cw to att? issue?
No issues to report, probably a return path issue. It'd be easier to confirm that with a traceroute showing the latency. And you will get a timely response from [EMAIL PROTECTED], which is where this email belongs. Regards, Mark Kasten Cable & Wireless Scott Granados wrote: Anyone else seeing an issue between cw and att somewhere near sf it looks like. I go from 4 ms, at the point tagged as the peer between cw and att and 1400 ms once I land on att. THanks
RE: XO problems?
Before there is wild speculation since cw.net shows up in the path We
are not experiencing any issues in DC or NY that would cause the problem
below. I have dropped in traceroutes from the ingress to our network from
XO to Cisco.com, and back to the first hop in the traceroute in Joe's
traceroute to demonstrate that CW is forwarding packets as we are supposed
to do. :-)
If there are questions regarding routing issues within AS3561, [EMAIL PROTECTED]
would be happy to investigate and respond.
Regards,
Mark Kasten
Cable & Wireless
[EMAIL PROTECTED]> traceroute www.cisco.com
traceroute to www.cisco.com (198.133.219.25), 30 hops max, 40 byte packets
1 agr2-loopback.NewYork.cw.net (206.24.194.102) 1.131 ms
agr1-loopback.NewYork.cw.net (206.24.194.101) 1.077 ms 1.001 ms
2 dcr2-so-7-1-0.NewYork.cw.net (206.24.207.197) 0.789 ms 0.650 ms
dcr2-so-6-0-0.NewYork.cw.net (206.24.207.177) 0.610 ms
3 agr4-so-4-0-0.NewYork.cw.net (206.24.207.78) 0.758 ms
agr3-so-2-0-0.NewYork.cw.net (206.24.207.186) 0.671 ms 0.704 ms
4 acr1-loopback.NewYork.cw.net (206.24.194.61) 1.026 ms 1.039 ms 0.912
ms
5 206.24.195.202 (206.24.195.202) 0.843 ms 0.799 ms 0.814 ms
6 gbr2-p70.n54ny.ip.att.net (12.123.1.134) 1.037 ms 0.863 ms 0.852 ms
7 tbr1-p013301.n54ny.ip.att.net (12.122.11.5) 1.261 ms 3.661 ms 1.650
ms
8 tbr1-cl1.cgcil.ip.att.net (12.122.10.5) 68.805 ms 68.180 ms 68.625 ms
9 tbr1-p013302.sffca.ip.att.net (12.122.11.217) 68.233 ms 68.018 ms
67.755 ms
10 gbr5-p100.sffca.ip.att.net (12.122.11.74) 66.266 ms 66.326 ms 66.368
ms
11 gar1-p360.sj2ca.ip.att.net (12.122.2.253) 67.636 ms 67.600 ms 67.711
ms
12 12.127.200.82 (12.127.200.82) 67.434 ms 67.357 ms 67.478 ms
13 sjck-dirty-gw1.cisco.com (128.107.239.9) 66.229 ms 66.220 ms 66.134
ms
14 sjck-sdf-ciod-gw1.cisco.com (128.107.239.106) 67.582 ms 67.750 ms
67.504 ms
^C
[EMAIL PROTECTED]> ping www.cisco.com
PING www.cisco.com (198.133.219.25): 56 data bytes
64 bytes from 198.133.219.25: icmp_seq=0 ttl=244 time=66.618 ms
64 bytes from 198.133.219.25: icmp_seq=1 ttl=244 time=66.287 ms
[EMAIL PROTECTED]> traceroute 132.237.9.3
traceroute to 132.237.9.3 (132.237.9.3), 30 hops max, 40 byte packets
1 agr1-loopback.NewYork.cw.net (206.24.194.101) 1.152 ms
agr2-loopback.NewYork.cw.net (206.24.194.102) 1.081 ms 0.823 ms
2 dcr2-so-6-0-0.NewYork.cw.net (206.24.207.177) 9.728 ms
dcr1-so-7-0-0.NewYork.cw.net (206.24.207.65) 0.797 ms
dcr2-so-7-1-0.NewYork.cw.net (206.24.207.197) 0.803 ms
3 dcr1-loopback.Washington.cw.net (206.24.226.99) 4.954 ms
dcr2-loopback.Washington.cw.net (206.24.226.100) 5.144 ms
dcr1-loopback.Washington.cw.net (206.24.226.99) 4.943 ms
4 agr2-so-0-0-0.Washington.cw.net (206.24.238.54) 4.851 ms
agr2-so-2-0-0.Washington.cw.net (206.24.238.182) 4.770 ms 4.692 ms
5 iar2-loopback.Washington.cw.net (206.24.226.13) 5.180 ms 5.167 ms
5.065 ms
6 xo-communication-telc-audit.Washington.cw.net (208.173.10.70) 5.402 ms
4.883 ms 5.632 ms
7 ge5-3-1.RAR1.Washington-DC.us.xo.net (64.220.0.222) 6.359 ms 6.010 ms
6.067 ms
8 p1-0-0.RAR1.SanJose-CA.us.xo.net (65.106.0.38) 78.736 ms 78.773 ms
79.209 ms
9 p4-0-0.MAR1.Fremont-CA.us.xo.net (65.106.5.142) 78.519 ms 78.741 ms
78.407 ms
10 p0-0.CHR1.Fremont-CA.us.xo.net (207.88.80.10) 79.890 ms 79.791 ms
80.193 ms
11 67.104.110.114 (67.104.110.114) 81.329 ms 82.717 ms 81.717 ms
12 * * *
13 * * *
14 * * *
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Joe
Blanchard
Sent: Wednesday, April 17, 2002 4:03 PM
To: '[EMAIL PROTECTED]'
Subject: XO problems?
Anyone seeing issues with XO routing?
/root# traceroute www.cisco.com
traceroute to www.cisco.com (198.133.219.25), 30 hops max, 38 byte packets
1 132.237.9.3 (132.237.9.3) 3.510 ms 0.448 ms 0.443 ms
2 132.237.245.1 (132.237.245.1) 0.739 ms 0.791 ms 0.790 ms
3 67.104.110.113 (67.104.110.113) 1.826 ms 2.091 ms 1.860 ms
4 p4-3-0.MAR1.Fremont-CA.us.xo.net (207.88.80.9) 2.044 ms 2.088 ms
2.112 ms
5 p5-1-0-0.RAR1.SanJose-CA.us.xo.net (65.106.5.141) 2.438 ms 2.371 ms
2.368
ms
6 p1-0-0.RAR1.Washington-DC.us.xo.net (65.106.0.37) 82.448 ms 87.242 ms
82.
110 ms
7 p6-0-0.RAR2.NYC-NY.us.xo.net (65.106.0.1) 86.110 ms 86.055 ms 86.090
ms
8 ge5-0.dist1.hud-ny.us.xo.net (64.220.3.65) 86.688 ms 86.560 ms 86.586
ms
9 ge6-0.edge1.hud-ny.us.xo.net (64.220.3.83) 86.734 ms 86.715 ms 86.835
ms
10 * * *
11 * * agr1-loopback.NewYork.cw.net (206.24.194.101) 3100.552 ms
12 * * *
