Re: Asian exchange points

2002-05-12 Thread Philip Smith


Richard,

There are several exchange points, but their functions tend to be slightly 
different from what is understood in the US. IXes such as SOX (Singapore), 
HKIX (Hong Kong), JPIX  NSP-IXP2 (Japan) and KIX  KINX (Korea) tend to be 
the more oft quoted IXes in Asia and are familiar in design and function. 
The others are either very much in-country exchanges offering neutral 
traffic exchange, or being run by one operator as a for profit transit 
service provider. (Consider in the latter cases the use of the word 
exchange as a marketing term... ;-)

As others have pointed out, www.ep.net has the list of all the known ones. 
Hope this helps.

philip
--


At 12:43 11/05/2002 -0400, Richard A Steenbergen wrote:

I know this isn't quote North American, but does anyone know what major
exchange points exist in Asia? The largest one I've found so far is JPIX,
which seems to move a fair amount of traffic
(http://www.jpix.co.jp/en/techncal/traffic.html). Any other major ones?

--
Richard A Steenbergen [EMAIL PROTECTED]   http://www.e-gerbil.net/ras
PGP Key ID: 0x138EA177  (67 29 D7 BC E8 18 3E DA  B2 46 B3 D8 14 36 FE B6)




New SubSeven outbreak?

2002-05-12 Thread Jeff Workman


All,

I have seen 6 portscans looking for SubSeven on a /24 in the past 24 hours. 
It'd been a while since I had seen *any*, now I'm seeing all these.  Is 
this a new outbreak/vulnerability, or have I just been lucky?  Has anybody 
else seen an increase in scans on tcp port 27374?

I scanned through BugTraq and didn't see any mention of anything there.

-J

--
Jeff Workman | [EMAIL PROTECTED] | http://www.pimpworks.org



Re: New SubSeven outbreak?

2002-05-12 Thread Johannes B. Ullrich



 I have seen 6 portscans looking for SubSeven on a /24 in the past 24 hours. 
 It'd been a while since I had seen *any*, now I'm seeing all these.  Is 
 this a new outbreak/vulnerability, or have I just been lucky?  Has anybody 
 else seen an increase in scans on tcp port 27374?

There are a number of IRC controlled bots that will allow 
scanning of subnets for Sub7. So you will see occasional
flameups of Sub7 scans as they happen to focus on your
network. Try to connect to some of the cable modem in 24/8
and you will see more of that.

I should still have a little perl honeypot around that you can use
to find out what they try to install on sub7 infected machines.

-- 
---
[EMAIL PROTECTED]Join http://www.DShield.org
  Distributed Intrusion Detection System





Re: New SubSeven outbreak?

2002-05-12 Thread Jeff Workman




Stoned koala bears drooled eucalyptus spit in awe as Johannes B. Ullrich 
exclaimed:



 I have seen 6 portscans looking for SubSeven on a /24 in the past 24
 hours.  It'd been a while since I had seen *any*, now I'm seeing all
 these.  Is  this a new outbreak/vulnerability, or have I just been
 lucky?  Has anybody  else seen an increase in scans on tcp port 27374?

 There are a number of IRC controlled bots that will allow
 scanning of subnets for Sub7. So you will see occasional
 flameups of Sub7 scans as they happen to focus on your
 network. Try to connect to some of the cable modem in 24/8
 and you will see more of that.

 I should still have a little perl honeypot around that you can use
 to find out what they try to install on sub7 infected machines.

Thanks for the pointer.  I looked on www.sans.org for it, but couldn't find 
it, but I found one on another site called leaves that seems to do what I 
need.  It's going to be amusing to see IRC bots try to upload windows EXE 
files to a NetBSD machine and try to run them.

-J

--
Jeff Workman | [EMAIL PROTECTED] | http://www.pimpworks.org



Re: BGP and aggregation

2002-05-12 Thread Scott Granados


Don't forget that if both sites use the same as even if the connection 
link drops they will not be able to see each  other over the upstream 
provider as routers won't take the srutes from the same as.  If this 
isn't a problem don't worry about it.  If you wish to preserve 
connectivity between cities you should have a back-up link or use 
different as's or gre tunnels:).

On Sat, 11 May 2002, Ralph Doncaster 
wrote:

 
 I have transit in 2 cities.  I have a circuit connecting the 2 cities as
 well.  So far I've been using non-contiguous IPs, so there's been no
 opportunity for aggregation.  Having just received my /20 from ARIN, I'm
 trying to plan my network.  Lets say I split the /20 into 2 /21's, one for
 each city.  I'd like to announce the aggregate /20 instead of 2 /21's, as
 long as the circuit connecting the 2 cities is working.  If the circuit
 goes down I want each city to announce the local /21.  Is this
 possible? (using either a Cisco router or Zebra)
 
 Ralph Doncaster
 principal, IStop.com 
 div. of Doncaster Consulting Inc.
 




Re: BGP and aggregation

2002-05-12 Thread Scott Granados


-
This is a great solution to a point.  I did this, with the help of 
someone who reads this list frequently:) but you have to jump through 
some hoops should you wish both cities to reach each other.  Assuming 
for example all your dns and mail servers are in one city you'd have to 
jump through this hoop.  

