- Test - lists.nanog.org

Juniper MX expert?
by Randy Carpenter 25 Apr '12

25 Apr '12

Any Juniper MX experts out there want to do some quick consulting for me (not for free)? I am working on implementing a couple of MX5 routers in a service provider setting, and have run into some issues. I am pretty proficient at the SRX and EX lines, but not as much with the MX. As the particulars of the issues go a little deeper than I feel comfortable asking for free help for, I will leave out the details on the list. Please contact me off list if you are willing and able to give me a hand. thanks, -Randy

1 1

10GBASE-LR SFP+ in Reston, VA
by Brandon Ewing 24 Apr '12

24 Apr '12

Greetings, Anyone know how I can get my hands on a SFP-10G-LR in the Reston area, tonight? -- Brandon Ewing (nicotine(a)warningg.com)

2 1

IPv6 dark traffic collection restarted
by Geoff Huston 24 Apr '12

24 Apr '12

Hi, In 2010, and again in 2011, I ran an experiment to examine the "dark" traffic in IPv6. I did this by announcing the "superblock" 2400::/12 which has been allocated to APNIC for its IPv6 allocations. The superblock announcement is an aggregate and will not disrupt any IPv6 traffic - the packets that will head to this dark traffic collector were on their way to /dev/null in any case. We are about to run this experiment up again to collect a 2012 data profile for IPv6 dark traffic in 2012. Accordingly, 2400::/12 will be announced by AS3562 - please don't filter it! IPv6 packets are scarce enough already! :-) This time around we are being assisted by Sandia National Laboratories and ESnet, for which APNIC would like to acknowledge their assistance in this ongoing research activity. Some URLs: - ESnet news item is at: http://www.es.net/services/ipv6-network/esnet-supports-sandia-and-apnic-ipv… - LOA for the announcement: http://www.sandia.gov/apnic/authorization.pdf - Previous re[port: http://www.potaroo.net/ispcol/2010-07/dark6.pdf thanks, Geoff

2 1

Partial Outage with TW Telecom and CenturyLink
by Eric C. Miller 24 Apr '12

24 Apr '12

Morning Everyone, Yesterday between about 1900 and 2230 UTC, we had a partial drop with reaching various sites through TW Telecom from our circuit in Orlando, FL. The unavailable sites included Facebook, Newegg, and Godaddy. The outage did not affect our Atlanta TW Telecom. I confered with a colleague who manages a large customer in Apopka who said that they appeared not to be affected. His circuit and ours loop to the same TW Telecom POP. But even more Murphy than that, our Centurylink secondary circuit was having a routing loop issue at the same time, so while our BGP routes were being advertised to world through Centurylink, the circuit was useless. Centurylink aknowledged the existence of a bigger transport issue and said that we weren't the only customer affected. Anybody else notice these issues or have any other insight? Thanks! Eric Miller

6 7

Fwd: Host scanning in IPv6 Networks
by Fernando Gont 24 Apr '12

24 Apr '12

FYI -------- Original Message -------- Subject: IPv6 host scanning in IPv6 Date: Fri, 20 Apr 2012 03:57:48 -0300 From: Fernando Gont <fgont(a)si6networks.com> Organization: SI6 Networks To: IPv6 Hackers Mailing List <ipv6hackers(a)lists.si6networks.com> Folks, We've just published an IETF internet-draft about IPv6 host scanning attacks. The aforementioned document is available at: <http://www.ietf.org/id/draft-gont-opsec-ipv6-host-scanning-00.txt> The Abstract of the document is: ---- cut here ---- IPv6 offers a much larger address space than that of its IPv4 counterpart. The standard /64 IPv6 subnets can (in theory) accommodate approximately 1.844 * 10^19 hosts, thus resulting in a much lower host density (#hosts/#addresses) than their IPv4 counterparts. As a result, it is widely assumed that it would take a tremendous effort to perform host scanning attacks against IPv6 networks, and therefore IPv6 host scanning attacks have long been considered unfeasible. This document analyzes the IPv6 address configuration policies implemented in most popular IPv6 stacks, and identifies a number of patterns in the resulting addresses lead to a tremendous reduction in the host address search space, thus dismantling the myth that IPv6 host scanning attacks are unfeasible. ---- cut here ---- Any comments will be very welcome (note: this is a drafty initial version, with lots of stuff still to be added... but hopefully a good starting point, and a nice reading ;-) ). Thanks! Best regards,

6 7

risk bearing/calculation for security service provider
by Ganbold Tsagaankhuu 24 Apr '12

24 Apr '12

Hi, I have some questions related to the security service that security SP offers. Is it common for SP to include risk related calculation into the security service (in contract/SLA) they offer? The question or problem might arise when some incident happened even the customer got secure hosting service from security SP. The customer might complain that SP doesn't protect them well and ask for some penalty in this case. So how does SP protect themselves in this case? Is there any best practice for that? thanks a lot, Ganbold

1 0

Automatic IPv6 due to broadcast
by Anurag Bhatia 23 Apr '12

23 Apr '12

Hello everyone Just got a awfully crazy issue. I heard from our support team about failure of whois during domain registration. Initially I thought of port 43 TCP block or something but found it was all ok. Later when ran whois manually on server via terminal it failed. Found problem that server was connecting to whois server - whois.verisign-grs.com. I was stunned! Server got IPv6 and not just that one - almost all. This was scary - partial IPv6 setup and it was breaking things. In routing tables, routes were all going to a router which I recently setup for testing. That router and other servers are under same switch but by no means I ever configured that router as default gateway for IPv6. I found option of "broadcast" was enabled on router for local fe80... address and I guess router broadcasted IPv6 and somehow (??) all servers found that they have a IPv6 router on LAN and started using it - automated DHCP IPv6? I wonder if anyone else also had similar issues? Also, if my guesses are correct then how can we disable Red Hat distro oriented servers from taking such automated configuration - simple DHCP in IPv6 disable? Thanks -- Anurag Bhatia anuragbhatia.com or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected network! Twitter: @anurag_bhatia <https://twitter.com/#!/anurag_bhatia> Linkedin: http://linkedin.anuragbhatia.com

17 24

Securing OOB
by Eric 23 Apr '12

23 Apr '12

Hello, It seems that the current practice is to use a DSL line, as opposed to a modem, for accessing an OOB a console server at a remote colo. From a security standpoint, what do people generally do - trust the console server, repurpose an old linksys box from my house or put in a full firewall? Eric :)

6 5

About Juniper MX10 router performance
by Md.Jahangir Hossain 23 Apr '12

23 Apr '12

Dear valued member: Wishes all are fine. i need suggestion from you about Juniper MX10 router performance. i want to buy this router for IP Transit provider where i received all global routes . it would be nice please put your valued suggestion about this issue. -- Thanks ---------- Jahangir* *

2 4

Assymetric routing L3/VZ (FIOS)
by Deepak Jain 22 Apr '12

22 Apr '12

Is anyone else seeing this? DC - DFW back to DC? AFAIK, Verizon-GNI is a customer of L3, so no weird peering issues should be afoot. This adds about 40ms to the R/T time. The path leaving Verizon-GNI (FIOS) goes (seemingly) DC-DC and has lower times (<5ms) unidirectionally. Tracing the route to pool-173-79-242-218.washdc.fios.verizon.net (173.79.242.218 ) [...] 3 ge-6-16.car1.Baltimore1.Level3.net (4.59.244.85) [AS 65518] 4 msec 0 msec 4 msec 4 ae-11-11.car2.Baltimore1.Level3.net (4.69.134.110) [AS 65518] 0 msec 4 msec 0 msec 5 ae-8-8.ebr2.Washington1.Level3.net (4.69.134.105) [AS 65518] 4 msec 4 msec 4 msec 6 ae-72-72.csw2.Washington1.Level3.net (4.69.134.150) [AS 65518] 4 msec ae-82-82.csw3.Washington1.Level3.net (4.69.134.154) [AS 65518] 8 msec 8 msec 7 ae-61-61.ebr1.Washington1.Level3.net (4.69.134.129) [AS 65518] 4 msec ae-91-91.ebr1.Washington1.Level3.net (4.69.134.141) [AS 65518] 4 msec ae-71-71.ebr1.Washington1.Level3.net (4.69.134.133) [AS 65518] 4 msec 8 ae-2-2.ebr3.Atlanta2.Level3.net (4.69.132.85) [AS 65518] 16 msec 16 msec 16 msec 9 ae-7-7.ebr3.Dallas1.Level3.net (4.69.134.21) [AS 65518] 36 msec 36 msec 36 m sec 10 ae-73-73.csw2.Dallas1.Level3.net (4.69.151.145) [AS 65518] 40 msec ae-63-63.csw1.Dallas1.Level3.net (4.69.151.133) [AS 65518] 40 msec 40 msec 11 ae-4-90.edge2.Dallas3.Level3.net (4.69.145.204) [AS 65518] 44 msec ae-3-80.edge2.Dallas3.Level3.net (4.69.145.140) [AS 65518] 36 msec ae-1-60.edge2.Dallas3.Level3.net (4.69.145.12) [AS 65518] 36 msec 12 MCI-level3-ae.dallas3.level3.net (4.68.62.34) [AS 65518] 36 msec mci-level3-30g.dallas3.level3.net (4.68.62.166) [AS 65518] 36 msec MCI-level3-ae.dallas3.level3.net (4.68.62.34) [AS 65518] 36 msec 13 0.ge-0-0-0.DFW01-BB-RTR1.verizon-gni.net (152.63.2.146) [AS 65518] 36 msec 3 6 msec 0.ae2.DFW01-BB-RTR2.verizon-gni.net (152.63.2.229) [AS 65518] 36 msec 14 * * * We're opening a ticket with them, but figured NANOG is an often better place for these resolutions. Thanks in advance, Deepak Jain AiNET Home of CyberNAP www.ai.net

4 3