- Test - lists.nanog.org

contact with mail support for domain cisco.com
by Piotr 28 Apr '16

28 Apr '16

Hi, There is a problem with sending emails from employees in @cisco.com domain to some certain domain. Emails in opposite direction pass without problem. No errors, warnings or any other logs at cisco's employees desktop.. We checked popular rbls, spamhauses, senderbase etc. Other domains on the same MX cluster receive emails from @cisco.com.. I try to get help in many ways ( cisco tac, a few account managers, channel partners) but without success.. Big thanks for contact via email: peter.handke.1966 at gmail.com or any other advice best regards, Peter

2 1

NYC & Philly Metro rack stack and config
by Daniel Corbe 28 Apr '16

28 Apr '16

If anyone in the NYC and Philly metro areas want to make a few extra bucks, contact me off list. I need someone to drop an initial config on some brocade routers and run some cabling. Best, Daniel

1 0

IPv6 prefix from T-Mobile USA used but not announced in BGP (2607:7700::/32)
by Baptiste Jonglez 27 Apr '16

27 Apr '16

Hi, While doing statistics on the participants of a public DHT, I was surprised to see some IP addresses that are not present in the DFZ: 2607:7700:0:25::4e00:605b 2607:7700:0:25::4e25:8ce8 2607:7700:0:25::c808:db2c 2607:7700:0:4::3294:6683 2607:7700:0:4::4c09:4d39 2607:7700:0:4::5985:87d1 2607:7700:0:4::5d7d:3df8 All those IP are in 2607:7700::/32, allocated to T-Mobile USA but never announced: https://stat.ripe.net/2607%3A7700%3A%3A%2F32#tabId=at-a-glance What could explain their usage in an application? Some form of address translation? Maybe these addresses have been used as source address in outgoing packets, which would indicate IPv6 tests in T-Mobile? (but obviously, nobody is able to answer such packets). Baptiste

3 5

Re: IPv6 prefix from T-Mobile USA used but not announced in BGP (2607:7700::/32)
by Baptiste Jonglez 27 Apr '16

27 Apr '16

On Wed, Apr 27, 2016 at 02:38:41PM -0700, Ca By wrote: > What behavior do you expect when an ipv6only node connects to an ipv4only > node , which is the tmobile case? How is that address of the address > report? As far as I know, IPv4-only DHT nodes do not directly communicate with IPv6-only DHT nodes, I don't see how this would be possible in general. The code of the DHT client is here: https://github.com/savoirfairelinux/opendht > On Wednesday, April 27, 2016, Baptiste Jonglez <baptiste(a)bitsofnetworks.org> > wrote: > > > On Wed, Apr 27, 2016 at 01:16:28PM -0700, Aaron Hopkins wrote: > > > On Wed, 27 Apr 2016, Baptiste Jonglez wrote: > > > > > > >While doing statistics on the participants of a public DHT, I was > > > >surprised to see some IP addresses that are not present in the DFZ: > > > > > > I believe those are used by T-mobile's 464XLAT (RFC 6877) implementation. > > > > > > Recent Android on T-mobile is IPv6-only and has no ability to connect to > > > raw IPv4 addresses. T-mobile's DNS servers are only asked by these > > devices > > > to translate hostnames to IPv6 addresses. If they can't find an IPv6 > > > address, they will look up the IPv4 address for a hostname, and pack it > > into > > > the bottom 32 bits of an IPv6 address that routes to a IPv6-to-IPv4 NAT > > > device. > > > > Thanks, I had forgotten that DNS64 is possible without using the > > well-known prefix. The encoded IPv4 addresses seem to belong to other > > peers of the DHT. > > > > So, if this is basically DNS64/NAT64, these IP addresses should not be > > seen as source or destination address outside of T-Mobile's network, and > > are not attached to the interface of any device. > > > > I can see two possible explanations: > > > > 1/ packets with src or dest IP in 2607:7700::/32 somehow escaped > > T-Mobile's network, without being translated back to IPv4. They caused > > other DHT nodes to believe they have incoming peers in 2607:7700::/32. > > > > 2/ there is an interesting bug in the DHT software when run behind 464XLAT > > (btw, the DHT is dual-stack and supports IPv6 just fine) > > > > I still wonder how this can happen, because the DHT does not use DNS at > > all... > > > > Baptiste > >

1 0

GeoIP database issues and the real world consequences
by Chris Boyd 27 Apr '16

27 Apr '16

