- NANOG - lists.nanog.org

AT&T blocking our IPs - need assistance
by Blocked IPs 01 Mar '16

01 Mar '16

The ISP I work for has a large block of IPs (randomly distributed) being blocked by AT&T so that mutual customers cannot log into online portals like att.net and directv.com. The common nodes of failure are cprodmasx.att.net and cprodx.att.com. We have had no luck getting through to higher tiers from customer-facing phone representatives, nor have we had a response when leaving a voicemail at 314-235-8168 (generic WHOIS registrant phone number, but recording mentions "domain administrator"; please check your voicemail and response; we just left another). Please have an AT&T server administrator reply off-list in regards to fixing this. Thank you

1 0

MetroE and Telephone Taxes
by Sam Norris 01 Mar '16

01 Mar '16

Hey all, My provider here in SoCal is charging me 8% or so telephone taxes on our MetroE products. This seems fishy to me and I can't find any cut and dry rules about private Ethernet / MetroE being under these rules. The same provider selling internet / DIA has no taxes whatsoever. Anyone out there getting charged ULS and other telephone taxes on MetroE circuits? Or can anyone point me to somewhere that shows that it shouldn't be charged telephone taxes? Assume there are no voip calls traversing these circuits. I believe ULS is Federal, the other 3-5% is CA taxes on CLECs. Thx, Sam

2 1

google search threshold
by Philip Lavine 29 Feb '16

29 Feb '16

Does anybody know what the threshold for google searches is before you get the captcha?I am trying to decide if I need to break up the overload NAT to a pool. -thx

6 6

Duplex negotiation over 100Base fibre
by Jason Lixfeld 29 Feb '16

29 Feb '16

Hello, My understanding is that for 1G and 10G optical networks, there is no concept of half-duplex mode, but I’m unclear about half duplex in the 100M optical world. Specifically, if I connect two 100Base-LX (or BX) transceivers together, is there a requirement for the controller(s on either side) to select between full or half duplex, either by static configuration, or auto-negotiation? Thanks!

3 2

2nd call for presentations RIPE 72
by Benno Overeinder 29 Feb '16

29 Feb '16

Dear colleagues, Please note the approaching deadline of 13 March 2016 for RIPE 72 plenary programme submissions. You can find the CFP for RIPE 72 below or at https://ripe72.ripe.net/submit-topic/cfp/, for your proposals for plenary session presentations, tutorials, workshops, BoFs (Birds of a Feather sessions) and lightning talks. Please also note that speakers do not receive any extra reduction or funding towards the meeting fee at the RIPE Meetings. Kind regards, Benno Overeinder RIPE PC Chair https://www.ripe.net/participate/meetings/ripe-meetings/pc -------------------->>><<<-------------------- Call for Presentations A RIPE Meeting is an open event where Internet Service Providers, network operators and other interested parties get together. Although the meeting is mostly technical, it is also a chance for people to meet and network with others in their field. RIPE 72 will take place from 23-27 May 2016 in Copenhagen, Denmark. The RIPE Programme Committee (PC) is now seeking content proposals from the RIPE community for the plenary sessions, BoFs (Birds of a Feather sessions), panels, workshops, tutorials and lightning talks at RIPE 72. See the full descriptions of the different presentation formats, https://ripe72.ripe.net/submit-topic/presentation-formats/. Proposals for plenary sessions, BoFs, panels, workshops and tutorials must be submitted for full consideration no later than 13 March 2016. Proposals submitted after this date will be considered depending on the remaining available space in the programme. The PC is looking for presentations covering topics of network engineering and operations, including but not limited to: - IPv6 deployment - Managing IPv4 scarcity in operations - Commercial transactions of IPv4 addresses - Data centre technologies - Network and DNS operations - Internet governance and regulatory practices - Network and routing security - Content delivery - Internet peering and mobile data exchange Submissions RIPE Meeting attendees are quite sensitive to keeping presentations non-commercial, and product marketing talks are strongly discouraged. Repeated audience feedback shows that the most successful talks focus on operational experience, research results, or case studies. For example, presenters wishing to describe a commercial solution should focus on the underlying technology and not attempt a product demonstration. Presenters should indicate how much time they will require. In general, the time allocated for the different presentation formats is as follows: - Plenary presentations: 20-25 minutes presentation with 5-10 minutes discussion - Tutorials: up to two hours (Monday morning) - Workshops: one hour (during evening sessions) to two hours (Monday morning) - BoFs: approximately one hour - Lightning talks: 10 minutes The following general requirements apply: - Proposals must be submitted using the meeting submission system, https://ripe72.ripe.net/submit-topic/submission-form/. - Lightning talks should also be submitted using the meeting submission system (https://ripe72.ripe.net/submit-topic/submission-form/) and can be submitted any time up to and including the meeting week. The allocation of lightning talks will be announced on short notice---in some cases on the same day but often one day prior to the time slot allocated. - Presenters who propose a panel or BoF are encouraged to include speakers from several (perhaps even competing) companies and/or a neutral facilitator. - All presentation proposals will only be considered by the PC if they contain at least draft presentation slides (slides may be updated later on). For panels, proposals must contain a clear description, as well as the names of invited panellists, presenters and moderators. - Due to potential technical issues, presenters/panellists should be physically present at the RIPE Meeting. If you have any questions or requests concerning content submissions, please email pc [at] ripe [dot] net. -- Benno J. Overeinder NLnet Labs http://www.nlnetlabs.nl/

