Re: [c-nsp] Peering + Transit Circuits
On Aug 18, 2015, at 8:47 AM, Gert Doering g...@greenie.muc.de 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-PeeringPolicyEnforcement.pdf ) 4. Don't worry about peers stealing transit. 5. What is peering? Your comments are appreciated. -- Tim:
Re: A multi-tenant firewall for an MSSP
On Mon, Aug 17, 2015 at 7:46 AM, Ramy Hashish ramy.ihash...@gmail.com 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 VS might be a good fit. Also there is McAfee NGFW that can be used as a multi-tenant solution. Other solutions are Fortigate (what you mentioned), ASA w/ contexts (not sure about UTM support in contexts though). People/customers here are more familiar with the Fortigate, however, we need to build a well-rounded solution that suits wide range of enterprises' business needs. I think that you first define what the most wanted needs of your clients are and work from that.
Re: Peering + Transit Circuits
On Aug 18, 2015, at 1:24 PM, William Herrin b...@herrin.us wrote: On Tue, Aug 18, 2015 at 8:29 AM, Tim Durack tdur...@gmail.com 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.org/meetings/nanog42/presentations/DavidSmith-PeeringPolicyEnforcement.pdf ) 4. Don't worry about peers stealing transit. 5. What is peering? Your comments are appreciated. If you have a small number of peers, a separate router carrying a partial table works really well. To expand on this, and answer Tim’s question one post up in the thread: Putting all peer routes on a dedicated router with a partial table avoids the “steal transit” question. The Peering router can only speak to peers and your own network. Anyone dumping traffic on it will get !N (unless they are going to a peer, which is a pretty minimal risk). It has lots of other useful features such as network management and monitoring. It lets you do maintenance much easier. Etc., etc. But mostly, it lets you avoid joining an IX and having people use you as a backup transit provider. -- TTFN, patrick
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 the service is gone, those channels and albums still exist but the users are unable to login to them or manage them in any way because it tells them that their account has been disabled. Of course, Google had been un-responsive to all of our (and the customer's) inquiries about how to fix this. Has anyone else run into this and found a way around it? thanks Shawn
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 wrote a small script that will go through a text file(or files), find anything that looks like a host IP or subnet (with subnet mask, wildcard mask, or mask length), dig up information about them (DNS name, ping responsiveness, host count etc) and then spit out an HTML version of the input file with color coded info. General info is blue Hosts that are reachable and networks that have a specific route are GREEN (see networks note below) Hosts that are non-responsive and networks that use default route are RED Individual script is: https://github.com/jlmcgraw/networkUtilities/blob/master/annotate_hosts_and_networks_in_file.pl Repository is: https://github.com/jlmcgraw/networkUtilities To get the whole repository: git clone https://github.com/jlmcgraw/networkUtilities.git This repository includes the necessary modules for this script and some other small utilities that network folks might be interested in (If for some reason included modules don't work for you see setup.sh for easy ways to install them under Debian-derived Linux. I've tested the script under Linux and Windows, but not OS X) Please let me know if you use this utility and encounter anything that doesn't work right. I'm also interested in incorporating any changes/improvements so feel free to send a pull request! -Jesse Note: If you've got a BGP speaking router that you can query via SNMP, you should be able to use bgp_asn_path_via_snmp.pl https://github.com/jlmcgraw/networkUtilities/blob/master/bgp_asn_path_via_snmp.pl to create a table of known routes to use along with this utility
Re: Peering + Transit Circuits
On Tue, Aug 18, 2015 at 8:29 AM, Tim Durack tdur...@gmail.com 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.org/meetings/nanog42/presentations/DavidSmith-PeeringPolicyEnforcement.pdf ) 4. Don't worry about peers stealing transit. 5. What is peering? Your comments are appreciated. If you have a small number of peers, a separate router carrying a partial table works really well. -- William Herrin her...@dirtside.com b...@herrin.us Owner, Dirtside Systems . Web: http://www.dirtside.com/
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 nanog-boun...@nanog.org on behalf of Jesse McGraw jlmcg...@gmail.com 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 (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 wrote a small script that will go through a text file(or files), find anything that looks like a host IP or subnet (with subnet mask, wildcard mask, or mask length), dig up information about them (DNS name, ping responsiveness, host count etc) and then spit out an HTML version of the input file with color coded info. General info is blue Hosts that are reachable and networks that have a specific route are GREEN (see networks note below) Hosts that are non-responsive and networks that use default route are RED Individual script is: https://github.com/jlmcgraw/networkUtilities/blob/master/annotate_hosts_and_networks_in_file.pl Repository is: https://github.com/jlmcgraw/networkUtilities To get the whole repository: git clone https://github.com/jlmcgraw/networkUtilities.git This repository includes the necessary modules for this script and some other small utilities that network folks might be interested in (If for some reason included modules don't work for you see setup.sh for easy ways to install them under Debian-derived Linux. I've tested the script under Linux and Windows, but not OS X) Please let me know if you use this utility and encounter anything that doesn't work right. I'm also interested in incorporating any changes/improvements so feel free to send a pull request! -Jesse Note: If you've got a BGP speaking router that you can query via SNMP, you should be able to use bgp_asn_path_via_snmp.pl https://github.com/jlmcgraw/networkUtilities/blob/master/bgp_asn_path_via_snmp.pl to create a table of known routes to use along with this utility
Re: Peering + Transit Circuits
On Tue, Aug 18, 2015 at 1:29 PM, Patrick W. Gilmore patr...@ianai.net wrote: On Aug 18, 2015, at 1:24 PM, William Herrin b...@herrin.us wrote: On Tue, Aug 18, 2015 at 8:29 AM, Tim Durack tdur...@gmail.com 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.org/meetings/nanog42/presentations/DavidSmith-PeeringPolicyEnforcement.pdf ) 4. Don't worry about peers stealing transit. 5. What is peering? Your comments are appreciated. If you have a small number of peers, a separate router carrying a partial table works really well. To expand on this, and answer Tim’s question one post up in the thread: Putting all peer routes on a dedicated router with a partial table avoids the “steal transit” question. The Peering router can only speak to peers and your own network. Anyone dumping traffic on it will get !N (unless they are going to a peer, which is a pretty minimal risk). It has lots of other useful features such as network management and monitoring. It lets you do maintenance much easier. Etc., etc. But mostly, it lets you avoid joining an IX and having people use you as a backup transit provider. 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. -- Tim: p.s. Perhaps I should be relieved no one tried to sell me an SDN peering transit theft controller...
Re: [c-nsp] Peering + Transit Circuits
On Tue, Aug 18, 2015 at 4:43 PM, Nick Hilliard n...@foobar.org 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 advise being careful with this approach: urpf at ixps is a nightmare. Hi Nick, This technique described isn't URPF, it's simple destination routing. The routes I offer you via BGP are the only routes in my table, hence the only routes I'm capable of routing. If you send me a packet for a _destination_ I didn't offer to you, I can't route it. URPF is the opposite of that. I'll only accept packets from you with a _source_ address which is included in the routes you sent to me. Regards, Bill Herrin -- William Herrin her...@dirtside.com b...@herrin.us Owner, Dirtside Systems . Web: http://www.dirtside.com/
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 September we will have this in place. On Sun, Aug 16, 2015 at 2:33 PM, Idafe Houghton idafe.hough...@gmail.com wrote: While I am recent incorporation, have you ever thought about organizing a few meetups? I am not from America, but there has been a boom recently, on a few cities around the world striving to make a global linked community network of techlabs. Probably, it isn't suited for this community mailing-list, that is pretty specialized, but just saying. I have been lately interested in these forms of communication, knowledge and experience sharing. My tips. On dom, ago 16, 2015 at 9:22 , Chris Boyd cb...@gizmopartners.com wrote: On Aug 15, 2015, at 12:13 PM, Martin Hannigan hanni...@gmail.com wrote: There is reasonable demand for a forum. It might need a little marketing to get a list with traction going. There seems to be some traction, with 268 members on the NADCOG list so far. —Chris
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 ja...@puck.nether.net wrote: On Aug 18, 2015, at 8:47 AM, Gert Doering g...@greenie.muc.de wrote: XR doesn't do it at all, hrmph) We have been asking about this as well, it might be worth revisiting. - Jared
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 was in turn acquired by GTT.net; we're trying to move our rDNS to Route53 and nobody at GTT.net seems to know how they would go about changing that rDNS delegation. My involvement with the process back in the day was limited to provide Airband with the name servers we would like to be authoritative for the reverse DNS and wait about 12 hours for them to handle the ticket. Now I'm trying to help my GTT contact get pointed in the right direction, and any assistance would be appreciated. -- Dave Pooser Cat-Herder-in-Chief, Pooserville.com
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 administrative and technical POC to make these adjustments directly from the interface. As it stands right now, it would appear that whomever has access to net...@alfordmedia.com,. n...@airband.com, or an associated POC would need to use the appropriate ARIN template or interface to make the change. -- Regards, Jake Mertel Nobis Technology Group, LLC *Web: *http://www.nobistech.net *Phone: *1-480-212-1710 *Mail:* 5350 East High Street, Suite 300, Phoenix, AZ 85054 On Tue, Aug 18, 2015 at 12:50 PM, Dave Pooser dave-na...@pooserville.com wrote: 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 was in turn acquired by GTT.net; we're trying to move our rDNS to Route53 and nobody at GTT.net seems to know how they would go about changing that rDNS delegation. My involvement with the process back in the day was limited to provide Airband with the name servers we would like to be authoritative for the reverse DNS and wait about 12 hours for them to handle the ticket. Now I'm trying to help my GTT contact get pointed in the right direction, and any assistance would be appreciated. -- Dave Pooser Cat-Herder-in-Chief, Pooserville.com
Re: rDNS delegation process question
On 8/18/15, 3:53 PM, Jake Mertel j...@nobistech.net 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 http://OAK.FOREST.NET and WILLOW.FOREST.NET http://WILLOW.FOREST.NET. If I recall correctly, the ARIN Online interface allows the registered administrative and technical POC to make these adjustments directly from the interface. As it stands right now, it would appear that whomever has access to net...@alfordmedia.com,. n...@airband.com, or an associated POC would need to use the appropriate ARIN template or interface to make the change. That definitely gets me pointed in the right direction. Tasty $BEVERAGE, I owe you a few... -- Dave Pooser Cat-Herder-in-Chief, Pooserville.com
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: 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 is dangerous. Target sharing with other targets that are outsourcing their security can get increasingly scary especially if one of these clients is a juicy target. Make sure you have the infrastructure in place to quickly isolate your clients so that they do not fate share if they become in the focus of DoS attacks. This can mean isolated infrastructure for those you wish to keep up, or sacrificial infrastructure for those you are willing to let drop for the greater good. -Blake Unsure what you meant by this. In a multi-tenant firewall implementation (as far as I envision it), all tenants would occupy different IP space so I don't get how any of the state sessions would be affected. I'd be more concerned with not enough sockets. Palo Alto has a virtual system set up built specifically for this: https://www.paloaltonetworks.com/products/features/virtual-systems.html Now if only they'd send me free firewalls for marketing them. -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT, RWSP, GREM Where ignorance is our master, there is no possibility of real peace - Dalai Lama 0B23 595C F07C 6092 8AEB 074B FC83 7AF5 9D8A 4463 https://pgp.mit.edu/pks/lookup?op=getsearch=0xFC837AF59D8A4463
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 nightmare. If you're concerned about transit / peering theft on a shared l2 ixp style fabric, you're far better to use bilateral-only peering with ingress l2 filters at the ixp interface to include or exclude other participants as required. This will stop the problem dead in the water with no side effects. Nick
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 advertised to whom... how exactly someone (peers) 'steal' transit ? (If one is not managing the filters well then yes it is possible, but that would be a configuration error ?) Maybe I am naive, to my Peering routes (relationships) are a subset of IP Transit Routes (relationships) Based on above belief... Then Item # 3, becomes the choice of the OP where one can make one of two starting assumptions... We will trust everything coming in and change what we don't like... or We will not trust anything coming in, and change (accept) what we like. Items # 1 2, would be a function of network design, technical requirements (maintenance window) etc etc.. easier to deal with a distributed edge vs all in one when one has to bring anything down for any reason.. I am open to learning and being corrected if any of the above is wrong ! Faisal Imtiaz Snappy Internet Telecom - Original Message - From: Tim Durack tdur...@gmail.com To: cisco-...@puck.nether.net, nanog list nanog@nanog.org Sent: Tuesday, August 18, 2015 8:29:31 AM Subject: 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-PeeringPolicyEnforcement.pdf ) 4. Don't worry about peers stealing transit. 5. What is peering? Your comments are appreciated. -- Tim:
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 Networks, Inc. Cell: +1 (650) 704-6633 On Aug 18, 2015, at 10:39 AM, Shawn L sha...@up.net wrote: 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 the service is gone, those channels and albums still exist but the users are unable to login to them or manage them in any way because it tells them that their account has been disabled. Of course, Google had been un-responsive to all of our (and the customer's) inquiries about how to fix this. Has anyone else run into this and found a way around it? thanks Shawn
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 - From: John Osmon jos...@rigozsaurus.com To: nanog list nanog@nanog.org Sent: Tuesday, August 18, 2015 8:30:45 PM Subject: 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, but in case it helps someone googling in years to come... Let's look at ParasiteNet, a content heavy network with three BGP peerings: - Transit provider A via 100Mbps - Transit provider B via 100Mbps - Peer P via 1GBps (who also buys from provider B at 10G) If ParasiteNet needed to push more than 100Mbps to provider B, they might be tempted to route the traffic to peer P, even though peer P didn't advertise those routes. ParasiteNet gets a free ride if peer P doesn't notice what is going on (until they need more than 100Mbps inbound). I've been told of an occurance of this when a private network started peering with an edu network. Once the link was up, an absurd amount of traffic went across the link -- all destined for the Internet rather than the edu network. When the edu network shutdown the link, they were threatened with lawsuits...
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 are outsourcing their security can get increasingly scary especially if one of these clients is a juicy target. Make sure you have the infrastructure in place to quickly isolate your clients so that they do not fate share if they become in the focus of DoS attacks. This can mean isolated infrastructure for those you wish to keep up, or sacrificial infrastructure for those you are willing to let drop for the greater good. -Blake On Tue, Aug 18, 2015 at 10:38 AM, Eugeniu Patrascu eu...@imacandi.net wrote: On Mon, Aug 17, 2015 at 7:46 AM, Ramy Hashish ramy.ihash...@gmail.com 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 VS might be a good fit. Also there is McAfee NGFW that can be used as a multi-tenant solution. Other solutions are Fortigate (what you mentioned), ASA w/ contexts (not sure about UTM support in contexts though). People/customers here are more familiar with the Fortigate, however, we need to build a well-rounded solution that suits wide range of enterprises' business needs. I think that you first define what the most wanted needs of your clients are and work from that.
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 pshe...@gmail.com To: Faisal Imtiaz fai...@snappytelecom.net, Tim Durack tdur...@gmail.com Cc: nanog list nanog@nanog.org, cisco-...@puck.nether.net Sent: Tuesday, August 18, 2015 7:00:35 PM Subject: 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 Exchange2. Provider1's router receives traffic, checks where it should go (Exchange2) and it forwards the traffic. So the traffic flows like this: Provider2 (Exchange1) - Provider1 - (Exchange2) Provider2, all due to static routes. kind regards Pshem On Wed, 19 Aug 2015 at 10:38 Faisal Imtiaz fai...@snappytelecom.net wrote: 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 advertised to whom... how exactly someone (peers) 'steal' transit ? (If one is not managing the filters well then yes it is possible, but that would be a configuration error ?) Maybe I am naive, to my Peering routes (relationships) are a subset of IP Transit Routes (relationships) Based on above belief... Then Item # 3, becomes the choice of the OP where one can make one of two starting assumptions... We will trust everything coming in and change what we don't like... or We will not trust anything coming in, and change (accept) what we like. Items # 1 2, would be a function of network design, technical requirements (maintenance window) etc etc.. easier to deal with a distributed edge vs all in one when one has to bring anything down for any reason.. I am open to learning and being corrected if any of the above is wrong ! Faisal Imtiaz Snappy Internet Telecom - Original Message - From: Tim Durack tdur...@gmail.com To: cisco-...@puck.nether.net , nanog list nanog@nanog.org Sent: Tuesday, August 18, 2015 8:29:31 AM Subject: 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-PeeringPolicyEnforcement.pdf ) 4. Don't worry about peers stealing transit. 5. What is peering? Your comments are appreciated. -- Tim:
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, but in case it helps someone googling in years to come... Let's look at ParasiteNet, a content heavy network with three BGP peerings: - Transit provider A via 100Mbps - Transit provider B via 100Mbps - Peer P via 1GBps (who also buys from provider B at 10G) If ParasiteNet needed to push more than 100Mbps to provider B, they might be tempted to route the traffic to peer P, even though peer P didn't advertise those routes. ParasiteNet gets a free ride if peer P doesn't notice what is going on (until they need more than 100Mbps inbound). I've been told of an occurance of this when a private network started peering with an edu network. Once the link was up, an absurd amount of traffic went across the link -- all destined for the Internet rather than the edu network. When the edu network shutdown the link, they were threatened with lawsuits...
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 you should not. As Comcast is not one of your customers, you will have to send the packets out your transit provider. You do not get paid when I give you the packets, and you probably pay your transit provider to get to Comcast. So I have gotten something for free, and you are paying for it - i.e. stealing. Normally a router gets a packet and sends it on its way without looking at the source. However, if you have a router at the IX which has _only_ peer routes and your routes, that solves the problem. If I send you a packet for Comcast, your peering router will drop it and send an ICMP Network Unreachable. No filters to manage, no RIRs to sync, nothing to code, etc. There are evil ways around this if you do not configure your router properly (e.g. send you a prefix for Comcast with next-hop set to inside your network). But standard network hygiene will stop those. And as has been stated, this doesn’t have anything to do with URPF either. (Not sure why Nick brought that up, he’s smart enough to know what URPF is and runs an exchange himself, so I think he just brain-farted. Happens to us all.) Hope that made it more clear. -- TTFN, patrick On Aug 18, 2015, at 6:35 PM, Faisal Imtiaz fai...@snappytelecom.net wrote: 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 advertised to whom... how exactly someone (peers) 'steal' transit ? (If one is not managing the filters well then yes it is possible, but that would be a configuration error ?) Maybe I am naive, to my Peering routes (relationships) are a subset of IP Transit Routes (relationships) Based on above belief... Then Item # 3, becomes the choice of the OP where one can make one of two starting assumptions... We will trust everything coming in and change what we don't like... or We will not trust anything coming in, and change (accept) what we like. Items # 1 2, would be a function of network design, technical requirements (maintenance window) etc etc.. easier to deal with a distributed edge vs all in one when one has to bring anything down for any reason.. I am open to learning and being corrected if any of the above is wrong ! Faisal Imtiaz Snappy Internet Telecom - Original Message - From: Tim Durack tdur...@gmail.com To: cisco-...@puck.nether.net, nanog list nanog@nanog.org Sent: Tuesday, August 18, 2015 8:29:31 AM Subject: 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-PeeringPolicyEnforcement.pdf ) 4. Don't worry about peers stealing transit. 5. What is peering? Your comments are appreciated. -- Tim:
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 b...@fiberinternetcenter.com To: Faisal Imtiaz fai...@snappytelecom.net Cc: Patrick W. Gilmore patr...@ianai.net, nanog list nanog@nanog.org Sent: Tuesday, August 18, 2015 7:36:00 PM Subject: 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. If you don't have much traffic to being with - yes, you are correct that you'll notice a bounce. However, you should build a network so that your average traffic level can grow without having to check things manually. The more you automate the more you and your network are worth. This way you can simply upgrade ports at IX locations in a second without worrying about traffic levels and having to establish new or change existing policies. Thank You Bob Evans CTO BTW, my comment We will trust everything coming in was in ref. to QOS tags. However, if you have a router at the IX which has _only_ peer routes and your routes, that solves the problem. If I send you a packet for Comcast, your peering router will drop it and send an ICMP Network Unreachable. In this scenario, the peering router is feeding routes to a Route Reflector ? and not taking in full routes from the route reflector ? But standard network hygiene will stop those. If there are any resources you could point to for these, I would be much obliged.. Thanks Faisal Imtiaz Snappy Internet Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: supp...@snappytelecom.net - Original Message - From: Patrick W. Gilmore patr...@ianai.net To: nanog list nanog@nanog.org Sent: Tuesday, August 18, 2015 7:12:23 PM Subject: 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 you should not. As Comcast is not one of your customers, you will have to send the packets out your transit provider. You do not get paid when I give you the packets, and you probably pay your transit provider to get to Comcast. So I have gotten something for free, and you are paying for it - i.e. stealing. Normally a router gets a packet and sends it on its way without looking at the source. However, if you have a router at the IX which has _only_ peer routes and your routes, that solves the problem. If I send you a packet for Comcast, your peering router will drop it and send an ICMP Network Unreachable. No filters to manage, no RIRs to sync, nothing to code, etc. There are evil ways around this if you do not configure your router properly (e.g. send you a prefix for Comcast with next-hop set to inside your network). But standard network hygiene will stop those. And as has been stated, this doesn’t have anything to do with URPF either. (Not sure why Nick brought that up, he’s smart enough to know what URPF is and runs an exchange himself, so I think he just brain-farted. Happens to us all.) Hope that made it more clear. -- TTFN, patrick On Aug 18, 2015, at 6:35 PM, Faisal Imtiaz fai...@snappytelecom.net wrote: 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 advertised to whom... how exactly someone (peers) 'steal' transit ? (If one is not managing the filters well then yes it is possible, but that would be a configuration error ?) Maybe I am naive, to my Peering routes (relationships) are a subset of IP Transit Routes (relationships) Based on above belief... Then Item # 3, becomes the choice of the OP where one can make one of two starting assumptions... We will trust everything coming in and change what we don't like... or We will not trust anything coming in, and change (accept) what we like. Items # 1 2, would be a function of network design, technical requirements (maintenance window) etc etc.. easier to deal with a distributed edge vs all in one when one has to bring anything down for any reason.. I am open to learning and being corrected if any of the above is wrong ! Faisal Imtiaz
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. If you don't have much traffic to being with - yes, you are correct that you'll notice a bounce. However, you should build a network so that your average traffic level can grow without having to check things manually. The more you automate the more you and your network are worth. This way you can simply upgrade ports at IX locations in a second without worrying about traffic levels and having to establish new or change existing policies. Thank You Bob Evans CTO BTW, my comment We will trust everything coming in was in ref. to QOS tags. However, if you have a router at the IX which has _only_ peer routes and your routes, that solves the problem. If I send you a packet for Comcast, your peering router will drop it and send an ICMP Network Unreachable. In this scenario, the peering router is feeding routes to a Route Reflector ? and not taking in full routes from the route reflector ? But standard network hygiene will stop those. If there are any resources you could point to for these, I would be much obliged.. Thanks Faisal Imtiaz Snappy Internet Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: supp...@snappytelecom.net - Original Message - From: Patrick W. Gilmore patr...@ianai.net To: nanog list nanog@nanog.org Sent: Tuesday, August 18, 2015 7:12:23 PM Subject: 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 you should not. As Comcast is not one of your customers, you will have to send the packets out your transit provider. You do not get paid when I give you the packets, and you probably pay your transit provider to get to Comcast. So I have gotten something for free, and you are paying for it - i.e. stealing. Normally a router gets a packet and sends it on its way without looking at the source. However, if you have a router at the IX which has _only_ peer routes and your routes, that solves the problem. If I send you a packet for Comcast, your peering router will drop it and send an ICMP Network Unreachable. No filters to manage, no RIRs to sync, nothing to code, etc. There are evil ways around this if you do not configure your router properly (e.g. send you a prefix for Comcast with next-hop set to inside your network). But standard network hygiene will stop those. And as has been stated, this doesnât have anything to do with URPF either. (Not sure why Nick brought that up, heâs smart enough to know what URPF is and runs an exchange himself, so I think he just brain-farted. Happens to us all.) Hope that made it more clear. -- TTFN, patrick On Aug 18, 2015, at 6:35 PM, Faisal Imtiaz fai...@snappytelecom.net wrote: 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 advertised to whom... how exactly someone (peers) 'steal' transit ? (If one is not managing the filters well then yes it is possible, but that would be a configuration error ?) Maybe I am naive, to my Peering routes (relationships) are a subset of IP Transit Routes (relationships) Based on above belief... Then Item # 3, becomes the choice of the OP where one can make one of two starting assumptions... We will trust everything coming in and change what we don't like... or We will not trust anything coming in, and change (accept) what we like. Items # 1 2, would be a function of network design, technical requirements (maintenance window) etc etc.. easier to deal with a distributed edge vs all in one when one has to bring anything down for any reason.. I am open to learning and being corrected if any of the above is wrong ! Faisal Imtiaz Snappy Internet Telecom - Original Message - From: Tim Durack tdur...@gmail.com To: cisco-...@puck.nether.net, nanog list nanog@nanog.org Sent: Tuesday, August 18, 2015 8:29:31 AM Subject: 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 (
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 Exchange2. Provider1's router receives traffic, checks where it should go (Exchange2) and it forwards the traffic. So the traffic flows like this: Provider2 (Exchange1) - Provider1 - (Exchange2) Provider2, all due to static routes. kind regards Pshem On Wed, 19 Aug 2015 at 10:38 Faisal Imtiaz fai...@snappytelecom.net wrote: 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 advertised to whom... how exactly someone (peers) 'steal' transit ? (If one is not managing the filters well then yes it is possible, but that would be a configuration error ?) Maybe I am naive, to my Peering routes (relationships) are a subset of IP Transit Routes (relationships) Based on above belief... Then Item # 3, becomes the choice of the OP where one can make one of two starting assumptions... We will trust everything coming in and change what we don't like... or We will not trust anything coming in, and change (accept) what we like. Items # 1 2, would be a function of network design, technical requirements (maintenance window) etc etc.. easier to deal with a distributed edge vs all in one when one has to bring anything down for any reason.. I am open to learning and being corrected if any of the above is wrong ! Faisal Imtiaz Snappy Internet Telecom - Original Message - From: Tim Durack tdur...@gmail.com To: cisco-...@puck.nether.net, nanog list nanog@nanog.org Sent: Tuesday, August 18, 2015 8:29:31 AM Subject: 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-PeeringPolicyEnforcement.pdf ) 4. Don't worry about peers stealing transit. 5. What is peering? Your comments are appreciated. -- Tim:
Re: Peering + Transit Circuits
On 18 August 2015 at 14:29, Tim Durack tdur...@gmail.com 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 transit is not practical giving the limitation that you need to use a source address from our ranges. I use ACLs on our end too just to be sure. ACL on the transit to prevent wrong source from leaving our network and ACL on the peering to prevent wrong destination to enter the network. Actually both ACLs are used in both places. The prefix lists used for the ACL need to be maintained in any case. It is the list of routes that we advertise. Regards, Baldur
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. However, if you have a router at the IX which has _only_ peer routes and your routes, that solves the problem. If I send you a packet for Comcast, your peering router will drop it and send an ICMP Network Unreachable. In this scenario, the peering router is feeding routes to a Route Reflector ? and not taking in full routes from the route reflector ? But standard network hygiene will stop those. If there are any resources you could point to for these, I would be much obliged.. Thanks Faisal Imtiaz Snappy Internet Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: supp...@snappytelecom.net - Original Message - From: Patrick W. Gilmore patr...@ianai.net To: nanog list nanog@nanog.org Sent: Tuesday, August 18, 2015 7:12:23 PM Subject: 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 you should not. As Comcast is not one of your customers, you will have to send the packets out your transit provider. You do not get paid when I give you the packets, and you probably pay your transit provider to get to Comcast. So I have gotten something for free, and you are paying for it - i.e. stealing. Normally a router gets a packet and sends it on its way without looking at the source. However, if you have a router at the IX which has _only_ peer routes and your routes, that solves the problem. If I send you a packet for Comcast, your peering router will drop it and send an ICMP Network Unreachable. No filters to manage, no RIRs to sync, nothing to code, etc. There are evil ways around this if you do not configure your router properly (e.g. send you a prefix for Comcast with next-hop set to inside your network). But standard network hygiene will stop those. And as has been stated, this doesn’t have anything to do with URPF either. (Not sure why Nick brought that up, he’s smart enough to know what URPF is and runs an exchange himself, so I think he just brain-farted. Happens to us all.) Hope that made it more clear. -- TTFN, patrick On Aug 18, 2015, at 6:35 PM, Faisal Imtiaz fai...@snappytelecom.net wrote: 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 advertised to whom... how exactly someone (peers) 'steal' transit ? (If one is not managing the filters well then yes it is possible, but that would be a configuration error ?) Maybe I am naive, to my Peering routes (relationships) are a subset of IP Transit Routes (relationships) Based on above belief... Then Item # 3, becomes the choice of the OP where one can make one of two starting assumptions... We will trust everything coming in and change what we don't like... or We will not trust anything coming in, and change (accept) what we like. Items # 1 2, would be a function of network design, technical requirements (maintenance window) etc etc.. easier to deal with a distributed edge vs all in one when one has to bring anything down for any reason.. I am open to learning and being corrected if any of the above is wrong ! Faisal Imtiaz Snappy Internet Telecom - Original Message - From: Tim Durack tdur...@gmail.com To: cisco-...@puck.nether.net, nanog list nanog@nanog.org Sent: Tuesday, August 18, 2015 8:29:31 AM Subject: 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-PeeringPolicyEnforcement.pdf ) 4. Don't worry about peers stealing transit. 5. What is peering? Your comments are appreciated. -- Tim:
Re: Peering + Transit Circuits
On Aug 18, 2015, at 7:26 PM, Faisal Imtiaz fai...@snappytelecom.net 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 provider, my transit has more out than in. If I can push some of that outbound traffic through you for free, I’ll get the inbound over my transit provider for free since inbound is so low. BTW, my comment We will trust everything coming in was in ref. to QOS tags. However, if you have a router at the IX which has _only_ peer routes and your routes, that solves the problem. If I send you a packet for Comcast, your peering router will drop it and send an ICMP Network Unreachable. In this scenario, the peering router is feeding routes to a Route Reflector ? and not taking in full routes from the route reflector ? The peering router has routes from the peers (since it peers directly with them), and routes from your internal network. Not sure where a router reflector comes into this. You can use one, or not, but it’s not relevant to which routes the peering router has. But standard network hygiene will stop those. If there are any resources you could point to for these, I would be much obliged.. There are lots, but don’t have my references with me. There’s 10K+ people on this list, I’m sure someone else has a list they like. :) -- TTFN, patrick - Original Message - From: Patrick W. Gilmore patr...@ianai.net To: nanog list nanog@nanog.org Sent: Tuesday, August 18, 2015 7:12:23 PM Subject: 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 you should not. As Comcast is not one of your customers, you will have to send the packets out your transit provider. You do not get paid when I give you the packets, and you probably pay your transit provider to get to Comcast. So I have gotten something for free, and you are paying for it - i.e. stealing. Normally a router gets a packet and sends it on its way without looking at the source. However, if you have a router at the IX which has _only_ peer routes and your routes, that solves the problem. If I send you a packet for Comcast, your peering router will drop it and send an ICMP Network Unreachable. No filters to manage, no RIRs to sync, nothing to code, etc. There are evil ways around this if you do not configure your router properly (e.g. send you a prefix for Comcast with next-hop set to inside your network). But standard network hygiene will stop those. And as has been stated, this doesn’t have anything to do with URPF either. (Not sure why Nick brought that up, he’s smart enough to know what URPF is and runs an exchange himself, so I think he just brain-farted. Happens to us all.) Hope that made it more clear. -- TTFN, patrick On Aug 18, 2015, at 6:35 PM, Faisal Imtiaz fai...@snappytelecom.net wrote: 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 advertised to whom... how exactly someone (peers) 'steal' transit ? (If one is not managing the filters well then yes it is possible, but that would be a configuration error ?) Maybe I am naive, to my Peering routes (relationships) are a subset of IP Transit Routes (relationships) Based on above belief... Then Item # 3, becomes the choice of the OP where one can make one of two starting assumptions... We will trust everything coming in and change what we don't like... or We will not trust anything coming in, and change (accept) what we like. Items # 1 2, would be a function of network design, technical requirements (maintenance window) etc etc.. easier to deal with a distributed edge vs all in one when one has to bring anything down for any reason.. I am open to learning and being corrected if any of the above is wrong ! Faisal Imtiaz Snappy Internet Telecom - Original Message - From: Tim Durack tdur...@gmail.com To: cisco-...@puck.nether.net, nanog list nanog@nanog.org Sent: Tuesday, August 18, 2015 8:29:31 AM Subject: 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 (
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 measures suffice nicely, e.g., deploying the DROP list in the firewall defending the Mailman instance. ---rsk
Fwd: [c-nsp] Peering + Transit Circuits
-- Forwarded message -- From: Tim Durack tdur...@gmail.com Date: Tue, Aug 18, 2015 at 9:53 AM Subject: Re: [c-nsp] Peering + Transit Circuits To: Rolf Hanßen n...@rhanssen.de Cc: cisco-...@puck.nether.net cisco-...@puck.nether.net On Tue, Aug 18, 2015 at 9:45 AM, Rolf Hanßen n...@rhanssen.de wrote: Hi, you forgot do some interface-ACL-magic that drops peer-traffic that does not have a destination IP in my cool-networks-whitelist. Yup, valid option. I am trying to avoid anything that involves maintaining lists. -- Tim:
Re: [c-nsp] Peering + Transit Circuits
On Tue, Aug 18, 2015 at 8:47 AM, Gert Doering g...@greenie.muc.de 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 my transit?! We're somewhat into the we'll notice if there is surprisingly high inbound traffic on peering, and then we'll find the peer, and apply appropriate measures camp... (since we're a hosting shop, we have mostly outgoing traffic, so significant amounts of incomnig traffic stick out). But yeah, something more strict might be in order. Thanks for the response. This is what I was guessing. We currently do 2. Terminate peering and transit circuits in separate VRFs. which works well when everything is a VRF but comes at the cost of higher resource usage (RIB FIB.) I was thinking a creative solution might be: 7. DSCP mark packets on peering ingress, police on transit egress. Not sure if I really want to get into using DSCP bits for basic IP service though. (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 appreciated. Software IOS can do it, Sup720 cannot do it due to hardware constraints, Sup2T exports MAC addresses taken from random caches in the system but not the inbound packets, XR doesn't do it at all, hrmph) gert -- USENET is *not* the non-clickable part of WWW! // www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025 g...@net.informatik.tu-muenchen.de -- Tim:
Re: [c-nsp] Peering + Transit Circuits
On Tue, Aug 18, 2015 at 8:47 AM, Gert Doering g...@greenie.muc.de 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 appreciated. Software IOS can do it, Sup720 cannot do it due to hardware constraints, Sup2T exports MAC addresses taken from random caches in the system but not the inbound packets, XR doesn't do it at all, hrmph) At the risk of introducing religion, I will mention sFlow... -- Tim:
Re: [c-nsp] Peering + Transit Circuits
On Tue, Aug 18, 2015 at 9:38 AM, Gert Doering g...@greenie.muc.de 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 of introducing religion, I will mention sFlow... Yes... and this is helping exactly why...? Given the overwhelming support for sFlow in (Cisco-) hardware routers used as peering edge? :-) I ask Cisco for sFlow support on a regular basis. Cisco typically respond with some variation of NIH syndrome. Anyway, back to my question :-) -- Tim:
Re: A multi-tenant firewall for an MSSP
On 18 Aug 2015, at 20:48, J. Oquendo joque...@e-fensive.net 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. State is evil, and state sharing with other targets is dangerous. Target sharing with other targets that are outsourcing their security can get increasingly scary especially if one of these clients is a juicy target. Make sure you have the infrastructure in place to quickly isolate your clients so that they do not fate share if they become in the focus of DoS attacks. This can mean isolated infrastructure for those you wish to keep up, or sacrificial infrastructure for those you are willing to let drop for the greater good. -Blake Unsure what you meant by this. In a multi-tenant firewall implementation (as far as I envision it), all tenants would occupy different IP space so I don't get how any of the state sessions would be affected. I'd be more concerned with not enough sockets. Palo Alto has a virtual system set up built specifically for this: https://www.paloaltonetworks.com/products/features/virtual-systems.html Now if only they'd send me free firewalls for marketing them. -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT, RWSP, GREM Where ignorance is our master, there is no possibility of real peace - Dalai Lama 0B23 595C F07C 6092 8AEB 074B FC83 7AF5 9D8A 4463 https://pgp.mit.edu/pks/lookup?op=getsearch=0xFC837AF59D8A4463 Back in my corporate days, the company that I was working for had persistent problems with a large UK ISP who insisted on providing a centralised managed firewall service for their multi-site internet connectivity (basically an L3VPN with a gateway for internet breakout), despite then setting the rules to allow everything as each site on the network had its own local firewall under our administrative control. The ISP were using Cisco FWSM with each customer in their own context and the company I was working for would periodically stop receiving any responses to DNS lookups irrespective of the server queried. It eventually turned out that another customer on the same FWSM kept getting DoSed and when this happened it caused some form of resource exhaustion (I'm afraid I can't recall the exact details) which broke things in the other contexts - the most noticeable of which was the protocol inspection/fixup stuff that was looking at DNS traffic! Of course, this may have been a configuration issue or a problem with the specific version of software that the ISP were running. Edward Dore Freethought Internet
Re: [c-nsp] Peering + Transit Circuits
On Tue, Aug 18, 2015 at 11:25 AM, Scott Granados sc...@granados-llc.net 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 anomalous flows or other issues. We pretty much detect and then deal with peering issues rather than prevent them with whitelists and so forth but then again we’ve been lucky and not experienced to many issues other than the occasional leakage of prefixes and such which maxprefix handles nicely. Can I ask why you terminate peering and transit on different routers? (Not suggesting that is bad, just trying to understand the reason.) Tim:
