Looks like they found a new willing partner.
AS32335 PACIFICINTERNETEXCHANGE-NET - Pacific Internet Exchange LLC.
http://cidr-report.org/cgi-bin/as-report?as=AS27595
http://www.pacificinternetexchange.net/
Marc
I like how their web page says "Network Uptime: 03:56:55 up 1562 days,
17:51 (100%) 1 user, load average: 0.03, 0.03, 0.02"
Now, the difference between host and network aside, I find the idea of
their having one user a little amusing. I've seen that truck around the
parking lot of 200 Paul. Tim P., you going to go have a little chat with
them for us?
-Bill
What's amusing about having one user on that particular host?
B
That's the _front page of their corporate web site_. It doesn't say
"host" it says that's their _network_.
-Bill
You already made that distinction - "Now, the difference between host and
network aside" - although perhaps I misinterpreted your point.
In that case, my apologies.
B
looks to me as if they are just using output of 'top' and displaying
it there as it were for network stats.
output of top from one of my boxes..
top - 11:39:48 up 3 days, 20:56, 3 users, load average: 0.07, 0.21, 0.16
For your reading enjoyments, their peering guidelines verbiage is at
http://www.pacificinternetexchange.net/?page=peering and their transit SLA is
at http://www.pacificinternetexchange.net/?page=sla
The differences in the termination clauses of the two agreements make
interesting reading. If a bit dull.
In summary, for this specific network exchange's situations only:
1.) Peers may be terminated for a number of reasons (or for no reason at all,
with 30 days notice). There is of course the normal 'no transit through our
network' verbiage, and a temporary instant disconnect clause for serious
problems (clauses 5.2 and 5.3). Patrick's favorite clause will likely be
5.5, where PIE reserves the right to refuse interconnection with or without
any reason. I find it most interesting that they feel the need to enumerate
an obvious right of a provider not normally worth mentioning.
2.) Customers have more rights than peers (obviously; consideration is
changing hands). One relevant section is IV(C) of their SLA. They at least
say the tough line against spam, and a depeering notice from one of their
peers carries great weight (as it should, of course). But, in section IV(I)
PIE makes a connection guarantee. That is their right to do, obviously, but
gives the customer the right to the connection as long as the customer plays
by the rules. No arbitrary disconnect ability there, for transit customers
at least. The agreement even warrants that PIE has the authority to grant the
rights under that agreement. Interesting wording.
So if you want to be able to shut down a BGP session at a whim, you'd best
make sure your agreement you executed allows for that; or exercise your right
as a provider to refuse the customer, one or the other.
It will be interesting to see how long this link stays active. And how long
it takes for Intercage to find another upstream. Money talks.
This is easy.
Hey Cogent (174), AboveNet (6461), and NTT/Verio (2914),
Could you guys please be sure you're not routing the following rogue
customer prefixes?
58.65.238.0/24
58.65.239.0/24
64.28.176.0/20
67.130.99.0/24
67.210.0.0/21
67.210.8.0/22
67.210.13.0/24
67.210.14.0/23
69.1.78.0/24
69.22.162.0/23
69.22.168.0/22
69.22.184.0/22
69.31.64.0/20
69.50.160.0/20
69.50.176.0/20
69.130.99.0/24
69.250.145.0/24
85.255.113.0/24
85.255.114.0/23
85.255.116.0/23
85.255.118.0/24
85.255.119.0/24
85.255.120.0/24
85.255.121.0/24
85.255.122.0/24
93.188.160.0/21
116.50.10.0/24
116.50.11.0/24
195.95.218.0/23
216.255.176.0/20
Thank you, and Drive Slow,
Paul Wall
For your reading enjoyments, their peering guidelines verbiage is at
http://www.pacificinternetexchange.net/?page=peering and their transit SLA is
at http://www.pacificinternetexchange.net/?page=sla
They don't seen to have ANY other clients than Intercage. Seems like the same operation to me. No?
This is easy.
Hey Cogent (174), AboveNet (6461), and NTT/Verio (2914),
Could you guys please be sure you're not routing the following rogue
customer prefixes?
I think your argument might be more convincing with those NOCs/abuse-desks if you provided or referred to evidence which shows those prefixes don't belong to them.
Playing devil's advocate here - it guarantees a connection, but does it also
guarantee that PIE won't null-route any of the customer's packets trying to
leave PIE's network at an upstream peer/transit point? 
However, if Gadi's claim that they don't seem to have any clients other than
Intercage is right, I'm sure the correct term for the connection guarantee
is "bulletproof"...
So if you want to be able to shut down a BGP session at a whim, you'd best
make sure your agreement you executed allows for that; or exercise your right
as a provider to refuse the customer, one or the other.
So... one other option which I've seen exercised is to keep the bgp
sessoin up and just not permit any routes in either direction. The
'customer connection' is still up, the link is pingable, all SLA's are
satisfied, the network doesn't have to guarantee 'routability' only
'connection'. Most every US network (at least) has the ability to shut
down interfaces/devices/sessions 'for the protection of their
network', in the worst case they may have to refund charges for the
monthly fees... though I'd note that in the place I saw the 'no
routes' used no chargebacks occured, despite the angry sales-driods
and customer(s).
In any case, there's no 'right' just some potentially flimsy legal
verbiage and 'we really dont want to make a habit of stomping on too
many customers'.
It will be interesting to see how long this link stays active. And how long
it takes for Intercage to find another upstream. Money talks.
agreed.
It may be, yes. Look at what else this AS is announcing:
http://www.spamhaus.org/sbl/sbl.lasso?query=SBL36453 (cernel/esthost)
http://www.spamhaus.org/sbl/sbl.lasso?query=SBL36702 (the infamous
UkrTeleGroup network)
http://www.spamhaus.org/sbl/sbl.lasso?query=SBL53319 (inhoster)
Interested parties can consult http://www.bofh.it/~md/drop-stats.txt
(randomly updated, I am still looking for a permanent home for it)
for a detailed list of who is announcing the networks listed in SBL
DROP, what else they announce and who is providing transit to the ASes
announcing them. The code used to generate it is available on request.
Hint: there is not just Intercage.
Hmmm. Callout to Randy Bush: tools like this and the techniques to use them
are tailor-made for cluepon, no?