1 0

Observium
by sathish kumar Ippani 29 Feb '16

29 Feb '16

Hello Everyone, This is off topic, i am posting request as i need some help in configuring obsrvium for RANCID and traffic polling. for traffic polling I am seeing white space in the graph as shown in the below. [image: Inline image 1] Rancid. Device back up are fine for few devices (daily) for few devices backup were not happening. Rancid cronjob ============================ 58 11 * * * /var/lib/rancid/bin/rancid-run #hourly router dump 59 11 * * * /usr/bin/find /var/lib/rancid/logs -type f -mtime +2 -exec rm {} \; poller cronjob ================== */5 * * * * root /opt/observium/poller-wrapper.py 10 >> /dev/null 2>&1 -- With Regards, Sathish Kumar Ippani 9177166040

2 1

Media converter vendors - GFP/EoSDH
by Ramy Hashish 29 Feb '16

29 Feb '16

Hello there, Any recommendations for Ethernet-SDH/SONET media converter vendors? Thanks, Ramy

4 5

Re: Media converter vendors - GFP/EoSDH
by Clayton Zekelman 29 Feb '16

29 Feb '16

What speeds SONET are you looking to map your Ethernet on to? RAD makes some products. http://www.rad.com/10/Ethernet-over-SDH-SONET-ADM/2833/ We use BIT Systems 2.5G Muxponders to map 2xGE to OC48. Works well. http://www.btisystems.com/Portals/0/Documents/Data-Sheets/Muxponder-Family-… We also have some ADTRAN Opti-6100 units using Ethernet mappers. At 08:10 AM 28/02/2016, Ramy Hashish wrote: >Hello there, > >Any recommendations for Ethernet-SDH/SONET media converter vendors? > >Thanks, > >Ramy -- Clayton Zekelman Managed Network Systems Inc. (MNSi) 3363 Tecumseh Rd. E Windsor, Ontario N8W 1H4 tel. 519-985-8410 fax. 519-985-8409

2 1

RE: Packet loss on XO's network
by Frank Bulk 28 Feb '16

28 Feb '16

