On 09/03/2009, at 1:44 PM, Jasper Bryant-Greene wrote:
>
> How is that different from normal IP routing? The other end always
> decides which way to send packets back to you, and in the event that
> your customer is multihomed, the return path might not even transit
> your AS.
I control my outbound and inbound routing. People only send packets
via routes I advertise and I can show a contractual relationship
between me and my upstream or peer, my upstream and theirs or their
peer and then to the far end etc.
With using 6to4 the downside is that whilst I may have my own gateway,
the FAR end could be using a 3rd party 6to4 gateway. This means that
the return packets traverse links for which I have no contractual
relationship.
I guess in some way I'm agreeing with Joe that everyone SHOULD run
their own, especially if they offer up content over IPv6. (I wonder
if Google do with ipv6.google.com?).
MMC
--
Matthew Moyle-Croft Internode/Agile Peering and Core Networks
Level 5, 162 Grenfell Street, Adelaide, SA 5000 Australia
Email: mmc(a)internode.com.au Web: http://www.on.net
Direct: +61-8-8228-2909 Mobile: +61-419-900-366
Reception: +61-8-8228-2999 Fax: +61-8-8235-6909
via Ausnog:
"Wholesale internet transit provider Vocus will create an internet peering
exchange to greatly cut latency between Sydney and Auckland.
The PacificIX exchange would go live "by the end of the year", Vocus (ASX:
VOC) chief executive officer James Spenceley (pictured) told iTnews today.
It would run out of the Equinix and Global Switch data centres in Sydney
and from the Auckland Sky Tower and a "second [undisclosed] node"
elsewhere in the NZ city."
http://www.itnews.com.au/News/232330,vocus-to-cut-sydney-auckland-latency.a…
--
Simon Lyall | Very Busy | Web: http://www.darkmere.gen.nz/
"To stay awake all night adds a day to your life" - Stilgar | eMT.
> In fact - what checks and balances are there to stop any ISP saying
> "chorus, churn phone 01 234 5678 to DodgyISP immediately"
This is the bit that is of most concern. From Joel's comment
> Wholesale get a job that says for instance "connect house X to DSLAM
> patch Y - for job ID XXXXX". all wholesale know is that there is a job
> and what they need to do.
It would appear that there may not be any or if they are that they may
be inadequate.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Glen Eustace
GodZone Internet Services, a division of AGRE Enterprises Ltd.
P.O. Box 8020, Palmerston North, New Zealand 4446.
Ph: +64 6 357 8168, Fax +64 6 357 8165, Mob: +64 27 542 4015
http://www.godzone.net.nz
"A Ministry specialising in providing low-cost Internet Services
to NZ Christian Churches, Ministries and Organisations."
Hi Folks,
All this talk today about outages and the like had me looking at something I know about that I'm not sure everyone else is aware of but nevertheless is fairly awesome. H/T to the lads and ladettes at WAND.
http://erg.wand.net.nz/amp/matrix.php/ipv4/latency/NZ/
If there were more nodes in the system we'd all get a better idea of what parts of NZ's internet are affected in times of trouble.
Enjoy.
jamie
We've been doing maintenance work involving moving spanning tree roots
and we've experiencing considerable network instability.
We've tracked the issue down to a 7609 that has crashed to the point the
supervisor won't respond (lots of stack traces in the logs). Engineers
are now on site with replacement hardware.
No ETA for full restoration of services at this stage.
Dylan
Time to check your electrolytic caps
-------- Original Message --------
Subject: [Disconnect] RailCorp Sydenham signalling failure report
From: Andrew McNamara <andrewm(a)object-craft.com.au>
To: disconnect(a)object-craft.com.au
CC:
RailCorp has released their report into the 12 April Sydenham signalling
failure (which crippled the whole metro network). They found it to be
due to a Cisco switch with leaky electrolytic caps repeatedly bouncing
(see the linked PDF):
http://www.railcorp.info/publications/sydenham
--
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au/
_______________________________________________
Disconnect mailing list
Disconnect(a)object-craft.com.au
https://www.object-craft.com.au/cgi-bin/mailman/listinfo/disconnect
Great stuff.
...Skeeve
--
Skeeve Stevens, CEO - eintellego Pty Ltd - The Networking Specialists
skeeve(a)eintellego.net<mailto:skeeve@eintellego.net> ; www.eintellego.net
Phone: 1300 753 383 ; Fax: (+612) 8572 9954
Cell +61 (0)414 753 383 ; skype://skeeve
facebook.com/eintellego or eintellego(a)facebook.com<mailto:eintellego@facebook.com>
twitter.com/networkceoau ; www.linkedin.com/in/skeeve
PO Box 7726, Baulkham Hills, NSW 1755 Australia
--
eintellego - The Experts that the Experts call
- Juniper - HP Networking - Cisco - Brocade - Arista - Allied Telesis
On 28/04/11 2:45 PM, "Nathalie Trenaman" <nathalie(a)ripe.net<mailto:nathalie@ripe.net>> wrote:
Dear Colleagues,
The RIPE NCC is pleased to announce the launch of four new information videos on real-life IPv6 deployment experiences.
The following videos are now available in the RIPE NCC's E-Learning Centre at:
http://www.ripe.net/lir-services/training/e-learning/ipv6
- Jan Žorž talks about "Mobile IPv6"
- Tore Anderson gives an overview on "IPv6 and Content Providers"
- Nuno Viera talks about "IPv6 in Hosting Environments"
- Teun Vink is interviewed about "IPv6 and ISPs"
The RIPE NCC E-Learning Centre is free and available to everyone.
If you have any questions about this, please contact us at <e-learning(a)ripe.net<mailto:e-learning@ripe.net>>.
Regards,
Nathalie Trenaman
Trainer
RIPE NCC
Dear Colleague,
This is to notify you that one or more objects in which you are
designated for notification have been modified in the NZRR routing
registry database.
These objects are used to configure the various NZIX route servers
(http://nzix.net/) so you can expect the relevant servers to be reloaded
in the near future. The reloading of the servers is staggered over a
period of time so that if you are peering with both servers at an
exchange, you can maintain at least one BGP session at all times and
consequently a full set of routes.
Diagnostic output:
------------------------------------------------------------
---
PREVIOUS OBJECT:
route-set: AS9560:RS-ROUTES:AS9738
descr: Route set advertised to AS9560 by Brennan IT - AS9738
members: 61.88.58.0/24^24-29
admin-c: RPA1-NZRR
tech-c: RPA1-NZRR
notify: rpsl-admin(a)nzix.net
notify: nznog(a)list.waikato.ac.nz
notify: benc(a)brennanit.com.au
mnt-by: MAINT-NZRR-NZ
changed: rpsl-admin(a)nzix.net 20110427
source: NZRR
REPLACED BY:
route-set: AS9560:RS-ROUTES:AS9738
descr: advertised to AS9560 by Brennan IT - AS9738
members: 125.253.0.0/18^18-29,
123.100.128.0/19^19-29,
180.214.64.0/19^19-29,
202.171.160.0/19^19-29,
210.18.192.0/19^19-29,
223.165.96.0/19^19-29,
61.14.96.0/20^20-29,
125.253.96.0/20^20-29,
202.148.224.0/20^20-29,
203.149.64.0/20^20-29,
61.14.112.0/21^21-29,
110.44.24.0/21^21-29,
115.178.16.0/21^21-29,
175.176.200.0/21^21-29,
182.23.192.0/21^21-29,
210.18.240.0/21^21-29,
61.14.124.0/22^22-29,
115.69.28.0/22^22-29,
115.69.60.0/22^22-29,
119.17.160.0/22^22-29,
119.17.168.0/22^22-29,
180.94.236.0/22^22-29,
180.189.152.0/22^22-29,
203.12.48.0/22^22-29,
203.62.184.0/22^22-29,
203.211.56.0/22^22-29,
210.18.228.0/22^22-29,
210.18.236.0/22^22-29,
210.18.248.0/22^22-29,
202.14.192.0/23^23-29,
202.83.78.0/23^23-29,
202.92.94.0/23^23-29,
202.150.60.0/23^23-29,
203.1.68.0/23^23-29,
203.4.182.0/23^23-29,
203.18.134.0/23^23-29,
203.28.202.0/23^23-29,
203.29.208.0/23^23-29,
203.31.110.0/23^23-29,
203.33.60.0/23^23-29,
203.34.152.0/23^23-29,
203.55.174.0/23^23-29,
203.62.210.0/23^23-29,
203.185.194.0/23^23-29,
203.220.18.0/23^23-29,
203.220.26.0/23^23-29,
203.220.30.0/23^23-29,
203.220.34.0/23^23-29,
203.220.36.0/23^23-29,
204.61.210.0/23^23-29,
204.61.212.0/23^23-29,
204.61.216.0/23^23-29,
210.8.240.0/23^23-29,
210.18.224.0/23^23-29,
210.18.234.0/23^23-29,
210.87.34.0/23^23-29,
61.88.58.0/24^24-29,
115.69.64.0/24^24-29,
192.146.106.0/24^24-29,
194.146.107.0/24^24-29,
194.146.108.0/24^24-29,
199.7.64.0/24^24-29,
199.7.77.0/24^24-29,
202.4.175.0/24^24-29,
202.14.148.0/24^24-29,
202.31.144.0/24^24-29,
202.41.144.0/24^24-29,
202.43.66.0/24^24-29,
202.176.15.0/24^24-29,
203.0.80.0/24^24-29,
203.5.19.0/24^24-29,
203.5.194.0/24^24-29,
203.6.250.0/24^24-29,
203.9.64.0/24^24-29,
203.11.207.0/24^24-29,
203.12.39.0/24^24-29,
203.12.171.0/24^24-29,
203.13.222.0/24^24-29,
203.16.25.0/24^24-29,
203.16.236.0/24^24-29,
203.17.183.0/24^24-29,
203.18.94.0/24^24-29,
203.19.66.0/24^24-29,
203.19.157.0/24^24-29,
203.20.90.0/24^24-29,
203.20.125.0/24^24-29,
203.22.85.0/24^24-29,
203.23.105.0/24^24-29,
203.23.194.0/24^24-29,
203.24.11.0/24^24-29,
203.24.22.0/24^24-29,
203.24.125.0/24^24-29,
203.25.67.0/24^24-29,
203.25.120.0/24^24-29,
203.26.72.0/24^24-29,
203.27.127.0/24^24-29,
203.29.84.0/24^24-29,
203.29.214.0/24^24-29,
203.30.31.0/24^24-29,
203.30.32.0/24^24-29,
203.30.177.0/24^24-29,
203.30.216.0/24^24-29,
203.31.56.0/24^24-29,
203.31.82.0/24^24-29,
203.31.246.0/24^24-29,
203.34.142.0/24^24-29,
203.55.112.0/24^24-29,
203.56.0.0/24^24-29,
203.56.78.0/24^24-29,
203.56.230.0/24^24-29,
203.57.10.0/24^24-29,
203.57.23.0/24^24-29,
203.57.81.0/24^24-29,
203.57.147.0/24^24-29,
203.161.132.0/24^24-29,
203.220.20.0/24^24-29,
203.220.33.0/24^24-29,
203.220.38.0/24^24-29,
210.8.64.0/24^24-29,
210.8.248.0/24^24-29,
210.18.227.0/24^24-29,
210.18.232.0/24^24-29,
210.18.252.0/24^24-29,
210.18.254.0/24^24-29,
210.56.153.0/24^24-29,
210.56.159.0/24^24-29,
216.75.222.0/24^24-29
admin-c: RPA1-NZRR
tech-c: RPA1-NZRR
notify: rpsl-admin(a)nzix.net
notify: nznog(a)list.waikato.ac.nz
notify: benc(a)brennanit.com.au
mnt-by: MAINT-NZRR-NZ
changed: rpsl-admin(a)nzix.net 20110429
source: NZRR
------------------------------------------------------------
KSK CEREMONY 5
The fifth KSK ceremony for the root zone will take place in Culpeper,
VA, USA on Wednesday 2011-05-11. The ceremony is scheduled to begin
at 1300 local time (1700 UTC) and is expected to end by 1600 local
time (2000 UTC).
Video from Ceremony 5 will be recorded for audit purposes. Video
and associated audit materials will be published 1 to 2 weeks after
the ceremony, and will be available as usual by following the "KSK
Ceremony Materials" link at <https://www.iana.org/dnssec/>.
ICANN will operate a separate camera whose video will not be retained
for audit purposes, but which will instead be streamed live in order
to provide remote observers an opportunity to watch the ceremony.
The live stream will be provided on a best-effort basis. The live
video stream will be available at <http://dns.icann.org/ksk/stream/>.
Ceremony 5 will include processing of a Key Signing Request (KSR)
generated by VeriSign, and the resulting Signed Key Response (SKR)
will contain signatures for Q3 2011.
CONTACT INFORMATION
We'd like to hear from you. If you have feedback for us, please
send it to rootsign(a)icann.org.