Re: SD-WAN Solutions
On 5/24/18 12:24 PM, Scott Weeks wrote: --- sab...@auxes.is wrote: From: "Sabina M." Additionally, is anyone familiar with what RFC Alcatel/Nokia is implementing for the VXLAN part of the solution? It looks a bit non-standard but I can't find any clear documentation regarding this anywhere --- You might try over on alcatel-...@puck.nether.net. Alcatel folks used to (still do?) hang out over there to answer questions. That is a good list to use indeed. Many employees are subscribed there, although traffic is pretty low. ...Or for questions about Nuage, feel free to reach out to me. AJ a...@nuagenetworks.net Nuage Networks from Nokia (and Alcatel-Lucent/Alcatel).
Re: Best way to San Jose Fairmont from SFO?
I live in the next block along from the Fairmont. For people who want to use CalTrain then there is the Downtown Area Shuttle (DASH) that runs from Diridon around the downtown area and will pass by the Fairmont on San Fernando St. The shuttle is timed to connect with CalTrain in both directions and is free, so it's probably the most convenient. That said... I would just take Lyft/Uber. SFO to downtown SJC via public transport is annoying. I try to fly in/out of SJC as much as possible. AJ > On Sep 29, 2017, at 9:56 AM, Owen DeLong wrote: > > >> On Sep 29, 2017, at 1:07 AM, Julien Goodwin wrote: >> >> On 29/09/17 06:47, Bob Evans wrote: >>> Train and Bus travel is not worth considering. However, there are airport >>> shuttle van services like supershuttle 4-5 passengers being dropped off on >>> your way south. >> >> I'm arriving on Sunday morning, so have plenty of time, and will take >> Caltrain down (BART to Millbrae, then Caltrain), sure it'll take 2h, but >> any van service wouldn't be much faster. >> >> During the week, or out of daylight hours it's a much less sensible idea. >> > > I disagree… I’ve done it during the week and it’s not that bad. > > I find Lyft to be the most desirable option (About $65), with Uber as > a second choice. > > Third choice would be BaRT/CalTrain (to Diridon) followed by either a very > short Lyft ride or VTA bus or light rail. > > Another option (if you get on the right CalTrain) is Tamien station and > connection to light rail there. > > Light rail gets you _VERY_ close to the Fairmont. The Fairmont has entrances > on Market St. (Front Door direct to Lobby) and First St. (Back door, hallway > to lobby). The VTA light rail northbound is on First St. > > I’m not 100% sure of the light rail routing from the Diridon station to > downtown > as it’s tied to the Almaden line and I’m usually dealing with the Santa Teresa > line. > > I, myself intend to bicycle to the meeting as my home is only about 7 miles > away. > > Owen >
Re: IPv4 Legacy assignment frustration
On 6/22/16 6:36 AM, Spurling, Shannon wrote: It’s a problem with the miss-use of the RIR delegation of a legacy block. The assumption that because a block is assigned to a particular RIR, all users in that block have to be in that RIR’s territory, without actually running a query against that RIR’s Whois database. I don't think it's an RIR / RIR-related problem, just - as you said - a short-sighted security practice. Operators that connect to the Internet and then decide "OMG, Asia is evil" are fairly frustrating. This has caused me a number of problems for decades, as AU/NZ are fairly frequent trading partners of USA and I have frequently run into this attitude.
Re: BRAS sugestion
On 8/14/15 11:06 AM, Julian Eble wrote: Hello Nanog, Our company are constantly growing and we're looking for a 30k+ subscribers BRAS, does the community have a sugestion? Alcatel-Lucent 7750SR AJ
Re: Keeping Track of Data Usage in GB Per Port
There's no correlation between PPPoE and RADIUS. Many (if not all) BRAS/BNG platforms will support RADIUS based accounting for IPoE sessions. The majority of accounting is done that way; with outliers using some other mechanism (Diameter; proprietary vendor billing solutions; flow based platforms; or counters elsewhere on the network). WiFi in my experience also typically uses a RADIUS based approach, although it can depend on the deployment context. AJ Original Message From: Colton Conor Sent: Sunday, October 19, 2014 3:35 PM To: Livingood, Jason Cc: NANOG Subject: Re: Keeping Track of Data Usage in GB Per Port So it looks like DOCSIS cable has a great solution with IPDR, but what about DSL, GPON, and regular Ethernet networks? It was mentioned that DSL uses radius, but most new DSL systems no longer use PPPoE, so I don't believe radius is a viable option. What about Wifi Access Points? What would be the best way to track usage across these devices? On Wed, Oct 15, 2014 at 3:33 PM, Livingood, Jason < jason_living...@cable.comcast.com> wrote: > There are lots of ways to do it. Cable uses IPDR, which is baked into > DOCSIS standards. > http://en.wikipedia.org/wiki/Internet_Protocol_Detail_Record > > > > On 10/15/14, 1:38 PM, "Colton Conor" wrote: > > >So based on the response I have received so far it seems cable was a > >complicated example with service flows involved. What if we are talking > >about something simpler like keeping track of how much data flows in and > >out of a port on a switch in a given month? I know you can use SNMP, but I > >believe that polls in intervals and takes samples which isn't really > >accurate right? > > > >On Wed, Oct 15, 2014 at 1:40 PM, wrote: > > > >> Folks, use sflow with rrdtool! > >> > >> Quite awesome & handy > >> > >> On 15/10/2014 20:14, valdis.kletni...@vt.edu wrote: > >> > On Wed, 15 Oct 2014 13:06:56 -0500, Colton Conor said: > >> > > >> >> on a cisco switch vs a DSL port on a DSLAM for example? I would think > >> these > >> >> access switches would have some sort of stat you can count similar > >>to a > >> >> utility meter reader on a house. See what it was at last month, see > >> what is > >> >> is at this month, subtract last months from this months, and the > >> difference > >> >> is the total amount used for that month. > >> > > >> > Assume a 20mbit connection. How many times can this roll over a > >> > 32 bit counter in a month if it's going full blast? > >> > > >> > >> > >
Re: RSVP Cisco ASR-9k to ALU 7750
On 12/2/2013 9:55 AM, Rampley Jr, Jim F wrote: Wondering if anybody on the list has any working configurations for RSVP tunnels between a Cisco ASR9k to Alcatel-Lucent 7750? I've been able to get LSP's up and talking between the two boxes, but I'm having an issue getting the RSVP tunnels to come up on the Cisco side. You may need to enable adspec on the 7750 side, otherwise the ASR will always advertise a 500 byte MTU on the LSP, which will usually cause problems (service MTU checks, etc). config router mpls lsp adspec HTH, AJ
Re: p2p addresses for point-to-point connections with customers
On 11/6/2012 5:44 AM, Tassos Chatzithomaoglou wrote: Roland, how do you handle customer requests regarding the remote management of their devices? i.e. if the customer wants to do any kind of management (ssh, snmp) from outside his router, he must use our infrastructure address (which is configured on his router) as a destination. Generally, the customer might want to use this wan address for many other things which you shouldn't actually care, since it's his router. Why would the customer not have a loopback interface configured on his router with an accessible IP address? Relying on the WAN address is arguably a poor choice for a number of reasons including renumbering events and circuit outages.
Re: Typical additional latency for CGN?
On 10/7/2012 1:47 PM, Tom Limoncelli wrote: Have there been studies on how much latency CGN adds to a typical internet user? I'd also be interested in anecdotes. You are typically talking microseconds of additional latency for sessions transiting a CGN/LSN type node. aj
Re: SDH Fiber Problem
On 9/19/2011 12:22 AM, jacob miller wrote: I have tried the pings and am able to ping through with a size of 1600 with the df-bit set without the df-bit am able to get up to 9000. The switched on bot ends hav been set to allow jumbo frames through and the system MTU size and routing MTU sizes are at 1998. The switch is a 2960 Cisco switch. I have set the mtu on the interface on the end router to 1600 and still unable to push meaningful traffic. How much traffic are you trying to pass over the link? How big is the underlying VCAT? Is it possible that this is misconfigured does not have enough bandwidth? Depending on the underlying EoSONET/EoSDH bandwidth, you might need to pace traffic into the ADM to avoid overrunning buffers. aj
Re: Enterprise Internet - Question
On 7/14/2011 7:37 PM, Owen DeLong wrote: > To the best of my knowledge, while this person reset my account so that > I could log in (from my house), I don't think Wells Fargo has any intention > of rethinking their geo-IP based restrictions on logging in. > > So, if you travel, consider carefully whether to try and log into something > directly vs. doing so over VNC. For precisely this reason I always ensure that my banking traffic goes via a VPN through a relatively consistent set of origin IPs to the wider Internet. Solves a lot of headaches, although PayPal were confused that I could be in California and have my traffic come from Chicago (which they thought was New Jersey...). _ NANOG mailing list NANOG@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog
Re: Weekend Gedankenexperiment - The Kill Switch
No - at least some links were still up. I saw both IPVPNs and leased lines still working during the event. aj -Original Message- From: "Ryan Finnesey" Date: Sat, 5 Feb 2011 23:58:35 To: Fred Baker; Hayden Katzenellenbogen Cc: NANOG list Subject: RE: Weekend Gedankenexperiment - The Kill Switch Does anyone know when they took down connectivity in Egypt did they also bring down the MPLS networks global companies use? Cheers Ryan -Original Message- From: Fred Baker [mailto:f...@cisco.com] Sent: Saturday, February 05, 2011 9:43 AM To: Hayden Katzenellenbogen Cc: NANOG list Subject: Re: Weekend Gedankenexperiment - The Kill Switch On Feb 4, 2011, at 9:49 PM, Hayden Katzenellenbogen wrote: > Not sure if it has been said already but wasn't one of the key point > for the creation of the internet to create and infrastructure that > would survive in the case of all out war and massive destruction. > (strategic nuclear strikes) Urban legend, although widely believed. Someone probably made the observation. > Does it not bode ill for "national security" if any party could take > out a massive communication system by destroying/pressuring a few > choke points? You mean, like drop a couple of trade towers and take out three class five switches, causing communication outages throughout New England and New Jersey, and affecting places as far away as Chicago? Nope. Couldn't happen. More seriously, yes, one could in fact take out any connectivity one wants by withdrawing routes (which is reportedly what Egypt did), and if you hit enough interchange points that could get serious. At the risk of sounding naive and pollyanna-ish, we have a few more of those interchange points in the US than they have in Egypt. In theory, yes. Making it actually happen could be quite an operation. > -Original Message- > From: JC Dill [mailto:jcdill.li...@gmail.com] > Sent: Thursday, February 03, 2011 11:39 PM > To: NANOG list > Subject: Re: Weekend Gedankenexperiment - The Kill Switch > > On 03/02/11 10:38 PM, Paul Ferguson wrote: >> >> And as an aside, governments will always believe that that they can > control >> the flow of information, when push comes to shove. >> >> This has always been a hazard, and will always continue to be so. >> >> As technologists, we need to be cognizant of that fact. > > In the US, by accident (surely not by design) we are lucky that our > network of networks does not have the convenient 4 chokepoints that > the Egyptian network had, making it easy for the government to shut > off the entier internet by putting pressure on just 4 companies. > > Where we *really* need to be fighting this battle is in the laws and > policies that are producing a duopoly in much of the US where > consumers have 2 choices, the ILEC for DSL or their local cableco for > Cable Internet. As theses companies push smaller competing ISPs out > of business, and as they consolidate (e.g. Cablecos buying each other > up, resulting in fewer and fewer cablecos over time), we head down the > direction of Egypt, where pressure on just a few companies CAN shut > down > > the entire internet. Otherwise we end up with a few companies that > will > > play Visa and PayPal and roll over and play dead when a government > official says "Wikileaks is bad" - and equally easily will shut down > their entire networks for "national security". > > If you *really* believe that the TSA is effective, you would be in > favor > > of an Internet Kill Switch. If you understand that this is really > security theater, and despite all the inconvenience we aren't really > any > > safer, then you should equally be very concerned that someone ever has > the power to order that the internet be "shut down" for our safety. > > jc > > >
Re: Connectivity status for Egypt
On 1/28/2011 1:02 PM, Alexander Harrowell wrote: I wonder if anyone's working on a mesh or p-t-p radio app that runs on a smartphone? Yes - came across http://www.servalproject.org/ from the linux.conf.au program.
Re: Connectivity status for Egypt
On 1/28/2011 8:17 AM, Christopher Morrow wrote: out of curiousity, what's the difference though between loss of light and peer shutdown? If the local gov't comes in and says: "Make the internets go down", you as the op choose how to do that... NOT getting calls from your peer for interface alarms is probably sane. You can simply drop your routes, leave BGP running even and roll ... If it's clear (and it seems to be) that the issue is a nation-state-decision... implementation (how it's done, no IF it's done) isn't really important, is it? I guess it depends on what goes down as an effect of the mandate. If it's full Layer 1 severing, then leased line and other circuits will go down too. If it's just "shut down your Internet peering sessions", then there's alternative opportunities for connectivity. For instance, our corporate WAN links into Cairo are still up (UUNET PIP). aj
Re: Dial Concentrators - TNT / APX8000 R.I.P.
Mark Foster wrote: Thus the wider concern I flagged; if the only source for equipment and spares is the grey market, aren't the vendors missing the boat on something which shouldn't even have a major overhead to maintain? There is no sales of new chassis, which means the manufacturing is shut down. The costs to maintain support and spares for an obsolete platform with a declining customer base and no further sales is quite high for the vendor. If they charged the real cost to provide support to the operator, most likely the operator wouldn't take the support contract. End result: end of support. If the operator /really/ needs to keep it going, they'll figure out a way to spare it. Telcos have been specialists in this regard for a long time. What about developing nations where Internet isn't yet as commonplace as it is in the 'west' ? They skip dialup.
Re: Dial Concentrators - TNT / APX8000 R.I.P.
Chris Adams wrote: How are ISPs that still offer dialup going to handle dialup and IPv6? I know the TNTs don't do it, and I don't think most of the old equipment in use in many places does. Most likely the customers still on dialup are not going to worry about IPv6 - if their systems even support it. In fact several operators I have spoken to have considered their legacy dialup plant as a good place to test Carrier Grade NAT in a low impact manner. Couple it with some kind of ALG (transparent proxy + DNS tricks) for IPv6-only sites and you have something which might work. If you really need native IPv6 support for dialup then using a legacy NAS as a dial-terminator LAC and tunneling to an IPv6 capable LNS might be a solution for you. aj
Re: Dial Concentrators - TNT / APX8000 R.I.P.
Mark Foster wrote: Does this not highlight a wider issue? I realise that dialup is hardly 'cutting edge' but there are providers out there with a significant number of dialup customers still on the books. Surely there's still a market for (what should be by now) a straightforward, well known piece of kit? In parts of the world where broadband is not ubiquitous and dialup remains useful as a Plan-B or is simply the only choice (for whatever reason), what are the practical choices now? Whilst folks may not be fielding 'new' dialup kit, I dare say that we're going to be continuing to see dialup customers on the books for the next 5 years, perhaps a lot longer? That's a whole product lifespan... Welcome to what telcos have been dealing with for 10 to 20 years with product lifecycles. The PSTN isn't exactly a growing market, and has lots of EOL switches, yet it continues to run. Secondary support markets, grey markets, and strategic migrations to carry internal sparing. Or you find a cost effective way to replace it with something; or you accept that the revenue vs. cost-to-maintain is too high and just kill the product. aj p.s. UTStarcom was still supporting the [former USR/3com] TotalControl chassis as of about 2 years ago; I don't know if they still do. They were positioning it as a migration platform for legacy X.25 networks.
Re: Finding content in your job title
Steve Bertrand wrote: I did not mean to initiate a thread that turns into a joke. I'm quite serious. I guess I'm curious to get an understanding from others who work in a small environment that have no choice but to 'classify' themselves. When I was in a similar role and situation to yourself my cards said "network manager". These days, working in an organisation big enough to restructure weekly, I removed the title from my business cards - now I have a blank space where I can write one in if I really *need* it. But mostly I don't. aj