Terri, Except the initial traces show that hop 6 is clean. If the problem really started at hop 4 then the issue would likely show up in hop 6 (unless there was a hashing on the return path based on the far end router's source IP that caused just some traffic to be thrown away). Hop 4 and 5 always have packet loss - I believe it's due to ICMPv6 rate limiters protecting their CPU: Frank From: Fullenkamp, Terri L [mailto:terri.l.fullenkamp@xo.com] Sent: Sunday, February 28, 2016 2:59 PM To: Frank Bulk <frnkblk(a)iname.com>; nanog(a)nanog.org Cc: # SUP - NCC Level 1 Data <NCCLevel1Data(a)xo.com> Subject: RE: Packet loss on XO's network >From the traces provided the packet loss starts accruing at hop 4 and 5 and that is before it gets into the XO network, If you are a customer of XO please contact care @ 888-575-6398 with any other questions Trace from hop 6 tfullenk(a)MCR2.Minneapolis-MN <mailto:tfullenk@MCR2.Minneapolis-MN> > traceroute enterprise.com traceroute6 to enterprise.com (2620:103:e049:31a7::b4) from 2610:18::30bc, 64 hops max, 12 byte packets 1 mcr1.minneapolis-mn.us.xo.net (2610:18::30b8) 29.325 ms 28.950 ms 31.327 ms MPLS Label=318081 CoS=0 TTL=1 S=0 MPLS Label=2 CoS=0 TTL=1 S=1 2 2610:18::5802 (2610:18::5802) 32.680 ms 29.684 ms 32.643 ms MPLS Label=19268 CoS=0 TTL=255 S=0 MPLS Label=2 CoS=0 TTL=255 S=1 3 2610:18::5804 (2610:18::5804) 30.629 ms 33.384 ms 81.985 ms MPLS Label=757571 CoS=0 TTL=1 S=0 MPLS Label=2 CoS=0 TTL=3 S=1 4 2610:18::5803 (2610:18::5803) 65.305 ms 28.876 ms 39.141 ms MPLS Label=419427 CoS=0 TTL=1 S=0 MPLS Label=2 CoS=0 TTL=4 S=1 5 2610:18::5201 (2610:18::5201) 36.762 ms 28.776 ms 28.718 ms MPLS Label=694064 CoS=0 TTL=1 S=0 MPLS Label=2 CoS=0 TTL=5 S=1 6 2610:18::2070 (2610:18::2070) 29.487 ms 28.920 ms 42.500 ms 7 2610:18:16::32 (2610:18:16::32) 28.619 ms 2600:803:2::9 (2600:803:2::9) 28.706 ms 28.692 ms 8 2600:807:21f::22 (2600:807:21f::22) 47.997 ms 48.042 ms 50.504 ms 9 2600:807:21f::22 (2600:807:21f::22) 48.026 ms 48.084 ms 49.172 ms Terri Fullenkamp NCC Specialist V / IP Data / <http://www.xo.com/> XO Communications / 2020 Westport Center Drive, Maryland Heights, MO 63146 T: 866-966-8975 F: 314-787- 7799 E: terri.l.fullenkamp(a)xo.com <mailto:terri.l.fullenkamp@xo.com> From: Frank Bulk [mailto:frnkblk@iname.com] Sent: Sunday, February 28, 2016 12:25 To: nanog(a)nanog.org <mailto:nanog@nanog.org> Subject: Packet loss on XO's network Since ~11:08 am Central our monitoring system has been reporting intermittent HTTPv6 timeouts to www.sprint.net <http://www.sprint.net> , www.qwest.com <http://www.qwest.com> , enterprise.com, and enterprise.ca. It goes bad for a while and then clears. Using mtr, these all have XO's network in common, and the packet loss to the endpoint sustains over 40%. Seems to be between 2610:18:18b:c000::11 and mcr1.minneapolis-mn.us.xo.net [2610:18::30b8] Frank To enterprise.com: Host Loss% Snt Last Avg Best Wrst StDev 1. router-core.mtcnet.net 0.0% 929 0.3 0.6 0.2 37.6 2.5 2. sxct.sxcy.mtcnet.net 0.0% 929 0.3 0.3 0.2 11.2 0.6 3. v6-premier.sxcy-mlx.fbnt.netins.net 0.0% 929 1.6 1.5 1.5 12.6 0.9 4. v6-ins-db4-te-0-6-0-4-219.desm.netins.net 52.4% 929 8.1 8.0 7.8 10.5 0.3 5. v6-ins-dc1-te-7-4.desm.netins.net 52.4% 929 7.9 8.0 7.6 10.9 0.5 6. 2610:18:18b:c000::11 0.0% 929 13.9 13.2 12.8 46.8 3.0 7. mcr1.minneapolis-mn.us.xo.net 50.3% 929 54.7 71.2 54.6 86.7 7.7 8. 2610:18::5802 50.8% 929 55.7 72.8 54.6 84.3 7.8 9. 2610:18::5202 51.4% 929 54.4 72.9 54.4 85.0 8.0 2610:18::5804 10. 2610:18::2070 52.3% 928 54.4 71.5 54.4 90.7 7.9 2610:18::5304 11. 2600:803:2::9 41.6% 928 54.5 56.8 47.8 96.7 3.4 2610:18::5303 12. 2610:18::5200 96.0% 928 54.5 55.8 54.4 75.6 3.7 13. 2610:18::5202 96.0% 928 55.5 56.6 54.6 58.5 1.2 14. 2610:18::2070 96.0% 928 61.8 55.1 54.6 61.8 1.2 15. 2600:803:2::9 95.9% 928 45.0 45.1 45.0 48.0 0.5 16. ??? To www.sprint.net <http://www.sprint.net> : Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. router-core.mtcnet.net 0.0% 846 0.4 0.8 0.2 91.5 3.9 2. sxct.sxcy.mtcnet.net 0.0% 846 0.9 0.3 0.2 10.3 0.4 3. v6-premier.sxcy-mlx.fbnt.netins.net 0.0% 846 1.5 1.6 1.5 12.0 0.8 4. v6-ins-db4-te-0-6-0-4-219.desm.netins.net 55.4% 846 7.9 8.1 7.8 14.8 0.4 5. v6-ins-dc1-te-7-4.desm.netins.net 54.3% 846 7.8 8.2 7.6 19.2 1.0 6. 2610:18:18b:c000::11 0.0% 846 12.9 14.0 12.8 73.0 5.4 7. mcr1.minneapolis-mn.us.xo.net 49.8% 846 54.7 70.0 54.6 100.1 8.1 8. 2610:18::5802 47.4% 846 58.3 71.9 54.6 82.9 8.2 9. 2610:18::5202 45.0% 846 54.4 72.1 54.4 83.3 8.4 2610:18::5804 10. 2610:18::2070 50.6% 845 54.4 70.4 54.3 88.8 8.1 2610:18::5304 11. sl-st31-ash-te0-15-2-0.v6.sprintlink.net 43.4% 845 57.5 59.1 53.1 80.5 2.3 2610:18::5303 12. sl-crs3-dc-be13.v6.sprintlink.net 46.7% 845 54.6 64.7 54.4 69.1 3.7 2610:18::5200 13. sl-crs1-ffx-be2.v6.sprintlink.net 44.1% 844 55.0 71.8 55.0 79.7 5.3 2610:18::5202 14. sl-crs1-orl-bu-1.v6.sprintlink.net 41.7% 844 54.9 75.7 54.7 96.3 7.4 2610:18::2070 15. sl-lkdstr2-p1-0.v6.sprintlink.net 41.0% 844 46.4 73.5 45.8 81.7 7.0 sl-st31-ash-te0-15-2-0.v6.sprintlink.net 16. www.sprint.net <http://www.sprint.net> 43.1% 844 54.5 74.6 53.5 81.6 5.0 sl-crs3-dc-be13.v6.sprintlink.net

1 0

Packet loss on XO's network
by Frank Bulk 28 Feb '16

28 Feb '16

Since ~11:08 am Central our monitoring system has been reporting intermittent HTTPv6 timeouts to www.sprint.net, www.qwest.com <http://www.qwest.com> , enterprise.com, and enterprise.ca. It goes bad for a while and then clears. Using mtr, these all have XO's network in common, and the packet loss to the endpoint sustains over 40%. Seems to be between 2610:18:18b:c000::11 and mcr1.minneapolis-mn.us.xo.net [2610:18::30b8] Frank To enterprise.com: Host Loss% Snt Last Avg Best Wrst StDev 1. router-core.mtcnet.net 0.0% 929 0.3 0.6 0.2 37.6 2.5 2. sxct.sxcy.mtcnet.net 0.0% 929 0.3 0.3 0.2 11.2 0.6 3. v6-premier.sxcy-mlx.fbnt.netins.net 0.0% 929 1.6 1.5 1.5 12.6 0.9 4. v6-ins-db4-te-0-6-0-4-219.desm.netins.net 52.4% 929 8.1 8.0 7.8 10.5 0.3 5. v6-ins-dc1-te-7-4.desm.netins.net 52.4% 929 7.9 8.0 7.6 10.9 0.5 6. 2610:18:18b:c000::11 0.0% 929 13.9 13.2 12.8 46.8 3.0 7. mcr1.minneapolis-mn.us.xo.net 50.3% 929 54.7 71.2 54.6 86.7 7.7 8. 2610:18::5802 50.8% 929 55.7 72.8 54.6 84.3 7.8 9. 2610:18::5202 51.4% 929 54.4 72.9 54.4 85.0 8.0 2610:18::5804 10. 2610:18::2070 52.3% 928 54.4 71.5 54.4 90.7 7.9 2610:18::5304 11. 2600:803:2::9 41.6% 928 54.5 56.8 47.8 96.7 3.4 2610:18::5303 12. 2610:18::5200 96.0% 928 54.5 55.8 54.4 75.6 3.7 13. 2610:18::5202 96.0% 928 55.5 56.6 54.6 58.5 1.2 14. 2610:18::2070 96.0% 928 61.8 55.1 54.6 61.8 1.2 15. 2600:803:2::9 95.9% 928 45.0 45.1 45.0 48.0 0.5 16. ??? To www.sprint.net: Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. router-core.mtcnet.net 0.0% 846 0.4 0.8 0.2 91.5 3.9 2. sxct.sxcy.mtcnet.net 0.0% 846 0.9 0.3 0.2 10.3 0.4 3. v6-premier.sxcy-mlx.fbnt.netins.net 0.0% 846 1.5 1.6 1.5 12.0 0.8 4. v6-ins-db4-te-0-6-0-4-219.desm.netins.net 55.4% 846 7.9 8.1 7.8 14.8 0.4 5. v6-ins-dc1-te-7-4.desm.netins.net 54.3% 846 7.8 8.2 7.6 19.2 1.0 6. 2610:18:18b:c000::11 0.0% 846 12.9 14.0 12.8 73.0 5.4 7. mcr1.minneapolis-mn.us.xo.net 49.8% 846 54.7 70.0 54.6 100.1 8.1 8. 2610:18::5802 47.4% 846 58.3 71.9 54.6 82.9 8.2 9. 2610:18::5202 45.0% 846 54.4 72.1 54.4 83.3 8.4 2610:18::5804 10. 2610:18::2070 50.6% 845 54.4 70.4 54.3 88.8 8.1 2610:18::5304 11. sl-st31-ash-te0-15-2-0.v6.sprintlink.net 43.4% 845 57.5 59.1 53.1 80.5 2.3 2610:18::5303 12. sl-crs3-dc-be13.v6.sprintlink.net 46.7% 845 54.6 64.7 54.4 69.1 3.7 2610:18::5200 13. sl-crs1-ffx-be2.v6.sprintlink.net 44.1% 844 55.0 71.8 55.0 79.7 5.3 2610:18::5202 14. sl-crs1-orl-bu-1.v6.sprintlink.net 41.7% 844 54.9 75.7 54.7 96.3 7.4 2610:18::2070 15. sl-lkdstr2-p1-0.v6.sprintlink.net 41.0% 844 46.4 73.5 45.8 81.7 7.0 sl-st31-ash-te0-15-2-0.v6.sprintlink.net 16. www.sprint.net 43.1% 844 54.5 74.6 53.5 81.6 5.0 sl-crs3-dc-be13.v6.sprintlink.net

1 1