On Sat, 11 May 2002, Richard A Steenbergen wrote:

 
 On Sat, May 11, 2002 at 05:34:39PM -0400, Ralph Doncaster wrote:
  
  I have transit in 2 cities.  I have a circuit connecting the 2 cities as
  well.  So far I've been using non-contiguous IPs, so there's been no
  opportunity for aggregation.  Having just received my /20 from ARIN, I'm
  trying to plan my network.  Lets say I split the /20 into 2 /21's, one for
  each city.  I'd like to announce the aggregate /20 instead of 2 /21's, as
  long as the circuit connecting the 2 cities is working.  If the circuit
  goes down I want each city to announce the local /21.  Is this
  possible? (using either a Cisco router or Zebra)
 
 If I was paying for transit, I would want THEM to do the work of 
 delivering it to the right city, without wasting the bandwidth of my 
 circuit (unless they're really close and that circuit is really cheap).
 
 If you're using the same transit provider in both cities, how about
 announcing the /20, and the 2 /21s tagged with no-export. The /20 would be
 heard by the world and get the traffic to your transit provider, then the
 /21s would route it to the right exit point.
 
 




Re: BGP and aggregation

2002-05-12 Thread Stephen J. Wilcox



Interesting point there Scott.. we were discussing just that at a recent
IXP meeting I was at. Theres a number of different ways (well hacks) in
which you can keep connectivity between two halves of an AS network in the
event of a split. 

Is anyone out there actually doing something either this or similar to
keep two halves connected in the event of a split.. and have you actually
run successfully on your backup and maintained a reasonable throughput
(say 30 or 40Mbs) ? I'd be interested if anyone has a proven technique as
I want to implement something myself and dont really want to test it by
pulling the plug on some backbone links and waiting to see what happens!

Steve

On Sun, 12 May 2002, Scott Granados wrote:

 
 Don't forget that if both sites use the same as even if the connection 
 link drops they will not be able to see each  other over the upstream 
 provider as routers won't take the srutes from the same as.  If this 
 isn't a problem don't worry about it.  If you wish to preserve 
 connectivity between cities you should have a back-up link or use 
 different as's or gre tunnels:).
 
 On Sat, 11 May 2002, Ralph Doncaster 
 wrote:
 
  
  I have transit in 2 cities.  I have a circuit connecting the 2 cities as
  well.  So far I've been using non-contiguous IPs, so there's been no
  opportunity for aggregation.  Having just received my /20 from ARIN, I'm
  trying to plan my network.  Lets say I split the /20 into 2 /21's, one for
  each city.  I'd like to announce the aggregate /20 instead of 2 /21's, as
  long as the circuit connecting the 2 cities is working.  If the circuit
  goes down I want each city to announce the local /21.  Is this
  possible? (using either a Cisco router or Zebra)
  
  Ralph Doncaster
  principal, IStop.com 
  div. of Doncaster Consulting Inc.
  
 
 





Re: Asian exchange points

2002-05-12 Thread Bill Woodcock


 There are several exchange points, but their functions tend to be slightly
 different from what is understood in the US. IXes such as SOX (Singapore),
 HKIX (Hong Kong), JPIX  NSP-IXP2 (Japan) and KIX  KINX (Korea) tend to be
 the more oft quoted IXes in Asia and are familiar in design and function.

Yeah, what Phil said.

Note that HKIX is the longest-established of those, although no longer by
any means the largest.  KIX/KINX carry the greatest volume of traffic by
far, but it's almost exclusively local intra-Korean traffic.  JPIX is, as
you note, probably your first choice if you're going to pick only one
exchange, you're coming in from outside the region, and you have to pick
today.

That choice is much harder in Asia right now than in north America or
Europe, where the choices are obvious.  An even tougher question is what
to do for a second exchange in Asia.  These questions are being addressed
though...  APIA is sponsoring a meeting in association with the next APNIC
meeting, exclusively on this topic, where Phil and I and Bill Manning and
other folks will be trying to help folks within the region come to some
consensus.

 As others have pointed out, www.ep.net has the list of all the known ones.

Bill, Antony, and I consolidated our three lists into one, which is at
http://www.pch.net/documents/data/exchange-points/

-Bill





Re: BGP and aggregation

2002-05-12 Thread Stephen Griffin


In the referenced message, E.B. Dreger said:
 * BGP is an EGP, not an IGP

BGP is one half of an IGP, it is the where to go half.
You generally run another IGP along with it to provide the
how to get there half. Most folks run isis or ospf to
transport router loopbacks and other next-hop information, but
still transport the majority of routes via bgp.




Re: BGP and aggregation

2002-05-12 Thread Scott Granados


Actually I ran this way for a while as a primary.  I had three sites 
attached via cogent entirely all announcing a /19 and the internally a 
/21 each and a couple /21's out of the primary location.  In the main 
location was a 7507 and in the two other pops 6509's.  We set ospf 
internally, set up bgp for the announcements at each site and used the 
no-export tag for the more specifics.  Then gre tunnels:) for the 
internal.  It worked and I pushed probably 45 to 50mb over the internal 
loops or gre tunnels.  Not ideal but it worked.

