Re: Google Apps for ISPs -- Lingering fallout

You’ll need to escalate this with Google. If the front-end support team cannot help, move up the chain as far as you can. It should eventually reach the PM that worked on the turn-down of that service and get some action. -- Gary L. Greene, Jr. Sr. Systems Administrator IT Operations Minerva Net

Re: Peering + Transit Circuits

Thank you to everyone who has offered different explanations.. Yes, all it take is one party pooper to spoil a good party... So now the question is (public or private) what is the best practices to protect the network ? :) Faisal Imtiaz Snappy Internet & Telecom - Original Message -

Re: Peering + Transit Circuits

On Tue, Aug 18, 2015 at 11:27:53PM +, Faisal Imtiaz wrote: > Thanks for the explanation, > I am still trying to figure out the realistic business case where > doing something like this would make sense to any party. > (unless purely malicious or in error). I'm sure others will reply as well

Re: Peering + Transit Circuits

Hi Bob, Your point is completely understood... so the next question becomes what are these best practices methods ? :) Faisal Imtiaz Snappy Internet & Telecom Help-desk: (305)663-5518 Option 2 or Email: supp...@snappytelecom.net - Original Message - > From: "Bob Evans" > To: "Faisal Im

Re: Peering + Transit Circuits

On Aug 18, 2015, at 7:26 PM, Faisal Imtiaz wrote: > > Thank you for the explanation.. > > However wouldn't a few other other attributes of the traffic show up . > e.g. you would have asymmetric traffic.. going out via us, but coming back > via a totally another path ? So? If I am a content pr

Re: Peering + Transit Circuits

Thank You Bob Evans CTO > Thank you for the explanation.. > > However wouldn't a few other other attributes of the traffic show up . > e.g. you would have asymmetric traffic.. going out via us, but coming > back via a totally another path ? Patrick is correct in the approach you should take. I

Re: Peering + Transit Circuits

Thanks for the explanation, I am still trying to figure out the realistic business case where doing something like this would make sense to any party. (unless purely malicious or in error). Regards Faisal Imtiaz Snappy Internet & Telecom > From: "Pshem Kowalczyk" > To: "Faisal Imtiaz" ,

Re: Peering + Transit Circuits

Thank you for the explanation.. However wouldn't a few other other attributes of the traffic show up . e.g. you would have asymmetric traffic.. going out via us, but coming back via a totally another path ? BTW, my comment "We will trust everything coming in" was in ref. to QOS tags. How

Re: Peering + Transit Circuits

Assume you and I are at an IX and peer. Suppose I send you traffic for Comcast. I can do this, even if you do not send me prefixes for Comcast. It requires me to manually configure things, but I can do it. Put another way, you said "We will trust everything coming in”. I am saying that perhaps

Re: Peering + Transit Circuits

On 18 August 2015 at 14:29, Tim Durack wrote: > 4. Don't worry about peers stealing transit. > Because both of our transit providers implement source filters. Any packets received with a source IP not in the list of IP ranges registered by us will be dropped by the transit provider. Stealing tra

Re: Peering + Transit Circuits

It's actually quite easy. Provider1 is present at Exchange1 and Exchange2, so is Provider2. Provider2 doesn't want to pay for the traffic between Exchange1 and Exchange2, so it points a static route for all prefixes it has in Exchange2 via Provider1's IP address in Exchange1 and does the same in Ex

Re: Peering + Transit Circuits

Let me start backwards... To me 'peering' is sharing internal routes and downstream customer routes,and not external ones. IP transit is all of the external routes including internal routes & downstream customer routes Having said that. if one is control of what IP Prefixes get advert

Re: [c-nsp] Peering + Transit Circuits

Why do I read this thread as “Peering + Transit Circus” manning bmann...@karoshi.com PO Box 6151 Playa del Rey, CA 90296 310.322.8102 On 18August2015Tuesday, at 6:01, Jared Mauch wrote: > >> On Aug 18, 2015, at 8:47 AM, Gert Doering wrote: >> >> XR doesn't do it at all, >> hrmph) >>

Re: Data Center operations mail list?

I actually suggested this to Chris while discussing what to have in the website, I definitely think it would be nice to have a platform to help plan and schedule local events for social and networking purposes. I am working with a few people on designing a website, so I am guessing some time in Se