Interesting article. http://fusion.net/story/287592/internet-mapping-glitch-kansas-farm/ An hour’s drive from Wichita, Kansas, in a little town called Potwin, there is a 360-acre piece of land with a very big problem. The plot has been owned by the Vogelman family for more than a hundred years, though the current owner, Joyce Taylor née Vogelman, 82, now rents it out. The acreage is quiet and remote: a farm, a pasture, an old orchard, two barns, some hog shacks and a two-story house. It’s the kind of place you move to if you want to get away from it all. The nearest neighbor is a mile away, and the closest big town has just 13,000 people. It is real, rural America; in fact, it’s a two-hour drive from the exact geographical center of the United States. But instead of being a place of respite, the people who live on Joyce Taylor’s land find themselves in a technological horror story. For the last decade, Taylor and her renters have been visited by all kinds of mysterious trouble. They’ve been accused of being identity thieves, spammers, scammers and fraudsters. They’ve gotten visited by FBI agents, federal marshals, IRS collectors, ambulances searching for suicidal veterans, and police officers searching for runaway children. They’ve found people scrounging around in their barn. The renters have been doxxed, their names and addresses posted on the internet by vigilantes. Once, someone left a broken toilet in the driveway as a strange, indefinite threat. --Chris

52 115

trout views
by Randy Bush 27 Apr '16

27 Apr '16

nfs0.dfw.rg.net:/root# ping 128.223.51.20 PING 128.223.51.20 (128.223.51.20) 56(84) bytes of data. From 4.69.145.11 icmp_seq=1 Time to live exceeded From 4.69.145.11 icmp_seq=2 Time to live exceeded ^C --- 128.223.51.20 ping statistics --- 2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1001ms nfs0.dfw.rg.net:/root# traceroute 128.223.51.20 traceroute to 128.223.51.20 (128.223.51.20), 30 hops max, 60 byte packets 1 r0.dfw.rg.net (198.180.152.3) 1.571 ms 1.559 ms 1.597 ms 2 r1.dfw.rg.net (198.180.152.2) 0.558 ms 0.551 ms 0.640 ms 3 ge-102-0-0-29-53.r08.dllstx09.us.bb.gin.ntt.net (157.238.224.205) 1.562 ms 1.598 ms 1.716 ms 4 ae-12.r07.dllstx09.us.bb.gin.ntt.net (129.250.3.107) 0.488 ms 0.538 ms 0.582 ms 5 * * * 6 * * * 7 ae-65-65.csw1.Dallas1.Level3.net (4.69.206.133) 0.514 ms 0.555 ms ae-95-95.csw4.Dallas1.Level3.net (4.69.206.145) 0.525 ms 8 ae-3-80.edge2.Dallas1.Level3.net (4.69.145.139) 0.627 ms 0.769 ms ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11) 0.633 ms 9 vlan90.csw4.Dallas1.Level3.net (4.69.145.254) 0.517 ms vlan80.csw3.Dallas1.Level3.net (4.69.145.190) 0.589 ms 0.676 ms 10 ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11) 0.519 ms ae-3-80.edge2.Dallas1.Level3.net (4.69.145.139) 0.632 ms ae-4-90.edge2.Dallas1.Level3.net (4.69.145.203) 13.412 ms 11 vlan60.csw1.Dallas1.Level3.net (4.69.145.62) 13.264 ms 0.604 ms vlan80.csw3.Dallas1.Level3.net (4.69.145.190) 0.530 ms 12 ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11) 0.633 ms 0.519 ms 0.513 ms 13 vlan80.csw3.Dallas1.Level3.net (4.69.145.190) 0.540 ms vlan60.csw1.Dallas1.Level3.net (4.69.145.62) 13.318 ms vlan90.csw4.Dallas1.Level3.net (4.69.145.254) 0.554 ms 14 ae-3-80.edge2.Dallas1.Level3.net (4.69.145.139) 0.723 ms ae-4-90.edge2.Dallas1.Level3.net (4.69.145.203) 12.793 ms ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11) 0.494 ms 15 vlan80.csw3.Dallas1.Level3.net (4.69.145.190) 0.554 ms vlan90.csw4.Dallas1.Level3.net (4.69.145.254) 0.541 ms vlan80.csw3.Dallas1.Level3.net (4.69.145.190) 2.040 ms 16 ae-4-90.edge2.Dallas1.Level3.net (4.69.145.203) 12.294 ms ae-3-80.edge2.Dallas1.Level3.net (4.69.145.139) 0.896 ms 0.790 ms 17 vlan80.csw3.Dallas1.Level3.net (4.69.145.190) 0.590 ms vlan60.csw1.Dallas1.Level3.net (4.69.145.62) 0.610 ms vlan80.csw3.Dallas1.Level3.net (4.69.145.190) 0.932 ms 18 ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11) 0.522 ms ae-4-90.edge2.Dallas1.Level3.net (4.69.145.203) 11.423 ms ae-3-80.edge2.Dallas1.Level3.net (4.69.145.139) 0.747 ms 19 vlan90.csw4.Dallas1.Level3.net (4.69.145.254) 0.673 ms vlan80.csw3.Dallas1.Level3.net (4.69.145.190) 0.803 ms vlan60.csw1.Dallas1.Level3.net (4.69.145.62) 0.638 ms 20 ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11) 0.525 ms ae-3-80.edge2.Dallas1.Level3.net (4.69.145.139) 0.826 ms 0.876 ms 21 vlan60.csw1.Dallas1.Level3.net (4.69.145.62) 0.635 ms 9.840 ms 9.404 ms 22 ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11) 0.622 ms 0.604 ms ae-4-90.edge2.Dallas1.Level3.net (4.69.145.203) 8.751 ms 23 vlan80.csw3.Dallas1.Level3.net (4.69.145.190) 0.671 ms 0.817 ms 0.687 ms 24 ae-3-80.edge2.Dallas1.Level3.net (4.69.145.139) 0.785 ms 0.754 ms ae-4-90.edge2.Dallas1.Level3.net (4.69.145.203) 4.774 ms 25 vlan90.csw4.Dallas1.Level3.net (4.69.145.254) 0.633 ms 0.683 ms 0.795 ms 26 ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11) 0.659 ms ae-3-80.edge2.Dallas1.Level3.net (4.69.145.139) 0.758 ms 0.907 ms 27 vlan60.csw1.Dallas1.Level3.net (4.69.145.62) 0.776 ms vlan90.csw4.Dallas1.Level3.net (4.69.145.254) 0.721 ms vlan60.csw1.Dallas1.Level3.net (4.69.145.62) 0.705 ms 28 ae-4-90.edge2.Dallas1.Level3.net (4.69.145.203) 15.057 ms 14.660 ms ae-3-80.edge2.Dallas1.Level3.net (4.69.145.139) 0.871 ms 29 vlan80.csw3.Dallas1.Level3.net (4.69.145.190) 0.864 ms vlan60.csw1.Dallas1.Level3.net (4.69.145.62) 0.752 ms 0.747 ms 30 ae-3-80.edge2.Dallas1.Level3.net (4.69.145.139) 0.877 ms ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11) 0.721 ms ae-4-90.edge2.Dallas1.Level3.net (4.69.145.203) 14.302 ms and, of course, email does not work