On Sun, 12 May 2002, 
Stephen J. Wilcox wrote:

 
 Interesting point there Scott.. we were discussing just that at a recent
 IXP meeting I was at. Theres a number of different ways (well hacks) in
 which you can keep connectivity between two halves of an AS network in the
 event of a split. 
 
 Is anyone out there actually doing something either this or similar to
 keep two halves connected in the event of a split.. and have you actually
 run successfully on your backup and maintained a reasonable throughput
 (say 30 or 40Mbs) ? I'd be interested if anyone has a proven technique as
 I want to implement something myself and dont really want to test it by
 pulling the plug on some backbone links and waiting to see what happens!
 
 Steve
 
 On Sun, 12 May 2002, Scott Granados wrote:
 
  
  Don't forget that if both sites use the same as even if the connection 
  link drops they will not be able to see each  other over the upstream 
  provider as routers won't take the srutes from the same as.  If this 
  isn't a problem don't worry about it.  If you wish to preserve 
  connectivity between cities you should have a back-up link or use 
  different as's or gre tunnels:).
  
  On Sat, 11 May 2002, Ralph Doncaster 
  wrote:
  
   
   I have transit in 2 cities.  I have a circuit connecting the 2 cities as
   well.  So far I've been using non-contiguous IPs, so there's been no
   opportunity for aggregation.  Having just received my /20 from ARIN, I'm
   trying to plan my network.  Lets say I split the /20 into 2 /21's, one for
   each city.  I'd like to announce the aggregate /20 instead of 2 /21's, as
   long as the circuit connecting the 2 cities is working.  If the circuit
   goes down I want each city to announce the local /21.  Is this
   possible? (using either a Cisco router or Zebra)
   
   Ralph Doncaster
   principal, IStop.com 
   div. of Doncaster Consulting Inc.
   
  
  
 
 




Re: BGP and aggregation

2002-05-12 Thread E.B. Dreger


SJW Date: Sun, 12 May 2002 21:07:50 +0100 (BST)
SJW From: Stephen J. Wilcox


SJW Is anyone out there actually doing something either this or
SJW similar to keep two halves connected in the event of a
SJW split.. and have you actually run successfully on your
SJW backup and maintained a reasonable throughput (say 30 or
SJW 40Mbs) ? I'd be interested if anyone has a proven technique

Anyone know more than myself about InterNAP who can disclose
details?


--
Eddy

Brotsman  Dreger, Inc. - EverQuick Internet Division
Phone: +1 (316) 794-8922 Wichita/(Inter)national
Phone: +1 (785) 865-5885 Lawrence

