Re: Usage data from Turkey
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 31/03/15 19:24, Jared Mauch wrote: On Tue, Mar 31, 2015 at 08:19:11PM +0300, Mehmet Akcin wrote: Hello Today March 31 , 2015 GMT +0200 1030am-4pm Turkey has suffered a major power outage impacting nearly 70M people. I am writing a blog post about power outage vs impact to network usage. I am looking for as much as useful network usage information possible related to Turkey. You may want to look at the RIPE Atlas project, they jsut did a similar thing on the power outage in The Netherlands. Density of RIPE Atlas probes in Turkey is quite low, probably too low to do something useful with: http://sg-pub.ripe.net/emile/turkey-atlas.pdf 7 probes disconnect at the same time around 7:30-ish UTC and number of probes returns to baselevel around 15:00 UTC. cheers, Emile - Jared -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJVG5ycAAoJEKxthF6wloMO5lsP/AwWxIar7LEMq6vlBdza/oJh v3hXVf6EmWG2GKv7eHEWVgBmq3+EXQpCq4XxqfZVnyL7jjpj8RIHhKYoXrkDR+bP ktVQxZL3i0XnGHbtcpdlo97LEmTzL1k5H25LxalkJKUAb96Cughrzano9JEuss39 5EHfOms6fG6sLx2im2fUtqve5e3OQLkognf/Vur1Sq/htTF9wpwViE2YUBlxHhcK Wlzq5Fjv55eycIVJAvnQqLRhjwhhJJqSZYwwSOTT6p7rmpoVmv4N5SvFylcqgcIh zME1fs1YPvny4mD51NYXNZfjCuXfbSkbe0eHIKWJkZN1Lk8au0MV+kPLf7x3hRt9 smn7IkJrnb0tVO3IamVq2o/8ENRQWfXRlAp0A7Rwr7aaLZ4KGqSFZZ2LVGNDP+9i AS6JNdpwYoFRLEguAnhzVfppQ6LHf7ZHuDmEWn5xSArafcpeasYaOyI79R+kER9E A+IdXL3cUEKm4/uhr22jDybCMXPQ94mLoTqiG7zbRQ5YGmkTQNkoZxh51LmcZ+0J AY4UeNtX0bscIEp3/lZpV75+spVtqz2BzKqxT4TdeBn4EZArmM2yJHHAh2bB9Jdm aaYmNoMoaaQhq3jy4cPtoUhM4J5zuq58pDIJK7T/QmNNBLhCLtnv8h4E4EjFttOk 70xd1Lu2YwNsG9qW5Wwp =BRjq -END PGP SIGNATURE-
From Europe to Australia via right way
Hello, There is some telecom, isp which have route from EU to AU via east or south east (via Russia, Red sea or other ways) ? Now i have path via US and looking something in opposite direction. thanks for some info, contact. Piotr
From Europe to Australia via right way
Hello, There is some telecom, isp which have route from EU to AU via east or south east (via Russia, Red sea or other ways) ? Now i have path via US and looking something in opposite direction. thanks for some info, contact. Piotr
Re: Experience Brocade ICX7750 and other vendor SFP
Hello, Brandon Martinlists.na...@monmotha.net , 31/3/2015 10:07 PM: I'm not sure where the VDX line ends up in this. It's apparently somewhat the result of actually merging the two technology lines, and it runs somewhat different software as a result. The VDX was AFAIK already in development before Brocade bought Foundry, which is further backed up by the fact that in e.g. FlexOptix's transceiver re-programming tool you have to select a Brocade Storage firmware for those transceivers rather than the Brocade IP firmware used for Foundry-like gear. It is however true that Brocade has since ported over a lot of Foundry features to the VDX platform. As for optics: it will work well (read: interface comes up and passes traffic) with most other-vendor transceivers even if you don't re-program, but like the Foundry-lineage kit you lose light level monitoring when the firmware doesn't match. Best regards, Martijn Schmidt http://www.i3D.net i3D.net is a private company registered in The Netherlands at Meent 93b, Rotterdam. Registration #: 14074337 - VAT # NL 8202.63.886.B01. i3D.net is CDSA certified on Content Protection and Security and provides hosting from 16 global ISO-certified datacenters. We are ranked in the Deloitte Technology Fast 500 EMEA as one of the fastest growing technology companies.
Charter NOC contact?
Can someone from Charter's NOC contact me off list? We have a mutual customer who's having issues and not getting anywhere going through normal channels. thanks
Re: From Europe to Australia via right way
you won't find internet packets going that way though (most of the time). You can buy a L2vpn, p2p, etc, that will though. On Wed, Apr 1, 2015 at 2:51 PM, joel jaeggli joe...@bogus.com wrote: On 4/1/15 3:14 AM, Piotr wrote: Hello, There is some telecom, isp which have route from EU to AU via east or south east (via Russia, Red sea or other ways) ? Now i have path via US and looking something in opposite direction. telstra ntt reliance retn all have eastbound paths from europe. thanks for some info, contact. Piotr
Re: From Europe to Australia via right way
Some times you can get luck and go through SE-ME-WE3 (we it's not cut) but most path's are via the US. What is your destination network in Australia. Matt On 2/04/2015 10:10 am, Tom Paseka wrote: you won't find internet packets going that way though (most of the time). You can buy a L2vpn, p2p, etc, that will though. On Wed, Apr 1, 2015 at 2:51 PM, joel jaeggli joe...@bogus.com wrote: On 4/1/15 3:14 AM, Piotr wrote: Hello, There is some telecom, isp which have route from EU to AU via east or south east (via Russia, Red sea or other ways) ? Now i have path via US and looking something in opposite direction. telstra ntt reliance retn all have eastbound paths from europe. thanks for some info, contact. Piotr -- /* Matt Perkins Direct 1300 137 379Spectrum Networks Ptd. Ltd. Office 1300 133 299m...@spectrum.com.au Level 6, 350 George Street Sydney 2000 Spectrum Networks is a member of the Communications Alliance TIO */
Re: RFC 7511 - Scenic Routing for IPv6
All my packets use recycled electrons. And recycled photons. Conservation of Energy isn't just a green idea...it's the LAW. On Wed, Apr 1, 2015 at 4:02 PM Jeff Walter jwal...@weebly.com wrote: I only buy free-ranged packets and you should too. On Wed, Apr 1, 2015 at 3:28 PM, valdis.kletni...@vt.edu wrote: On Wed, 01 Apr 2015 17:18:42 -0400, Sadiq Saif said: Informational of course. :) https://tools.ietf.org/html/rfc7511 It already has an errata filed. Follow the link. :)
Re: RFC 7511 - Scenic Routing for IPv6
The pigeon one is still my favorite, too. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Wed, Apr 1, 2015 at 7:39 PM, Stephen Satchell l...@satchell.net wrote: I'm sorry, packets are for the birds. https://tools.ietf.org/html/rfc2549 On 04/01/2015 04:35 PM, Gary Wardell wrote: My packets prefer owls. -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Thomas Maufer Sent: Wednesday, April 01, 2015 7:15 PM To: Jeff Walter; valdis.kletni...@vt.edu Cc: NANOG Subject: Re: RFC 7511 - Scenic Routing for IPv6 All my packets use recycled electrons. And recycled photons. Conservation of Energy isn't just a green idea...it's the LAW. On Wed, Apr 1, 2015 at 4:02 PM Jeff Walter jwal...@weebly.com wrote: I only buy free-ranged packets and you should too. On Wed, Apr 1, 2015 at 3:28 PM, valdis.kletni...@vt.edu wrote: On Wed, 01 Apr 2015 17:18:42 -0400, Sadiq Saif said: Informational of course. :) https://tools.ietf.org/html/rfc7511 It already has an errata filed. Follow the link. :)
Re: From Europe to Australia via right way
Yes, I believe PCCW had the route at one time. Roderick Beck Sales Director/Europe and the Americas Hibernia Networks http://www.hibernianetworks.com Budapest and New York 36-30-859-5144 rod.b...@hibernianetworks.com From: NANOG nanog-bounces+rod.beck=hibernianetworks@nanog.org on behalf of Piotr piotr.1...@interia.pl Sent: Wednesday, April 1, 2015 12:14 PM To: nanog@nanog.org Subject: From Europe to Australia via right way Hello, There is some telecom, isp which have route from EU to AU via east or south east (via Russia, Red sea or other ways) ? Now i have path via US and looking something in opposite direction. thanks for some info, contact. Piotr This e-mail and any attachments thereto is intended only for use by the addressee(s) named herein and may be proprietary and/or legally privileged. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this email, and any attachments thereto, without the prior written permission of the sender is strictly prohibited. If you receive this e-mail in error, please immediately telephone or e-mail the sender and permanently delete the original copy and any copy of this e-mail, and any printout thereof. All documents, contracts or agreements referred or attached to this e-mail are SUBJECT TO CONTRACT. The contents of an attachment to this e-mail may contain software viruses that could damage your own computer system. While Hibernia Networks has taken every reasonable precaution to minimize this risk, we cannot accept liability for any damage that you sustain as a result of software viruses. You should carry out your own virus checks before opening any attachment.
Re: From Europe to Australia via right way
I don’t believe anyone has significant IP network capacity going EU - Australia in that direction, esp. since once you get to Singapore, the options to get to Australia are limited. Even for networks that do have EU to Asia connectivity via Indian Ocean or land route to north Asia, the preferred path would be via US and transpac. -dorian On Apr 1, 2015, at 5:51 PM, joel jaeggli joe...@bogus.com wrote: On 4/1/15 3:14 AM, Piotr wrote: Hello, There is some telecom, isp which have route from EU to AU via east or south east (via Russia, Red sea or other ways) ? Now i have path via US and looking something in opposite direction. telstra ntt reliance retn all have eastbound paths from europe. thanks for some info, contact. Piotr
BGP offloading (fixing legacy router BGP scalability issues)
Hello, We've a lot of customers with Cisco 6500 routers (mostly with SUP720 supervisors) in operation. They are very popular with smaller ISPs in Africa/middle east due to their cheap price on the used marked and their fully sufficient routing performance for the given tasks. In practice the biggest problem with them is their poor BGP scalability due to the CPU/memory limitations. We're looking into options for a cheap fix for this problem. The idea is to offload BGP IPv4/IPv6 RIB calculation from the router to a standard server. All BGP sessions will be handled by the server. The server takes care of the RIB calculation and aggregates the result as much as possible (the aggregation potential of the global tables should be very high if it can completely ignore the AS path and only care about the next hop). The final optimized RIB is then pushed to the Router via an iBGP session (the only BGP session configured on the router). If there's room in the transfer net for the server and the router, the setup is simple (eBGP session is established with the server and next-hop is set to the router). In other peering situations the setup might be more challenging. E.g. with typical IXP constrains (only a single MAC address/IP address allowed) the session would have to be a multihop session and an additional static route (host route for the server) on the peer router should be installed. Another way to make the server appear completely transparent for other peers (no special configuration on the peer side) might be NAT for the BGP port to the server or proxy ARP. But we would like to avoid doing NAT with a SUP720 and proxy ARP would make us the default gateway for any incorrectly configured IXP participant router and a configuration error on our side might cause severe harm to the IXP. And of course both ideas won't work for IPv6 (SUP720 doesn't support NAT for IPv6 or proxy NDP). The only solution to make it fully transparent for IPv4 and IPv6 we came up with it is to configure the IXP router interface as unnumbered + static route for the IXP nets + host routes for the assigned IXP IPs to the server. In that case the server would have to monitor the IXP vlan and take care of responding to ARP and Neighbor Solicitation requests for the IXP IPs (using the MAC of the router). Additionally it might be necessary to inject the ARP/IPv6 neighbors into the cisco using static entries (to avoid sending ARP/NS requests with a non IXP IP). We're wondering if anyone has experience with such a setup? Best Regards, Freddy
Re: Usage data from Turkey
I'm not an expert on Turkey, but NetIX has a PoP in Istanbul. http://netix.net/map * On Wed, 01 Apr 2015 13:34:15 +0300 * Max Tulyev max...@netassist.ua wrote: Hello, may be a bit off-topic, but which major Internet Exchange points are in Tukrey? I can't google it. On 03/31/15 20:19, Mehmet Akcin wrote: Hello Today March 31 , 2015 GMT +0200 1030am-4pm Turkey has suffered a major power outage impacting nearly 70M people. I am writing a blog post about power outage vs impact to network usage. I am looking for as much as useful network usage information possible related to Turkey. If you can share network usage information, i will be making sure to buy you some drinks at next nanog ;) Cheers Mehmet
Re: How are you doing DHCPv6 ?
[ 3 year old thread ]
So back in 2012 there was some discussion on DHCPv6 and the challenge of
using a DUID in a dual-stack environment where MAC-based assignments are
already happening though an IPAM.
Update on this since then:
*RFC 6939 - Client Link-Layer Address Option in DHCPv6*
Pretty much exactly what I described in 2012 in terms of leveraging RFC
6422 to do this. Thank you, Halwasia, Bhandari, and Dec @ Cisco :-)
I'd like to think my email back in 2012 influenced this, but I'm sure it
didn't. ;-)
*Support in ISC DHCP 4.3.1+*
https://deepthought.isc.org/article/AA-01112/0/Newly-Pre-defined-Options-in-DHCP-4.3.html
Example to add logging for this in dhcpd.conf:
log (info, concat (Lease for , binary-to-ascii(16,16, :,
substring(suffix(option dhcp6.ia-na, 24),0,16)), client-linklayer-addr
,v6relay(1, (binary-to-ascii(16, 8, :, option
dhcp6.client-linklayer-addr);
To create static bindings based on it:
host hostname-1 {
host-identifier v6relopt 1 dhcp6.client-linklayer-addr
0:1:32:8b:36:ba:ed:ab;
fixed-address6 2001:db8:100::123;
};
[ These examples taken from Enno Rey, link follows ]
http://www.insinuator.net/2015/02/is-rfc-6939-support-finally-here-checking-the-implementation-of-the-client-link-layer-address-option-in-dhcpv6/
*Cisco Support?*
Apparently Cisco has started to support this in IOS-XE by default. I
haven't had a chance to verify this yet, but I did check IOS XR and IOS and
still don't see support for it.
Does anyone have details on what platforms and releases from Cisco support
RFC 6939 Option 79 so far? The only thing I can find online is reference
to the Cisco uBR7200 release 12.2(33)SCI, which doesn't really help me.
On Mon, Jan 23, 2012 at 5:23 PM, Ray Soucy r...@maine.edu wrote:
The requirement of the DUID is a big hurdle to DHCPv6 adoption, I agree.
Currently, a DUID can be generated in 1 of 3 ways, 2 of which include
_any_ MAC address of the system at the time of generation. After
that, the DUID is stored in software.
The idea is that the DUID identifies the system and the IAID
identifies the interface, and that over time, the system will keep its
DUID even if the network adapter changes.
This is obviously different from how we use DHCP for legacy IP.
There are a few problems as a result:
1. Systems that are built using disk images can all have the same DUID
unless the admin takes care to remove any generated DUID on the image
(already see this on Windows 7 and even Linux).
2. Networks where the MAC addresses for systems are already known
can't simply build a DHCPv6 configuration based on those MACs.
If someone were to modify DHCPv6 to address these concerns, I think
the easiest way to do so would be to extend DHCPv6 relay messages to
include the MAC address of the system making the request (DHCPv6
servers on local sub-networks would be able to determine the MAC from
the packet). This would allow transitional DHCPv6 configurations to
be built on MAC addresses rather than DUID without client modification
(which is key).
Perhaps this is already possible through the use of RFC 6422 (which
shouldn't break anything).
I think more important, though, is a good DHCPv6 server implementation
with verbose logging capabilities, and the ability to specify a DUID,
DUID+IAID, or MAC for static assignments.
I know there are people from ISC on-list. It would be great to hear
someone who works on DHCPd chime in.
How about we start with modifying ISC DHCPd for IPv6 to have proper
logging and support for configuring IAID, then work on the MAC
awareness piece. ISC DHCPd makes use of RAW sockets, so it should
always have the MAC for a non-relayed request. Then we just need to
work with router vendors on adding MACs as a relay option.
--
Ray Soucy
Epic Communications Specialist
Phone: +1 (207) 561-3526
Networkmaine, a Unit of the University of Maine System
http://www.networkmaine.net/
--
Ray Patrick Soucy
Network Engineer
University of Maine System
T: 207-561-3526
F: 207-561-3531
MaineREN, Maine's Research and Education Network
www.maineren.net
Re: Usage data from Turkey
I left the industry for a few years so I may be off, but I doubt they have any. It wasn't a deregulated market when I left telecom in 2011. Regards, Roderick. Roderick Beck Sales Director/Europe and the Americas Hibernia Networks http://www.hibernianetworks.com Budapest and New York 36-30-859-5144 rod.b...@hibernianetworks.com _ This e-mail and any attachments thereto is intended only for use by the addressee(s) named herein and may be proprietary and/or legally privileged. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this email, and any attachments thereto, without the prior written permission of the sender is strictly prohibited. If you receive this e-mail in error, please immediately telephone or e-mail the sender and permanently delete the original copy and any copy of this e-mail, and any printout thereof. All documents, contracts or agreements referred or attached to this e-mail are SUBJECT TO CONTRACT. The contents of an attachment to this e-mail may contain software viruses that could damage your own computer system. While Hibernia Networks has taken every reasonable precaution to minimize this risk, we cannot accept liability for any damage that you sustain as a result of software viruses. You should carry out your own virus checks before opening any attachment.
RE: RFC 7511 - Scenic Routing for IPv6
My packets prefer owls. -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Thomas Maufer Sent: Wednesday, April 01, 2015 7:15 PM To: Jeff Walter; valdis.kletni...@vt.edu Cc: NANOG Subject: Re: RFC 7511 - Scenic Routing for IPv6 All my packets use recycled electrons. And recycled photons. Conservation of Energy isn't just a green idea...it's the LAW. On Wed, Apr 1, 2015 at 4:02 PM Jeff Walter jwal...@weebly.com wrote: I only buy free-ranged packets and you should too. On Wed, Apr 1, 2015 at 3:28 PM, valdis.kletni...@vt.edu wrote: On Wed, 01 Apr 2015 17:18:42 -0400, Sadiq Saif said: Informational of course. :) https://tools.ietf.org/html/rfc7511 It already has an errata filed. Follow the link. :)
Re: BGP offloading (fixing legacy router BGP scalability issues)
On Wednesday, April 1, 2015, Frederik Kriewitz frede...@kriewitz.eu wrote: Hello, We've a lot of customers with Cisco 6500 routers (mostly with SUP720 supervisors) in operation. They are very popular with smaller ISPs in Africa/middle east due to their cheap price on the used marked and their fully sufficient routing performance for the given tasks. In practice the biggest problem with them is their poor BGP scalability due to the CPU/memory limitations. We're looking into options for a cheap fix for this problem. The idea is to offload BGP IPv4/IPv6 RIB calculation from the router to a standard server. All BGP sessions will be handled by the server. The server takes care of the RIB calculation and aggregates the result as much as possible (the aggregation potential of the global tables should be very high if it can completely ignore the AS path and only care about the next hop). The final optimized RIB is then pushed to the Router via an iBGP session (the only BGP session configured on the router). If there's room in the transfer net for the server and the router, the setup is simple (eBGP session is established with the server and next-hop is set to the router). In other peering situations the setup might be more challenging. E.g. with typical IXP constrains (only a single MAC address/IP address allowed) the session would have to be a multihop session and an additional static route (host route for the server) on the peer router should be installed. Another way to make the server appear completely transparent for other peers (no special configuration on the peer side) might be NAT for the BGP port to the server or proxy ARP. But we would like to avoid doing NAT with a SUP720 and proxy ARP would make us the default gateway for any incorrectly configured IXP participant router and a configuration error on our side might cause severe harm to the IXP. And of course both ideas won't work for IPv6 (SUP720 doesn't support NAT for IPv6 or proxy NDP). The only solution to make it fully transparent for IPv4 and IPv6 we came up with it is to configure the IXP router interface as unnumbered + static route for the IXP nets + host routes for the assigned IXP IPs to the server. In that case the server would have to monitor the IXP vlan and take care of responding to ARP and Neighbor Solicitation requests for the IXP IPs (using the MAC of the router). Additionally it might be necessary to inject the ARP/IPv6 neighbors into the cisco using static entries (to avoid sending ARP/NS requests with a non IXP IP). We're wondering if anyone has experience with such a setup? Best Regards, Freddy Do these use cases really require a full table? Could you get-by with a simple filter Less than or equal to /22 ? Especially applying such a filter to non-local / inter-continental routes? I have done similar for a long time on 7600s, works fine for me (with a default from my upstream) CB
PoC for shortlisted DDoS Vendors
In our effort to pick up a reasonably priced DDoS appliance with a competitive features, we're in a process of doing a PoC for the following shortlisted vendors: 1- RioRey 2- NSFocus 3- Arbor 4- A10 The setup will be inline. So it would be great if anyone have done this before and can help provide the appropriate tools, advices, or the testing documents for efficient PoC. Thanks. -- Mohamed Kamal Core Network Sr. Engineer
Re: From Europe to Australia via right way
On 4/1/15 3:14 AM, Piotr wrote: Hello, There is some telecom, isp which have route from EU to AU via east or south east (via Russia, Red sea or other ways) ? Now i have path via US and looking something in opposite direction. telstra ntt reliance retn all have eastbound paths from europe. thanks for some info, contact. Piotr signature.asc Description: OpenPGP digital signature
Re: PoC for shortlisted DDoS Vendors
Why aren't you also looking at Hauwei? On Apr 01, 2015, at 09:53 AM, Mohamed Kamal mka...@noor.net wrote: In our effort to pick up a reasonably priced DDoS appliance with a competitive features, we're in a process of doing a PoC for the following shortlisted vendors: 1- RioRey 2- NSFocus 3- Arbor 4- A10 The setup will be inline. So it would be great if anyone have done this before and can help provide the appropriate tools, advices, or the testing documents for efficient PoC. Thanks. -- Mohamed Kamal Core Network Sr. Engineer
RFC 7511 - Scenic Routing for IPv6
Informational of course. :) https://tools.ietf.org/html/rfc7511 -- Sadiq Saif https://staticsafe.ca
Re: RFC 7511 - Scenic Routing for IPv6
On Wed, 01 Apr 2015 17:18:42 -0400, Sadiq Saif said: Informational of course. :) https://tools.ietf.org/html/rfc7511 It already has an errata filed. Follow the link. :) pgpJQL1kWv8fH.pgp Description: PGP signature
Re: RFC 7511 - Scenic Routing for IPv6
I only buy free-ranged packets and you should too. On Wed, Apr 1, 2015 at 3:28 PM, valdis.kletni...@vt.edu wrote: On Wed, 01 Apr 2015 17:18:42 -0400, Sadiq Saif said: Informational of course. :) https://tools.ietf.org/html/rfc7511 It already has an errata filed. Follow the link. :)
