Re: Riot Games
Hi Alistair (and anyone else interested), the best place to reach our team is via peer...@riotgames.com. Thanks! On Sat, Jun 6, 2015 at 10:35 AM, Alistair Mackenzie wrote: > Hi, > > Is there anyone on this list from Riot Games that can reach out to me? > > I'm having some issues with customers reaching your network. > > Thanks, > Alistair > -- *Trent Farrell* *Riot Games* *IP Network Engineer* E: tfarr...@riotgames.com | IE: +353 83 446 6809 | US: +1 424 285 9825 Summoner name: Foro
Re: Alcatel-Lucent 7750 Service Router (SR)
And if you ever need to find out what can commands exist for a certain string "xxx" tree flat detail | match xxx is a huge helper when learning. e.g. A:router# tree flat detail | match aspath-regex show router bgp routes [ [type ]] aspath-regex show router bgp routes [ []] aspath-regex On Thu, May 7, 2015 at 9:16 AM, Craig wrote: > yep.. its way easier and faster to take a look at what is configured: > > A:R01>config>service>vprn# interface "to-what-ever-eBGP" > A:R01>config>service>vprn>if# info > -- > description "L3 Ckt ID: " > enable-ingress-stats > cpu-protection 231 > address 299.299.299.299/30 > cflowd interface > ipv6 > address 2001::x::x/126 > exit > sap 1/1/2 create > cpu-protection 231 > ingress > filter ip 3356 > filter ipv6 3356 > flowspec > exit > exit > -- > > > > > > > > On Thu, May 7, 2015 at 12:08 PM, Chris Boyd > wrote: > > > > > > On May 6, 2015, at 5:24 PM, Colton Conor > wrote: > > > > > > I am worried as most tech's know Cisco and Juniper, so going to ALU > would > > > be a learning curve based on replies I am getting off list. > > > > It’s not that hard to learn if you know the basics of IP routing. I just > > did an implementation of A-L 7705 SAR 8s and 18s. Now I really wish that > > Cisco supported the “info” command. > > > > —Chris > > > > > -- *Trent Farrell* *Riot Games* *IP Network Engineer* E: tfarr...@riotgames.com | IE: +353 83 446 6809 | US: +1 424 285 9825 Summoner name: Foro
Re: 192.0.1.0/24?
Jump the slightest bit ahead in the library: https://tools.ietf.org/html/rfc5737 On Fri, Apr 17, 2015 at 1:14 PM, Harley H wrote: > Does anyone know the status of this netblock? I've come across a malware > sample configured to callback to an IP in that range but it does not appear > to be routable. Yet, it is not mentioned in RFC 5735 nor does it have any > whois information. > > Thanks, > Harley > -- *Trent Farrell* *Riot Games* *IP Network Engineer* E: tfarr...@riotgames.com | IE: +353 83 446 6809 | US: +1 424 285 9825 Summoner name: Foro
Re: Google served from non-google IPs?
^ my thought, they're on the QIX public block On Thu, Mar 12, 2015 at 1:00 PM, Stephen Fulton wrote: > Local Google caches at QIX? > > -- Stephen > > > On 2015-03-12 3:58 PM, Jason Lixfeld wrote: > >> So today, I saw this: >> >> BlackBox:~ jlixfeld$ host google.ca 8.8.8.8 >> Using domain server: >> Name: 8.8.8.8 >> Address: 8.8.8.8#53 >> Aliases: >> >> google.ca has address 206.126.112.166 >> google.ca has address 206.126.112.177 >> google.ca has address 206.126.112.172 >> google.ca has address 206.126.112.187 >> google.ca has address 206.126.112.151 >> google.ca has address 206.126.112.158 >> google.ca has address 206.126.112.157 >> google.ca has address 206.126.112.173 >> google.ca has address 206.126.112.181 >> google.ca has address 206.126.112.155 >> google.ca has address 206.126.112.147 >> google.ca has address 206.126.112.185 >> google.ca has address 206.126.112.143 >> google.ca has address 206.126.112.170 >> google.ca has address 206.126.112.162 >> google.ca has IPv6 address 2607:f8b0:4006:808::100f >> google.ca mail is handled by 50 alt4.aspmx.l.google.com. >> google.ca mail is handled by 30 alt2.aspmx.l.google.com. >> google.ca mail is handled by 20 alt1.aspmx.l.google.com. >> google.ca mail is handled by 10 aspmx.l.google.com. >> google.ca mail is handled by 40 alt3.aspmx.l.google.com. >> BlackBox:~ jlixfeld$ >> >> That is not Google IPv4 address space, and those IPv4 IPs are not being >> announced by 15169. >> >> Am I dumb in thinking that this is weird or is this sort of thing >> commonplace? >> >> -- *Trent Farrell* *Riot Games* *IP Network Engineer* E: tfarr...@riotgames.com | IE: +353 83 446 6809 | US: +1 424 285 9825 Summoner name: Foro
Re: Facebook outage?
https://twitter.com/LizardMafia/status/559963134006292481 On Mon, Jan 26, 2015 at 10:50 PM, Damien Burke wrote: > I hear that AIM and hipchat is also having issues. > > Any other major company down too? > > -Original Message- > From: John van Oppen [mailto:jvanop...@spectrumnet.us] > Sent: Monday, January 26, 2015 10:49 PM > To: Damien Burke; nanog@nanog.org > Subject: RE: Facebook outage? > > Dead here at AS11404 from all locations where we PNI or public peer... > > must be bad over there, v4 dies at their edge, v6 makes it in but no page > loads. > > John > -- *Trent Farrell* *Riot Games* *IP Network Engineer* E: tfarr...@riotgames.com | IE: +353 83 446 6809 | US: +1 424 285 9825 Summoner name: Foro
Re: gamer "lag" dashboard
Hi Michael, I don't have a direct answer to your question, nor can I speak for other gaming companies, but I can certainly work with you off-list on ways to monitor connectivity and performance to our game, "League of Legends". Hopefully also find some ways to optimise routing between our networks. Happy to assist any other network also - it's great to see gaming appearing on more and more radars. On Mon, Jan 19, 2015 at 2:10 PM, Michael O Holstein < michael.holst...@csuohio.edu> wrote: > ?Can someone point me in the right direction for something that allows > creation of a "dashboard" with current and statistical latency to the > various game servers (PC, Xbox, PS4, etc) ? .. I'm in the education space > and we get lots of questions/complains about this and would like a way to > make the stats public. > > > I could roll something with RRD and Smokeping but with all the > packet-shaping crapola (including that which we use here) I need something > that emulates the actual game traffic as would be classified by all the > network crap that endeavors to mess with it. > > > (not intended to be an argument about QoS and prioritization, responses > addressing either --or the politics thereof-- really aren't helpful). > > > TIA, > > > Michael Holstein > > Network & Data Security > > Cleveland State University > -- *tf*
Re: DDOS, IDS, RTBH, and Rate limiting
I wouldn't have suggested it if I hadn't successfully made these requests myself. Most attacks don't last long enough to put a dent on billing so it's in everyone best interest to cull it quickly. Providing the upstream network is big enough and your attacks aren't huge pipefills, they will usually place the acl on your customer port first, which in those cases should be enough. For smaller attacks you can try to drop at your router/absorb it/ scrub it inside your border if you have the kit - but anything significant like the NTP reflection attacks earlier in the year, you come up against the "bandwidth arms race" problem. There are services out there like Prolexic/Black Lotus offer where they can scrub traffic for you, but I've never used one first hand so can't comment. On Saturday, November 8, 2014, Jon Lewis wrote: > How many holes are you going to stick fingers in to stop the flows? Good > luck getting your provider to put in such a filter and make it anything > more than temporary...and then there's still DNS, NTP, SNMP, and other > protocols an attacker can easily utilize when they find that chargen isn't > getting the job done. > > On Sat, 8 Nov 2014, Trent Farrell wrote: > > A quick and dirty win is to get your upstream(s) to kill anything UDP 19 >> to >> your prefixes at their ingress points if it becomes a common thing. You >> lose visibility as to when you're getting targeted by that type of attack >> again though, which could matter depending on your network. >> >> >> On Saturday, November 8, 2014, Jon Lewis wrote: >> >> On Sat, 8 Nov 2014, Miles Fidelman wrote: >>> >>> Does anyone have any suggestions for mitigating these type of attacks? >>> >>>> >>>>> >>>> The phrase automated offensive cyber counter-attack has been coming to >>>> mind rather frequently, of late. I wonder if DARPA might fund some >>>> work in >>>> this area. :-) >>>> >>>> >>> When you're being hit with one of the UDP reflection DDoS's, attacking >>> the >>> world in response isn't likely to work too well. >>> >>> In theory, you could write something that takes flow data from your >>> transit routers, and in either near or real time, looks at that data and >>> triggers an RTBH route for any IP that is responsible for more than a >>> certain defined threshold of inbound traffic. In practice, it gets a >>> little more complicated than that, as you'll likely want to whitelist >>> some >>> IPs and/or maybe be able to set different thresholds for different IPs. >>> But >>> it's not that complicated a problem to solve. Have a default threshold, >>> and a table of networks and thresholds. Once a minute, look at the top X >>> local destinations over the past minute. For each one, check to see if >>> it >>> has a custom threshold. If it doesn't, it gets the default. Then see if >>> it's over its threshold. If it is, generate an RTBH route and email your >>> NOC. >>> >>> The tricky part is when to remove the route...since you can't tell if the >>> attack has ended while the target is black holed by your upstreams. >>> >>> -- >>> Jon Lewis, MCP :) | I route >>> | therefore you are >>> _ http://www.lewis.org/~jlewis/pgp for PGP public key_ >>> >>> >> >> -- >> >> *Trent Farrell* >> >> *Riot Games* >> >> *IP Network Engineer* >> >> E: tfarr...@riotgames.com | IE: +353 83 446 6809 | US: +1 424 285 9825 >> >> Summoner name: Foro >> >> > -- > Jon Lewis, MCP :) | I route > | therefore you are > _ http://www.lewis.org/~jlewis/pgp for PGP public key_ > -- *Trent Farrell* *Riot Games* *IP Network Engineer* E: tfarr...@riotgames.com | IE: +353 83 446 6809 | US: +1 424 285 9825 Summoner name: Foro
Re: DDOS, IDS, RTBH, and Rate limiting
A quick and dirty win is to get your upstream(s) to kill anything UDP 19 to your prefixes at their ingress points if it becomes a common thing. You lose visibility as to when you're getting targeted by that type of attack again though, which could matter depending on your network. On Saturday, November 8, 2014, Jon Lewis wrote: > On Sat, 8 Nov 2014, Miles Fidelman wrote: > > Does anyone have any suggestions for mitigating these type of attacks? >>> >> >> The phrase automated offensive cyber counter-attack has been coming to >> mind rather frequently, of late. I wonder if DARPA might fund some work in >> this area. :-) >> > > When you're being hit with one of the UDP reflection DDoS's, attacking the > world in response isn't likely to work too well. > > In theory, you could write something that takes flow data from your > transit routers, and in either near or real time, looks at that data and > triggers an RTBH route for any IP that is responsible for more than a > certain defined threshold of inbound traffic. In practice, it gets a > little more complicated than that, as you'll likely want to whitelist some > IPs and/or maybe be able to set different thresholds for different IPs. But > it's not that complicated a problem to solve. Have a default threshold, > and a table of networks and thresholds. Once a minute, look at the top X > local destinations over the past minute. For each one, check to see if it > has a custom threshold. If it doesn't, it gets the default. Then see if > it's over its threshold. If it is, generate an RTBH route and email your > NOC. > > The tricky part is when to remove the route...since you can't tell if the > attack has ended while the target is black holed by your upstreams. > > -- > Jon Lewis, MCP :) | I route > | therefore you are > _ http://www.lewis.org/~jlewis/pgp for PGP public key_ > -- *Trent Farrell* *Riot Games* *IP Network Engineer* E: tfarr...@riotgames.com | IE: +353 83 446 6809 | US: +1 424 285 9825 Summoner name: Foro
Re: Vendor cert levels
^^ It really helps if you're a Cisco shop to have CCIEs. Every place I've worked has offered to refund the cost of a cert after you pass (if the employee fails, the cost is on them), and it's had a pretty decent uptake among the more junior staff - as well as the CCIE re-certs. I'm not sure if Juniper have a similar type system of rewarding partners that are packed with certified engineers, but I wouldn't be surprised if they did. On Wed, Sep 3, 2014 at 12:23 PM, Jared Mauch wrote: > >> On Sep 3, 2014, at 5:00 AM, Isaac Adams wrote: >> >> Hey Folks, >> >> I am trying to work out a strategy for vendor certification in our company. >> As a general rule, do you all fund employees certification and if so what >> kind of levels do you try to maintain as good practice? >> >> For example. NOC staff should be JNCIA and engineering JNCIP to JNCIE? >> >> Clearly certification does not usually reflect ability but it does help >> people feel valued and to maintain a basic level of competence. > > Cisco discriminates against customers without certification and delays > service and support to them as a result. (e.g.: you can’t open a sev 1 case > online unless you are “CCIE”). > > You likely want to have someone with this access in their account to speed > access when there are network critical issues. > > - Jared -- Trent Farrell Riot Games IP Network Engineer E: tfarr...@riotgames.com | IE: +353 83 446 6809 | US: +1 424 285 9825 Summoner name: Foro
Re: Verizon Public Policy on Netflix
Similar but much smaller scale issue that I'm having trying to deliver our content to access networks - small amount of traffic, heavily skewed outbound from our AS but massive amounts of players on these access networks - yet we're forced to pay said access networks to deliver our mutual customers for an optimal experience. So much double dipping. On Thursday, July 10, 2014, Matthew Petach wrote: > On Thu, Jul 10, 2014 at 6:40 PM, Miles Fidelman < > mfidel...@meetinghouse.net > > wrote: > > > Jimmy Hess wrote: > > > >> On Thu, Jul 10, 2014 at 8:12 PM, Miles Fidelman > >> > wrote: > >> > >>> Randy Bush wrote: > >>> > >> [snip] > >> > >>> At the ISPs expense, including connectivity to a peering point. Most > >>> content > >>> providers pay Akamai, Netflix wants ISPs to pay them. Hmmm > >>> > >> Netflix own website indicates otherwise. > >> https://www.netflix.com/openconnect > >> > >> "ISPs can directly connect their networks to Open Connect for free. > >> ISPs can do this either by free peering with us at common Internet > >> exchanges, or can save even more transit costs by putting our free > >> storage appliances in or near their network." > >> > >> > >> From another list, I think this puts it nicely (for those of you who > > don't know Brett, he's been running a small ISP for years > > http://www.lariat.net/) > > > > > > > > > > At 02:42 PM 7/10/2014, Jay Ashworth wrote: > > > > Netflix's only fault is being popular. > >> > > > > Alas, as an ISP who cares about his customers, I must say that this is > not > > at all the case. > > > > Netflix generates huge amounts of wasteful, redundant traffic and then > > refuses to allow ISPs to correct this inefficiency via caching. > > > I'm sorry. You cannot take that sentence... > > > > It fails to provide adequate bandwidth for its traffic to ISPs' "front > > doors" and then blames their downstream networks when in fact they are > more > > than adequate. It exercises market power over ISPs (one of the first > > questions asked by every customer who calls us is, "How well do you > stream > > Netflix?") in an attempt to force them to host their servers for free > > > ...together with this sentence, without hitting a WTF > moment. > > He rants about Netflix generating huge amounts of traffic > and refusing to allow ISPs to cache it; and then goes on to > grumble that Netflix is trying to force them to host caching > boxes. Does he love caching, or hate caching? I really > can't tell. Netflix is offering to provide you the cache boxes > *for FREE* so that you can cache the data in your network; > isn't that exactly what he wanted, in his first sentence? > Why is it that two sentences later, free Netflix cache boxes > are suddenly an evil that must be avoided, no matter how > much Netflix may try to force them on you? > > I'm sorry. I think someone forgot to take their coherency > meds before writing that paragraph. > > If you like caching, you should be happy when someone > offers to give you caching boxes for FREE. If you don't > like caching, you shouldn't bitch about inefficient it is to > have traffic that isn't being cached. > > Trying to play both sides of the issue like that in the > same paragraph is just...dizzying. > > Matt > -- *Trent Farrell* *Riot Games* *IP Network Engineer* E: tfarr...@riotgames.com | IE: +353 83 446 6809 | US: +1 424 285 9825 Summoner name: Foro
