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
On Fri, 12 Sep 2008 marcus.sachs@verizon.com wrote: > Looks like they found a new willing partner. 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
On Fri, 12 Sep 2008 marcus.sachs@verizon.com wrote: > Looks like they found a new willing partner.
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.
What's amusing about having one user on that particular host? B
On Fri, 12 Sep 2008, William Hamilton wrote: > What's amusing about having one user on that particular host? That's the _front page of their corporate web site_. It doesn't say "host" it says that's their _network_. -Bill
On Fri, 12 Sep 2008, William Hamilton wrote: > What's amusing about having one user on that particular host?
That's the _front page of their corporate web site_. It doesn't say "host" it says that's their _network_.
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 On Fri, Sep 12, 2008 at 11:13 AM, Bill Woodcock <woody@pch.net> wrote:
On Fri, 12 Sep 2008, William Hamilton wrote:
What's amusing about having one user on that particular host?
That's the _front page of their corporate web site_. It doesn't say "host" it says that's their _network_.
-Bill
On Friday 12 September 2008 04:29:13 marcus.sachs@verizon.com wrote:
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.
On Fri, 12 Sep 2008, Lamar Owen wrote:
On Friday 12 September 2008 04:29:13 marcus.sachs@verizon.com wrote:
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?
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.
On Fri, 12 Sep 2008 14:24:33 EDT, Lamar Owen said:
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
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"...
On 9/12/08, Lamar Owen <lowen@pari.edu> wrote:
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.
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 On Fri, Sep 12, 2008 at 4:29 AM, <marcus.sachs@verizon.com> wrote:
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
On Fri, 12 Sep 2008, Paul Wall wrote:
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.
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
On Fri, Sep 12, 2008 at 4:29 AM, <marcus.sachs@verizon.com> wrote:
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
-- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
participants (10)
-
Bill Woodcock -
Christian Koch -
Christopher Morrow -
Gadi Evron -
Lamar Owen -
marcus.sachs＠verizon.com -
Paul Wall -
Pekka Savola -
Valdis.Kletnieks＠vt.edu -
William Hamilton