RE: 32-bit ASN acceptance by ISPs in ARIN region
I'd like to see an option for a larger private ASN block - 1K of private ASNs can be quite a pain in really large organizations. I have seen others mention this in the past - e.g. http://www.gossamer-threads.com/lists/cisco/nsp/158375 But apparently there's not enough traction to cause movement. -Original Message- From: Nick Hilliard [mailto:n...@foobar.org] Sent: Monday, September 23, 2013 10:22 AM To: Geoff Huston Cc: nanog@nanog.org list Subject: Re: 32-bit ASN acceptance by ISPs in ARIN region On 23/09/2013 15:14, Geoff Huston wrote: I'm sorry, but I'm still confused, as I see your comment as one that relates to the size of the payload field here, as distinct from the support for 32 bit AS numbers per se. hence my original comment about being usable on nontrivial transit networks, where having the size of the community local administrator = your customer asn bitfield size is a rather useful feature. There's also a serious vendor support problem at the moment. Nick
RE: PRISM: NSA/FBI Internet data mining project
On Saturday, June 08, 2013 6:44 PM, Ryan Malayter [mailto:malay...@gmail.com] wrote: Speaking from the content provider dide here, but we've always run IPsec on DCIs and even private T1s/DS3s back in the day. Doesn't everyone do the same these days? I find it hard to imagine passing any audit/compliance process without doing so. Private lines or dedicated fiber always pass through much public, unmanaged, and unmonitored space infrastructure. And we know better than to trust our providers to never screw up and mis-route traffic. I see that there is actually a beast that will do encryption of multiple 10G waves between Cisco ONS boxes - https://www.cisco.com/en/US/prod/collateral/optical/ps5724/ps2006/at_a_glance_c45-728015.pdf How many people are actually doing this?
RE: [outages] NTP Issues Today
Logs from a Juniper router in a customer network - we had hundreds of these affected. They all synchronize to internal hosts (172.20.167.251 and .252) which are configured to get time from NIST and USNO CORP-NTP-01#sh ntp as address ref clock st when poll reach delay offsetdisp *~192.5.41.41 .IRIG.1 354 512 37734.20.36 1.4 +~132.163.4.101.ACTS.1 336 512 37735.0 -2.5418.7 ~127.127.7.1 127.127.7.1 105964 377 0.00.00 0.0 * master (synced), # master (unsynced), + selected, - candidate, ~ configured CORP-NTP-02#sh ntp as address ref clock st when poll reach delay offsetdisp *~192.5.41.41 .IRIG.165 512 37736.50.91 0.6 +~132.163.4.101.ACTS.195 512 37734.3 -1.3122.8 ~127.127.7.1 127.127.7.1 104464 377 0.00.00 0.0 * master (synced), # master (unsynced), + selected, - candidate, ~ configured Here are the logs from one of the Junipers: Nov 19 14:24:48 xntpd[912]: kernel time sync enabled 2001 Nov 19 15:50:11 xntpd[912]: synchronized to 172.20.167.252, stratum=2 Nov 19 16:41:23 xntpd[912]: no servers reachable Nov 19 16:44:24 xntpd[912]: synchronized to 172.20.167.251, stratum=2 Nov 19 16:44:24 xntpd[912]: time correction of -378691200 seconds exceeds sanity limit (1000); set clock manually to the correct UTC time. Nov 19 16:44:24 init: ntp (PID 912) exited with status=255 Nov 19 16:44:24 init: ntp (PID 70200) started Nov 19 16:44:24 xntpd[70200]: ntpd 4.2.0-a Sat Apr 10 00:32:46 UTC 2010 (1) Nov 19 16:44:24 xntpd[70200]: mlockall(): Resource temporarily unavailable Nov 19 16:44:24 xntpd[70200]: precision = 0.582 usec Nov 19 16:44:24 xntpd[70200]: Listening on interface ggsn_vpn, 128.0.0.1#123 Nov 19 16:44:24 xntpd[70200]: kernel time sync status 2040 Nov 19 16:44:24 xntpd[70200]: frequency initialized -64.931 PPM from /var/db/ntp.drift Nov 19 16:44:24 xntpd[70200]: Configuring iburst flag for server Nov 19 16:44:24 xntpd[70200]: Configuring iburst flag for server Nov 19 16:44:33 xntpd[70200]: synchronized to 172.20.167.251, stratum=2 Nov 19 16:44:32 xntpd[70200]: time reset -378691200.411331 s Nov 19 16:44:32 xntpd[70200]: kernel time sync disabled 2041 Nov 19 16:45:44 xntpd[70200]: synchronized to 172.20.167.251, stratum=2 Nov 19 16:45:51 xntpd[70200]: kernel time sync enabled 2001 Nov 19 16:45:56 xntpd[70200]: NTP Server Unreachable Nov 19 16:53:25 xntpd[70200]: no servers reachable Nov 19 17:03:09 xntpd[70200]: NTP Server Unreachable Nov 19 17:13:00 xntpd[70200]: NTP Server Unreachable Nov 19 17:20:27 xntpd[70200]: synchronized to 172.20.167.252, stratum=2 Nov 19 17:20:27 xntpd[70200]: time correction of 378691200 seconds exceeds sanity limit (1000); set clock manually to the correct UTC time. Nov 19 17:20:27 init: ntp (PID 70200) exited with status=255 Nov 19 17:20:27 init: ntp (PID 70766) started Nov 19 17:20:27 xntpd[70766]: ntpd 4.2.0-a Sat Apr 10 00:32:46 UTC 2010 (1) Nov 19 17:20:27 xntpd[70766]: mlockall(): Resource temporarily unavailable Nov 19 17:20:27 xntpd[70766]: precision = 0.570 usec Nov 19 17:20:27 xntpd[70766]: Listening on interface ggsn_vpn, 128.0.0.1#123 Nov 19 17:20:27 xntpd[70766]: kernel time sync status 2040 Nov 19 17:20:27 xntpd[70766]: frequency initialized -64.931 PPM from /var/db/ntp.drift Nov 19 17:20:27 xntpd[70766]: Configuring iburst flag for server Nov 19 17:20:27 xntpd[70766]: Configuring iburst flag for server Nov 19 17:20:35 xntpd[70766]: synchronized to 172.20.167.252, stratum=2 Nov 19 17:20:36 xntpd[70766]: time reset +378691200.387434 s Nov 19 17:20:36 xntpd[70766]: kernel time sync disabled 6041 Nov 19 17:21:48 xntpd[70766]: synchronized to 172.20.167.252, stratum=2 Nov 19 17:21:48 xntpd[70766]: kernel time sync disabled 2041 Nov 19 17:21:52 xntpd[70766]: kernel time sync enabled 2001 Nov 20 00:02:29 xntpd[70766]: synchronized to 172.20.167.251, stratum=2 Nov 20 01:44:56 xntpd[70766]: kernel time sync enabled 6001 Nov 20 02:19:03 xntpd[70766]: kernel time sync enabled 2001 Nov 20 02:53:12 xntpd[70766]: kernel time sync enabled 6001 Nov 20 03:44:26 xntpd[70766]: kernel time sync enabled 2001 Nov 20 05:26:58 xntpd[70766]: kernel time sync enabled 6001 Nov 20 05:44:02 xntpd[70766]: kernel time sync enabled 2001 Nov 20 07:43:35 xntpd[70766]: kernel time sync enabled 6001 Nov 20 08:00:39 xntpd[70766]: kernel time sync enabled 2001 Nov 20 08:34:48 xntpd[70766]: kernel time sync enabled 6001 Nov 20 08:51:54 xntpd[70766]: kernel time sync enabled 2001 Nov 20 10:34:22 xntpd[70766]: synchronized to
RE: NANOG poll: favorite cable labeler?
We use the Brady IDXPERT label makers to create the self-laminating cable labels and Brother P-Touch to label devices, etc. The Brady label printers and supplies are a bit more expensive than the Brother but it's worth it for the cable labels. The Brother supplies are available at most office supply stores so you don't have issues with running out of label tape in the middle of a project; several different colors are available, etc. Both machines run in AA batteries (or AC wall-wort) There are lots of cartridge options for the Brady printers that we haven't explored yet just because we've been using the Brother printers for far longer. This dual-box approach has been working for us for many years but if I had to pick only one, I'd probably go with the Brady. http://www.bradyid.com/bradyid/pfpv/Printers-and-Label-Makers~Portable-Label-Printers~IDXPERT%E2%84%A2-Labeling-Printers.html -Original Message- From: Robert E. Seastrom [mailto:r...@seastrom.com] Sent: Tuesday, August 21, 2012 9:11 PM To: nanog@nanog.org Subject: NANOG poll: favorite cable labeler? Hey everyone, Many moons ago I worked in a place where we had a Brady LS2000 wire labeler. So long as the supplies were fresh it was great. In the storage unit I have a Brady TLS2200. Supplies are expensive, but it works reasonably well. Unfortunately the battery is shot (gotta replace that). It seems to me that as cheap as the Brother P-Touch type labelers have gotten that there might be some product by (Brady|Dymo|Brother|etc) that everyone uses and recommends these days which is (a) cheap enough that they can be deployed en masse rather than treated as a scarce resource, (b) hopefully runs on standard (such as AAA) battery types, and (c) has reasonably priced supplies. Labeling cables is mostly what I'm interested in. The el-cheapo p-touch seems adequate to putting hostnames on machines. Thoughts? -r
RE: Verizon's New Repair Method: Plastic Garbage Bags
Quality Union work! -Original Message- From: Miles Fidelman [mailto:mfidel...@meetinghouse.net] Sent: Monday, August 20, 2012 3:29 PM Cc: nanog@nanog.org Subject: Re: Verizon's New Repair Method: Plastic Garbage Bags Justin M. Streiner wrote: On Mon, 20 Aug 2012, Eric Wieling wrote: For a while we have had a customer with some lines which go down every time it rains. We put in the trouble ticket, a couple of days later Verizon says the issue is resolved...until the next time it rains. The customer sent us some pictures today of the pole outside their office. The repair appears to be wrapping some plastic bags around something up on the pole. Here is link to the pictures the customer sent us, in case anyone in the mood for a good scare. http://rock.nyigc.net/verizon/ If I didn't see the loops of electrical tape holding the whole works together I'd say that was a squirrel nest. The two aerial runs that appear to be using each other to turn a corner (right above the plastic-and-electrical-tape mess in the top picture) is an especially nice and creative touch. I sincerely hope the smaller of the two aerials is not a lashing wire. jmwell *there's* your problems Hey looks totally professional to me. After all, black tape is the network engineer's equivalent of duck tape, and, as we all know, duck tape holds the universe together! -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra
RE: Firewalls - Ease of Use and Maintenance?
We work with many vendor's firewalls and our current favorites are Palo Alto Networks - they're very full-featured and easy to manage. www.paloaltonetworks.com I don't want to get all sales-weasel on you but we can help if you want more info as we are one of their premier partners. P.S. - we're also Juniper and Cisco partners too but we prefer the Palo Altos for firewalls these days. Let me know how I can help -Ben R. Benjamin Kessler CCIE #8762, CISSP, CCSE President / Chief Network Geek Zenetra Corporation Email: ben.kess...@zenetra.com http://www.zenetra.com Office: 260-271-4330 Note: New Number Cell: 260-437-5774 Fax: 866-388-6652 -Original Message- From: Jones, Barry [mailto:bejo...@semprautilities.com] Sent: Tuesday, November 08, 2011 6:07 PM To: nanog@nanog.org Subject: Firewalls - Ease of Use and Maintenance? Hello all. I am potentially looking at firewall products and wanted suggestions as to the easiest firewalls to install, configure and maintain? I have a few small networks ( 50 nodes at one site, 50 odd at another, and maybe 20 at another. I have worked with Cisco Pix, ASA, Netscreen, and Checkpoint (Nokia), and each have strong and not as strong features for ease of use. Like everyone, I'm resource challenged and need an easy solution to stand up and operate. Feel free to ping me offline - and thank you for the assistance. Barry Jones - CISSP GSNA Project Manager II Sempra Energy Utilities (760) 271-6822 P please don't print this e-mail unless you really need to.
RE: Looking for an IPv6 naysayer...
From: William Herrin [mailto:b...@herrin.us] * Carrier NAT... I spend most of my days fighting with carriers to actually carry bits from point A to point B like they're paid to do. I'm sick and tired of them blaming CPE for circuit bounces and outages that are magically fixed without us doing anything to CPE. I have absolutely ZERO confidence that the carriers can implement NAT on a global scale such that it works and actually provides decent customer service. (realizing that this broad characterization is probably unfair to many smaller carriers who actually give a crap; my daily pain is generally caused by the Tier 1 guys)
RE: Post-Exhaustion-phase punishment for early adopters
From: George Herbert [mailto:george.herb...@gmail.com] Let's just grab 2/8, it's not routed on the Internet... +1 I was consulting for a financial services firm in the late '90s that was acquired by a large east-coast bank; the bank's brilliant scheme was to renumber all new acquisitions *out* of RFC1918 space and into (at the time) bogon space. If I recall, some of the arguments were they were too big to fit into RFC1918 space and by having all of their divisions in non-RFC1918 space it would make it easier for them to acquire new companies who used RFC1918 space internally. I wonder what they're doing now...
RE: ethernet to serial converters with ACLs
On Mar 10, 2010, at 3:17 PM, Michael Holstein wrote: Can anyone recommend a cheap Ethernet to Serial (RS232/422/485) converter with functionality like the Lantronix boxes .. except one that supports access lists (nothing complicated .. maybe a list of 5 approved hosts). I need a bunch of single port devices, not an access-server for a rack. We use SENA PS110 boxes ( http://www.sena.com/products/device_servers/hd_ps_x10.php ). They work very well, have various ACL features (dunno if it supports 5 named IP or not), and other configurables. Caleb On a similar topic, any good solutions for out-of-band serial console/Ethernet solutions that use EV-DO/GSM wireless Internet?
MLFR Differential Delay Problems
Hello NANOGers - I'm working on a project to migrate a customer from one Tier 1 provider to another at 50+ locations (all domestic US sites). Most of these connections are 4xT1 multi-link bundles. The old router configuration was MLPPP which was rock-solid for 3 years (save for the typical last-mile circuit issues, fiber-cuts, etc.). The new carrier uses FRF.16 multi-link Frame Relay vs. MLPPP. We've completed the migration on 10+ sites and all of them are now reporting errors like the following: Feb 17 21:01:39 /kernel: MFR bundle ls-0/0/0:0 link t1-1/0/0 differential 91.7 ms over yellow differential delay 75 ms Feb 17 21:01:50 /kernel: MFR bundle ls-0/0/0:0 link t1-1/0/0 differential 115.9 ms over yellow differential delay 75 ms Feb 17 21:01:50 /kernel: MFR bundle ls-0/0/0:0 link t1-1/0/1 differential 79.0 ms over yellow differential delay 75 ms Feb 17 21:01:50 /kernel: MFR bundle ls-0/0/0:0 link t1-2/0/1 differential 79.1 ms over yellow differential delay 75 ms Feb 17 21:01:50 /kernel: MFR bundle ls-0/0/0:0 link t1-1/0/1 differential 97.4 ms over yellow differential delay 75 ms Feb 17 21:01:50 /kernel: MFR bundle ls-0/0/0:0 link t1-2/0/0 differential 97.5 ms over yellow differential delay 75 ms Feb 17 21:01:50 /kernel: MFR bundle ls-0/0/0:0 link t1-2/0/1 differential 97.5 ms over yellow differential delay 75 ms Feb 17 21:01:52 /kernel: MFR bundle ls-0/0/0:0 link t1-1/0/1 differential 97.4 ms over yellow differential delay 75 ms Feb 17 21:01:52 /kernel: MFR bundle ls-0/0/0:0 link t1-2/0/0 differential 97.5 ms over yellow differential delay 75 ms Feb 17 21:01:52 /kernel: MFR bundle ls-0/0/0:0 link t1-2/0/1 differential 97.5 ms over yellow differential delay 75 ms Feb 17 21:01:53 /kernel: MFR bundle ls-0/0/0:0 link t1-1/0/1 differential 90.0 ms over yellow differential delay 75 ms Feb 17 21:01:53 /kernel: MFR bundle ls-0/0/0:0 link t1-2/0/1 differential 100.0 ms over yellow differential delay 75 ms The customer routers are all Juniper J6350; I believe the Carrier's routers are all Cisco GSRs. Advanced JTAC says that our configurations are solid and that there are no known bugs that would exhibit behavior like this. The carrier is insisting on performing physical-level tests of the circuits (even though they're running error free) before they'll engage higher-level engineers so I'm currently in a holding pattern awaiting those results. My Google-foo is failing me and I'm not able to find any documents that help explain what may be causing this and how to troubleshoot and find an eventual solution. I would really appreciate any tips or suggestions from anyone on the list that may have seen issues like this in the past. Thanks, Ben
cisco.com
Hey Gang - I'm unable to get to cisco.com from multiple places on the 'net (including downforeveryoneorjustme.com); any ideas on the cause and ETR? Thanks, Ben
What Platform for a small ISP (was: Cisco 7600 (7609) as a core BGP router)
There has been a lot of good feedback regarding the deficiencies of the 7600 platform... So, the new question is: what platforms should a small, start-up ISP consider when looking to provide Ethernet services to their customers? - Scalability - 100M, 1G, 10G access speeds (backplane limitations, number of ports per chassis, etc.) - MPLS Capabilities - QoS Features - Ease of configuration and support, etc. (finding NOC talent, scripting tools, etc.) - Software/Hardware stability and longevity (we don't want something that is brand-new and therefore buggy nor do we want something that is going EOL next year) - Bang for the buck (both acquisition and on-going maintenance and support) I'm sure I'm missing a lot of things...are there any good presentations from previous NANOG meetings that one should review? Thanks in advance, Ben
RE: What Platform for a small ISP (was: Cisco 7600 (7609) as a core BGP router)
On 7/22/09 9:48 AM, Jim Wininger jwinin...@indianafiber.net wrote: What do you consider a small start-up ISP? What kind of upstream connectivity are you considering (or at least falls under the category of small isp) bandwidht, bgp etc? two or three upstreams - OC-12 to 1G to each (BGP full tables) three POPs meshed together On 7/22/09 9:39 AM, R. Benjamin Kessler r...@mnsginc.com wrote: There has been a lot of good feedback regarding the deficiencies of the 7600 platform... So, the new question is: what platforms should a small, start-up ISP consider when looking to provide Ethernet services to their customers? - Scalability - 100M, 1G, 10G access speeds (backplane limitations, number of ports per chassis, etc.) - MPLS Capabilities - QoS Features - Ease of configuration and support, etc. (finding NOC talent, scripting tools, etc.) - Software/Hardware stability and longevity (we don't want something that is brand-new and therefore buggy nor do we want something that is going EOL next year) - Bang for the buck (both acquisition and on-going maintenance and support) I'm sure I'm missing a lot of things...are there any good presentations from previous NANOG meetings that one should review? Thanks in advance, Ben