Re: A multi-tenant firewall for an MSSP

On 18 Aug 2015, at 20:48, J. Oquendo wrote: > On Tue, 18 Aug 2015, Blake Dunlap wrote: > >> Since no one else has mentioned it, I'll dive on that fire. >> >> Be careful when setting up a multi-tenant security solution that you >> are not accidentally selling "DoS as a Service" to your clients.

Re: [c-nsp] Peering + Transit Circuits

On Tue, Aug 18, 2015 at 4:43 PM, Nick Hilliard wrote: > On 18/08/2015 20:22, Tim Durack wrote: >> This has always been my understanding - thanks for confirming. I'm weighing >> cost-benefit, and looking to see if there are any other smart ideas. As >> usual, it looks like simplest is best. > > i'd

Re: [c-nsp] Peering + Transit Circuits

On 18/08/2015 21:56, Gert Doering wrote: > So how's that stopping one of your bilateral peers from sending you > traffic destined elsewhere? it doesn't: you detect it and depeer them. If they force the situation with static routes, the traffic will be dropped. Nick

Re: rDNS delegation process question

On 8/18/15, 3:53 PM, "Jake Mertel" wrote: >Someone needs to update the delegation at ARIN since they are the >authoritative root for 69/8. >http://whois.arin.net/rest/rdns/223.26.69.in-addr.arpa shows that the >current nameservers are OAK.FOREST.NET and >WILLOW.FOREST.NET

Re: [c-nsp] Peering + Transit Circuits

On 18/08/2015 20:22, Tim Durack wrote: > This has always been my understanding - thanks for confirming. I'm weighing > cost-benefit, and looking to see if there are any other smart ideas. As > usual, it looks like simplest is best. i'd advise being careful with this approach: urpf at ixps is a nig

Re: rDNS delegation process question

Someone needs to update the delegation at ARIN since they are the authoritative root for 69/8. http://whois.arin.net/rest/rdns/223.26.69.in-addr.arpa shows that the current nameservers are OAK.FOREST.NET and WILLOW.FOREST.NET. If I recall correctly, the ARIN Online interface allows the registered a

Re: A multi-tenant firewall for an MSSP

On Tue, 18 Aug 2015, Blake Dunlap wrote: > Since no one else has mentioned it, I'll dive on that fire. > > Be careful when setting up a multi-tenant security solution that you > are not accidentally selling "DoS as a Service" to your clients. State > is evil, and state sharing with other targets

rDNS delegation process question

At $DAYJOB we have a /24 of PA space that we were allocated by Airband, and when the account was set up they delegated authoritative reverse DNS to our DNS hosting provider. This is 69.26.223.0/24, in ARIN address space. Now, almost a decade later Airband has been acquired by somebody or other who

Re: A multi-tenant firewall for an MSSP

Since no one else has mentioned it, I'll dive on that fire. Be careful when setting up a multi-tenant security solution that you are not accidentally selling "DoS as a Service" to your clients. State is evil, and state sharing with other targets is dangerous. Target sharing with other targets that

Re: Peering + Transit Circuits

On Tue, Aug 18, 2015 at 1:29 PM, Patrick W. Gilmore wrote: > On Aug 18, 2015, at 1:24 PM, William Herrin wrote: > > On Tue, Aug 18, 2015 at 8:29 AM, Tim Durack wrote: > > >> Question: What is the preferred practice for separating peering and > transit > >> circuits? > >> > >> 1. Terminate peeri

Google Apps for ISPs -- Lingering fallout

I know there are others on this list who used Google Apps for ISPs and recently migrated off (as the service was discontinued). We have had several cases where the user had a YouTube channel or Picasa photo albums, etc. that they created with their Google Apps for ISPs credentials. Now that

Re: A multi-tenant firewall for an MSSP

On Mon, Aug 17, 2015 at 7:46 AM, Ramy Hashish wrote: > Hello All, > > We are planning to implement a multi-tenant FW/UTM and start providing > security as a service, I would like to hear if anybody had experience on > this, and if there are any recommendations for the UTM's vendor. > Check Point

Re: Peering + Transit Circuits