3 4

NCS5K?
by Chris Welti 27 Apr '16

27 Apr '16

According to some slides from a russian cisco connect event, the upcoming small-size NCS 5501 and NCS 5502 will support 1M+ FIB and 50ms per port buffers. Seem to be killer boxes. 48x100GE in 2RU with large FIB & buffers? Loving it already. I wonder what prices will look like for those. With Google Translate: NCS 5501 • 800 Gbps @ 430 watts • 40 x SFP + 1G / 10G + 4 x QSFP28 100G • 1RU • Intel Broadwell CPU 8Core @ 1.6GHz • Dimensions WxDxH 444mm x551mm x 44mm • External TCAM for more FIB, large buffers (~ 50 ms) • 1-2M IPv4 FIB • The same set of features as a modular • FCS in IOS XR 6.1.1 NCS 5502 • 4.8 Tbps 100G @ ~ 2200 W • 48 x QSFP 28 or QSFP + optics • 2RU • Intel Broadwell CPU 12Core @ 1.6GHz • 8 ASIC packet processing • Integrated FIA • External FIB TCAM for more • Large buffers (~ 50 ms) • 1-2M IPv4 FIB • The same set of features as a modular • FCS in IOS XR 6.1.1 On Mon Jan 25 18:01:41 EST 2016, Phil Bedard <philxor at gmail.com> wrote: > My guess is you will see something from Cisco similar to the PTX1K in the > NCS 55XX series but it will be more expensive than the 500X series. These > boxes I believe use the Broadcom Tomahawk chipset and the NCS55XX uses the > Jericho. The Jericho can support an external TCAM with more routes but > with some speed limitations since the bus to the off-chip TCAM memory is > slower. Those boxes will also have more packet buffering than what you'll > find on the 500X. > > Either way the cost of 100G is rapidly dropping, crazy to think what we > paid for just a CFP transceiver a few years ago.

4 6

Firewall list recommendations (config conversion options)
by b f 25 Apr '16

25 Apr '16

Hi list, Could any one recommend any firewall related mailing lists? Looking for options on converting a large amount of Fortinet rules to Checkpoint. Ultimately converting the entire configuration to Checkpoint would be nice. Thank you for any advice you can provide. Respectfully, Ed

4 3

As a SP, what is your standard CoS configuration on JunOS?
by Sean Kennedy 25 Apr '16

25 Apr '16

NANOG, I realize that every SP handles marking and queueing/scheduling differently, but I am curious to see other provider's 'standard' config for QoS that is deployed on the JunOS platform. What config do apply to all your ingress interfaces for classification? How are your core link schedulers configured? What kind of remarking do you do (specifically on packets arriving on internet-facing interfaces)? If you have a converged network carrying both internet and carrier-eth/transport traffic, how do you handle guaranteeing bandwidth to the carrier eth services? Thank you, Sean

2 1

google and amazon wierdness via HE right now
by Ken Chase 22 Apr '16

22 Apr '16

>From toronto - something odd - mtr to google.com (google.com (172.217.3.142)) 5. v638.core1.tor1.he.net 6. 100ge7-2.core1.nyc4.he.net 7. 100ge11-1.core1.par2.he.net 8. 10ge3-2.core1.zrh1.he.net 9. ??? par is paris, zrh is zurich? same base path for hitting my EC2 nodes... Cant imagine this is just affecting Toronto HE customers. EC2 node is in 107.20/14 /kc

6 6