~
Date: Mon, 21 May 2001 11:23:58 + (GMT)
From: A Trap [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Please ignore this portion of my mail signature.

These last few lines are a trap for address-harvesting spambots.
Do NOT send mail to [EMAIL PROTECTED], or you are likely to
be blocked.




Re: BGP and aggregation

2002-05-12 Thread Andy Walden


On Sun, 12 May 2002, Stephen Griffin wrote:


 In the referenced message, Andy Walden said:
 
 
  Conditional Router Advertisement:
 
  http://www.american.com/warp/public/459/cond_adv.pdf
 

 As it sounds like he's using a single AS, the above may not be
 a fix, since a partitioned AS is still a failure condition.

Why?

If you announce one prefix via one circuit and announce a different
prefix via a different with the same source AS, I don't see a problem
since traffic will continue to reach its intended destination.

andy
--
PGP Key Available at http://www.tigerteam.net/andy/pgp




Re: BGP and aggregation

2002-05-12 Thread Stephen Griffin


In the referenced message, Andy Walden said:
 On Sun, 12 May 2002, Stephen Griffin wrote:
 
 
  In the referenced message, Andy Walden said:
  
  
   Conditional Router Advertisement:
  
   http://www.american.com/warp/public/459/cond_adv.pdf
  
 
  As it sounds like he's using a single AS, the above may not be
  a fix, since a partitioned AS is still a failure condition.
 
 Why?
 
 If you announce one prefix via one circuit and announce a different
 prefix via a different with the same source AS, I don't see a problem
 since traffic will continue to reach its intended destination.
 
 andy

BGP will discard any prefix with its own AS in the path, for loop
prevention. Hence, one half of the AS would still be unable to
reach the other half. This is why a partitioned AS is a failure
condition. A tunnel is a means to keep the AS nonpartitioned.

There are other ways to treat the symptoms, but they aren't
particularly good, imho.




Re: BGP and aggregation

2002-05-12 Thread Andy Walden



On Sun, 12 May 2002, Stephen Griffin wrote:

 BGP will discard any prefix with its own AS in the path, for loop
 prevention. Hence, one half of the AS would still be unable to
 reach the other half. This is why a partitioned AS is a failure
 condition. A tunnel is a means to keep the AS nonpartitioned.

 There are other ways to treat the symptoms, but they aren't
 particularly good, imho.

True. This also assumes that we aren't talking about vanilla access here
or perhaps you don't have local servers. This could also be fixed with a
floating static I suppose as well. At any rate, it depends on your setup I
suppose. Connecting remote offices != Bad, Vanilla access = probably
tolerable.

andy

--
PGP Key Available at http://www.tigerteam.net/andy/pgp




Re: BGP and aggregation

2002-05-12 Thread Ralph Doncaster


  isn't a problem don't worry about it.  If you wish to preserve
  connectivity between cities you should have a back-up link or use
  different as's or gre tunnels:).
 
 Floating statics would be a less-hassle means to continue connectivity
 (with only 2 locations not much of a scaling issue).  Or, if you want, a
 default route (learned via BGP if possible) going to your upstream(s).  An
 IBGP session sharing full routing information might not be something you
 want to keep established over a GRE tunnel.

Hmm... the default route idea sounds even easier than my iBGP over a
transit link.  I think I'll try your idea first.

-Ralph





Re: BGP and aggregation

2002-05-12 Thread Forrest W. Christian


On Sun, 12 May 2002, Stephen J. Wilcox wrote:

 Interesting point there Scott.. we were discussing just that at a recent
 IXP meeting I was at. Theres a number of different ways (well hacks) in
 which you can keep connectivity between two halves of an AS network in the
 event of a split.

 Is anyone out there actually doing something either this or similar to
 keep two halves connected in the event of a split.. and have you actually
 run successfully on your backup and maintained a reasonable throughput
 (say 30 or 40Mbs) ? I'd be interested if anyone has a proven technique as
 I want to implement something myself and dont really want to test it by
 pulling the plug on some backbone links and waiting to see what happens!

My answer isn't even to close to your reasonable throughput as the example
is only T1 connected, but I have a site which we are only connected to via
a non-igp path.  Everything is via the internet (well sprint.net usually).

We're announcing a /18 to sprint at our main site, and a /23 at the
disconnected site.  The disconnected site points default at sprint,
and doesn't take a full routing table.  Basically we have BGP up at the
disconnected site just to announce the /23 with our AS.

With some creative use of cisco routing tools including OSPF, GRE tunnels,
and some creative static routing we maintain decent connectivity between
the two sites.  It works quite well.  In fact, it works well enough that
we're starting to buy circuits at each of our POPs as it is cheaper to buy
circuits from sprint or similar to their internet PoPs than it is to buy
circuits around the state.  In most cases we will still be maintaining
internal connectivity for backup and latency reasons.

- Forrest W. Christian ([EMAIL PROTECTED]) AC7DE
--
The Innovation Machine Ltd.  P.O. Box 5749
http://www.imach.com/Helena, MT  59604
Home of PacketFlux Technogies and BackupDNS.com (406)-442-6648
--
  Protect your personal freedoms - visit http://www.lp.org/