On Aug 18, 2015, at 1:24 PM, William Herrin wrote: > On Tue, Aug 18, 2015 at 8:29 AM, Tim Durack wrote: >> Question: What is the preferred practice for separating peering and transit >> circuits? >> >> 1. Terminate peering and transit on separate routers. >> 2. Terminate peering and transit cir

Re: Peering + Transit Circuits

On Tue, Aug 18, 2015 at 8:29 AM, Tim Durack wrote: > Question: What is the preferred practice for separating peering and transit > circuits? > > 1. Terminate peering and transit on separate routers. > 2. Terminate peering and transit circuits in separate VRFs. > 3. QoS/QPPB ( > https://www.nanog.o

Re: A perl script to find IP and network addresses in a text file (config, ACL, etc) and annotate them with various bits of information

Sweet! Ill try this out this week for a similar router migration project I have. From: NANOG on behalf of Jesse McGraw Sent: Tuesday, August 18, 2015 10:04 AM To: nanog@nanog.org Subject: A perl script to find IP and network addresses in a text file (con

A perl script to find IP and network addresses in a text file (config, ACL, etc) and annotate them with various bits of information

(This is me scratching an itch of my own and hoping that it might be useful to others on this list. Apologies if it isn't) All, I was working my way through a very long ACL, trying to clean out old cruft, and I found myself thinking that surely I could make this somewhat easier. So, I wr

Re: [c-nsp] Peering + Transit Circuits

On Tue, Aug 18, 2015 at 11:25 AM, Scott Granados wrote: > So in our case we terminate peering and transit on different routers. > Peering routers have well flow enabled (the one that starts with a J that’s > inline). With NFSEN / NFDUMP we’re able to collect that flow data and look > for anomalo

Fwd: [c-nsp] Peering + Transit Circuits

-- Forwarded message -- From: Tim Durack Date: Tue, Aug 18, 2015 at 9:53 AM Subject: Re: [c-nsp] Peering + Transit Circuits To: Rolf Hanßen Cc: "cisco-...@puck.nether.net" On Tue, Aug 18, 2015 at 9:45 AM, "Rolf Hanßen" wrote: > Hi, > > you forgot "do some interface-ACL-magic

Re: [c-nsp] Peering + Transit Circuits

On Tue, Aug 18, 2015 at 9:38 AM, Gert Doering wrote: > Hi, > > On Tue, Aug 18, 2015 at 09:32:53AM -0400, Tim Durack wrote: > > > (It would be cool if Cisco would understand that hardware forwarding > > > platforms need useful netflow with MAC-addresses in there... ASR9k at > [..] > > At the risk

Re: Data Center operations mail list?

On Thu, Aug 13, 2015 at 08:36:24AM +0800, Phill Twiss wrote: > You should really have captcha's configured for your mailman lists No. In fact: hell no. Captchas have zero security value and serve only to annoy and waste the time of legitimate users. Far less intrusive and more effective m

Re: [c-nsp] Peering + Transit Circuits

On Tue, Aug 18, 2015 at 8:47 AM, Gert Doering wrote: > Hi, > > (It would be cool if Cisco would understand that hardware forwarding > platforms need useful netflow with MAC-addresses in there... ASR9k at > least got working MAC-accounting, but more fine grained telemetry would > certainly be app

Re: [c-nsp] Peering + Transit Circuits

On Tue, Aug 18, 2015 at 8:47 AM, Gert Doering wrote: > Hi, > > On Tue, Aug 18, 2015 at 08:29:31AM -0400, Tim Durack wrote: > > 4. Don't worry about peers stealing transit. > > 5. What is peering? > > I'm afraid that the majority of answers will be 4./5., mixed with > "6. what? how can peers stell

Re: [c-nsp] Peering + Transit Circuits

> On Aug 18, 2015, at 8:47 AM, Gert Doering wrote: > > XR doesn't do it at all, > hrmph) > We have been asking about this as well, it might be worth revisiting. - Jared

Peering + Transit Circuits

Question: What is the preferred practice for separating peering and transit circuits? 1. Terminate peering and transit on separate routers. 2. Terminate peering and transit circuits in separate VRFs. 3. QoS/QPPB ( https://www.nanog.org/meetings/nanog42/presentations/DavidSmith-PeeringPolicyEnforce