Re: mpls over microwave
One more add: Properly engineered, fixed wireless links can have better-than-wireline availability. Two jobs ago, we had customer links with zero dropped packets in 5 years, which is outstanding compared to most copper-based services. Properly engineered, however, is the key. Make sure whom-ever is building your links looks at vendor specs, builds a real link budget (including losses from connectors, cable, grounding, etc) properly weather seals everything, and try to get at least a a 20db fade margin if you can. If the things I just mentioned are confusing to your RF guy, you might want to get outside help. On 2/5/15, 3:17 PM, Scott Weeks sur...@mauigateway.com wrote: Had to run off to a meeting. Back now. This is one thing I was worried about. I'm not doing the radio part. Someone else is. I didn't know if folks do pure Ethernet or if it's an IP hand off. If it's an IP addressed hand off, I have to come out of MPLS, cross the link, then go back into MPLS. Thanks for the pointers on packet size. I will be sure to check into that. Scott
RE: mpls over microwave
-Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Scott Weeks Thanks everyone, I feel a lot more confident on this project after this discussion. I will be working with a comm engineer who'll be doing the various radio links. I just need to be sure he can make the best decision as we're moving from ATM to MPLS and he doesn't understand the networking part and I only understand the basics of microwave links. --- snasl...@medline.com wrote: From: Naslund, Steve snasl...@medline.com I would try to recommend finding a microwave guy that knows IP. Quite a lot of them do now since most of their installs are IP traffic backhaul. --- There is no choice in this situation. I get what I get and make it work. And, it is hard to find technical folks *way* out in the country on a dot in the middle of the Pacific Ocean. :-) scott
Re: Provider to Blend with Level3
I don't know how accurate it is, but here's a site that more plainly spells out upstream\peer\customer: https://radar.qrator.net/ - Mike Hammett Intelligent Computing Solutions http://www.ics-il.com - Original Message - From: Faisal Imtiaz fai...@snappytelecom.net To: Colton Conor colton.co...@gmail.com Cc: NANOG nanog@nanog.org Sent: Friday, February 6, 2015 2:15:29 PM Subject: Re: Provider to Blend with Level3 We approach this in the following empirical manner. 1) Who is available to you easily and within the budget. 2) Where is the other side of the network connectivity consumers ? i.e. do you need good connectivity to Cable Network ? ATT Broadband ? Europe ? Mexico ? Latin America ? 3) What is the bulk of the traffic type ? Consumer (Video / You Tube ? Netflix ? ) Business ? etc based on the answers to above, I would look at the bgp.he.net to see each options upstream connectivity, and check with peeringdb to see what could be their peering relationships finding one that does not have a directly Level3 relationship would be preferred. Also, don't forget to do traffic engineering to nullify the Level3 traffic engineering, (They prefer to keep traffic on-net even if there are better paths available out of their network). 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: Colton Conor colton.co...@gmail.com To: NANOG nanog@nanog.org Sent: Friday, February 6, 2015 12:26:55 PM Subject: Provider to Blend with Level3 We have a network that is single homed with Level3 at this time in Dallas. They already have BGP and their own ASN and IP setup. Who would you recommend for a second provider in Dallas to blend with Level3? Assuming Level3 and this other provider would be the only two in the blend for a long time to come? Client was talking to TWT, but now that they are being bought by Level3 that doesn't make much sense.
BGP Update Report
BGP Update Report Interval: 29-Jan-15 -to- 05-Feb-15 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASNUpds % Upds/PfxAS-Name 1 - AS23752 272647 6.5%2198.8 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 2 - AS9829 151291 3.6% 90.4 -- BSNL-NIB National Internet Backbone,IN 3 - AS381662061 1.5% 114.1 -- COLOMBIA TELECOMUNICACIONES S.A. ESP,CO 4 - AS53563 59929 1.4%7491.1 -- XPLUSONE - X Plus One Solutions, Inc.,US 5 - AS845238477 0.9% 18.3 -- TE-AS TE-AS,EG 6 - AS51964 31841 0.8% 88.9 -- ORANGE-BUSINESS-SERVICES-IPSN-ASN Equant Inc.,FR 7 - AS958328712 0.7% 21.9 -- SIFY-AS-IN Sify Limited,IN 8 - AS48159 28597 0.7% 95.3 -- TIC-AS Telecommunication Infrastructure Company,IR 9 - AS60725 26037 0.6%2002.8 -- O3B-AS O3b Limited,JE 10 - AS840223179 0.6% 133.2 -- CORBINA-AS OJSC Vimpelcom,RU 11 - AS17974 22998 0.6% 8.1 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia,ID 12 - AS42337 22453 0.5% 136.9 -- RESPINA-AS Respina Networks Beyond PJSC,IR 13 - AS23342 22314 0.5% 22314.0 -- UNITEDLAYER - Unitedlayer, Inc.,US 14 - AS38197 21893 0.5% 26.2 -- SUNHK-DATA-AS-AP Sun Network (Hong Kong) Limited,HK 15 - AS197914 20789 0.5% 20789.0 -- STOCKHO-AS Stockho Hosting SARL,FR 16 - AS27738 20735 0.5% 26.5 -- Ecuadortelecom S.A.,EC 17 - AS25563 19652 0.5%4913.0 -- WEBLAND-AS Webland AG, Autonomous System,CH 18 - AS11054 19087 0.5% 795.3 -- LIVEPERSON - LivePerson, Inc.,US 19 - AS10620 19074 0.5% 7.4 -- Telmex Colombia S.A.,CO 20 - AS34170 18808 0.5% 186.2 -- AZTELEKOM Azerbaijan Telecomunication ISP,AZ TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASNUpds % Upds/PfxAS-Name 1 - AS23342 22314 0.5% 22314.0 -- UNITEDLAYER - Unitedlayer, Inc.,US 2 - AS197914 20789 0.5% 20789.0 -- STOCKHO-AS Stockho Hosting SARL,FR 3 - AS61039 16246 0.4% 16246.0 -- ZMZ OAO ZMZ,RU 4 - AS53563 59929 1.4%7491.1 -- XPLUSONE - X Plus One Solutions, Inc.,US 5 - AS25563 19652 0.5%4913.0 -- WEBLAND-AS Webland AG, Autonomous System,CH 6 - AS337214881 0.1%4881.0 -- CCL-ASN2 - CARNIVAL CRUISE LINES,US 7 - AS1980057258 0.2%3629.0 -- UNI-AS UNI BAHRAIN TELECOM Bsc closed,SA 8 - AS677518764 0.5%3127.3 -- BACKBONE_EHF_EUROPE Backbone ehf,CH 9 - AS47680 14546 0.3%2909.2 -- NHCS EOBO Limited,IE 10 - AS2012242247 0.1%2247.0 -- MYOWNAS PE Evgeny Tikhomirov,RU 11 - AS45606 11225 0.3%2245.0 -- 12 - AS23752 272647 6.5%2198.8 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 13 - AS1322422162 0.1%2162.0 -- HOGARTHWW-SG Hogarth Worldwide Pte,SG 14 - AS60725 26037 0.6%2002.8 -- O3B-AS O3b Limited,JE 15 - AS621741993 0.1%1993.0 -- INTERPAN-AS INTERPAN LTD.,BG 16 - AS201511907 0.1%1907.0 -- MCW-12-01 - Mountain Computer Wizards, Inc.,US 17 - AS1980531872 0.0%1872.0 -- AMTEL VECTRA S.A.,PL 18 - AS1979571708 0.0%1708.0 -- KERBB Ker Broadband Communications Ltd,IE 19 - AS662910520 0.2%1502.9 -- NOAA-AS - NOAA,US 20 - AS33440 12005 0.3%1500.6 -- WEBRULON-NETWORK - webRulon, LLC,US TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 202.70.64.0/21 138229 3.2% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 2 - 202.70.88.0/21 133081 3.0% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 3 - 199.38.164.0/23 59920 1.4% AS53563 -- XPLUSONE - X Plus One Solutions, Inc.,US 4 - 64.29.130.0/2422314 0.5% AS23342 -- UNITEDLAYER - Unitedlayer, Inc.,US 5 - 130.0.192.0/2120789 0.5% AS197914 -- STOCKHO-AS Stockho Hosting SARL,FR 6 - 79.134.225.0/24 18755 0.4% AS6775 -- BACKBONE_EHF_EUROPE Backbone ehf,CH 7 - 91.235.169.0/24 16246 0.4% AS61039 -- ZMZ OAO ZMZ,RU 8 - 91.193.202.0/24 15846 0.4% AS42081 -- SPEEDY-NET-AS Speedy net EAD,BG 9 - 88.87.160.0/1914530 0.3% AS47680 -- NHCS EOBO Limited,IE 10 - 162.249.183.0/24 13395 0.3% AS60725 -- O3B-AS O3b Limited,JE 11 - 185.26.155.0/24 12607 0.3% AS60725 -- O3B-AS O3b Limited,JE 12 - 192.58.232.0/24 10514 0.2% AS6629 -- NOAA-AS - NOAA,US 13 - 42.83.48.0/20 9839 0.2% AS18135 -- BTV BTV Cable television,JP 14 - 196.43.144.0/239371 0.2% AS327687 -- RENU,UG 15 - 199.191.120.0/22 7998 0.2% AS15177 -- STARTOUCH-WA1 - STARTOUCH
The Cidr Report
This report has been generated at Fri Feb 6 21:14:23 2015 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org/2.0 for a current version of this report.
Recent Table History
Date PrefixesCIDR Agg
30-01-15535593 295029
31-01-15535725 294851
01-02-15535758 295558
02-02-15536071 295227
03-02-15536401 293285
04-02-15536630 293544
05-02-15537306 294063
06-02-15537226 294611
AS Summary
49580 Number of ASes in routing system
19856 Number of ASes announcing only one prefix
3090 Largest number of prefixes announced by an AS
AS10620: Telmex Colombia S.A.,CO
120442368 Largest address span announced by an AS (/32s)
AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street,CN
Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').
--- 06Feb15 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 537228 294453 24277545.2% All ASes
AS6389 2890 69 282197.6% BELLSOUTH-NET-BLK -
BellSouth.net Inc.,US
AS22773 2982 172 281094.2% ASN-CXA-ALL-CCI-22773-RDC -
Cox Communications Inc.,US
AS17974 2823 77 274697.3% TELKOMNET-AS2-AP PT
Telekomunikasi Indonesia,ID
AS39891 2473 18 245599.3% ALJAWWALSTC-AS Saudi Telecom
Company JSC,SA
AS28573 2339 312 202786.7% NET Serviços de Comunicação
S.A.,BR
AS4755 1972 252 172087.2% TATACOMM-AS TATA
Communications formerly VSNL
is Leading ISP,IN
AS4766 2882 1320 156254.2% KIXS-AS-KR Korea Telecom,KR
AS6147 1719 160 155990.7% Telefonica del Peru S.A.A.,PE
AS7303 1771 284 148784.0% Telecom Argentina S.A.,AR
AS9808 1526 55 147196.4% CMNET-GD Guangdong Mobile
Communication Co.Ltd.,CN
AS10620 3090 1636 145447.1% Telmex Colombia S.A.,CO
AS20115 1854 520 133472.0% CHARTER-NET-HKY-NC - Charter
Communications,US
AS8402 1357 25 133298.2% CORBINA-AS OJSC Vimpelcom,RU
AS7545 2553 1256 129750.8% TPG-INTERNET-AP TPG Telecom
Limited,AU
AS4323 1628 408 122074.9% TWTC - tw telecom holdings,
inc.,US
AS18566 2041 869 117257.4% MEGAPATH5-US - MegaPath
Corporation,US
AS9498 1289 182 110785.9% BBIL-AP BHARTI Airtel Ltd.,IN
AS6849 1230 134 109689.1% UKRTELNET JSC UKRTELECOM,UA
AS7552 1141 53 108895.4% VIETEL-AS-AP Viettel
Corporation,VN
AS34984 1968 893 107554.6% TELLCOM-AS TELLCOM ILETISIM
HIZMETLERI A.S.,TR
AS3356 2568 1501 106741.5% LEVEL3 - Level 3
Communications, Inc.,US
AS22561 1332 300 103277.5% AS22561 - CenturyTel Internet
Holdings, Inc.,US
AS7738 1000 84 91691.6% Telemar Norte Leste S.A.,BR
AS6983 1621 713 90856.0% ITCDELTA - Earthlink, Inc.,US
AS38285 983 113 87088.5% M2TELECOMMUNICATIONS-AU M2
Telecommunications Group
Ltd,AU
AS18881 862 24 83897.2% Global Village Telecom,BR
AS4538 1776 957 81946.1% ERX-CERNET-BKB China Education
and Research Network
Center,CN
AS8151 1520 717 80352.8% Uninet S.A. de C.V.,MX
AS26615 920 137 78385.1% Tim Celular S.A.,BR
AS8551 1092 313 77971.3% BEZEQ-INTERNATIONAL-AS
Bezeqint Internet Backbone,IL
Total 55202135544164875.4% Top 30 total
Possible Bogus
RE: mpls over microwave
-Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Scott Weeks Sent: Saturday, 7 February 2015 5:26 AM To: nanog@nanog.org Subject: RE: mpls over microwave There is no choice in this situation. I get what I get and make it work. And, it is hard to find technical folks *way* out in the country on a dot in the middle of the Pacific Ocean. :-) scott Hi Scott, Just a few tips from someone who did some of the RF engineering and ran a mpls network in a previous job :- Watch your MTUs. Also, watch out for flow control - talk to your radio vendor to see if you will need it enabled. Good luck :) -Tim
Looking for a Consolidated Communications (AS5742) contact
Hoping to speak with a Consolidated Communications (AS5742) engineer regarding routing in Illinois region towards Gaikai (AS33353). Thanks, Chris Costa
Re: Looking for a Consolidated Communications (AS5742) contact
- Original Message - From: Mike Hammett na...@ics-il.net This is the third or fourth request I've seen lately. I'm assuming they don't have anyone on here. Not necessarily. Some people reply privately, so as not to come out of the closet. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
Re: Looking for a Consolidated Communications (AS5742) contact
Yeah, but it's the same guy looking for the same people for the same issue. I know it sucks to have things not working right, but they're probably not here. - Mike Hammett Intelligent Computing Solutions http://www.ics-il.com - Original Message - From: Jay Ashworth j...@baylink.com To: NANOG nanog@nanog.org Sent: Friday, February 6, 2015 8:10:58 PM Subject: Re: Looking for a Consolidated Communications (AS5742) contact - Original Message - From: Mike Hammett na...@ics-il.net This is the third or fourth request I've seen lately. I'm assuming they don't have anyone on here. Not necessarily. Some people reply privately, so as not to come out of the closet. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
Re: Looking for a Consolidated Communications (AS5742) contact
Oops, sorry. Didn't think those other requests got through the moderator. :) On Feb 6, 2015 6:18 PM, Mike Hammett na...@ics-il.net wrote: Yeah, but it's the same guy looking for the same people for the same issue. I know it sucks to have things not working right, but they're probably not here. - Mike Hammett Intelligent Computing Solutions http://www.ics-il.com - Original Message - From: Jay Ashworth j...@baylink.com To: NANOG nanog@nanog.org Sent: Friday, February 6, 2015 8:10:58 PM Subject: Re: Looking for a Consolidated Communications (AS5742) contact - Original Message - From: Mike Hammett na...@ics-il.net This is the third or fourth request I've seen lately. I'm assuming they don't have anyone on here. Not necessarily. Some people reply privately, so as not to come out of the closet. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
Re: Looking for a Consolidated Communications (AS5742) contact
This is the third or fourth request I've seen lately. I'm assuming they don't have anyone on here. - Mike Hammett Intelligent Computing Solutions http://www.ics-il.com - Original Message - From: Chris Costa ccosta92...@gmail.com To: nanog@nanog.org Sent: Friday, February 6, 2015 6:05:28 PM Subject: Looking for a Consolidated Communications (AS5742) contact Hoping to speak with a Consolidated Communications (AS5742) engineer regarding routing in Illinois region towards Gaikai (AS33353). Thanks, Chris Costa
Re: Provider to Blend with Level3
We approach this in the following empirical manner. 1) Who is available to you easily and within the budget. 2) Where is the other side of the network connectivity consumers ? i.e. do you need good connectivity to Cable Network ? ATT Broadband ? Europe ? Mexico ? Latin America ? 3) What is the bulk of the traffic type ? Consumer (Video / You Tube ? Netflix ? ) Business ? etc based on the answers to above, I would look at the bgp.he.net to see each options upstream connectivity, and check with peeringdb to see what could be their peering relationships finding one that does not have a directly Level3 relationship would be preferred. Also, don't forget to do traffic engineering to nullify the Level3 traffic engineering, (They prefer to keep traffic on-net even if there are better paths available out of their network). 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: Colton Conor colton.co...@gmail.com To: NANOG nanog@nanog.org Sent: Friday, February 6, 2015 12:26:55 PM Subject: Provider to Blend with Level3 We have a network that is single homed with Level3 at this time in Dallas. They already have BGP and their own ASN and IP setup. Who would you recommend for a second provider in Dallas to blend with Level3? Assuming Level3 and this other provider would be the only two in the blend for a long time to come? Client was talking to TWT, but now that they are being bought by Level3 that doesn't make much sense.
Re: Provider to Blend with Level3
With how many people cogent connects with, it is almost never a bad idea to have them in your mix. On Fri, Feb 6, 2015 at 12:26 PM, Colton Conor colton.co...@gmail.com wrote: We have a network that is single homed with Level3 at this time in Dallas. They already have BGP and their own ASN and IP setup. Who would you recommend for a second provider in Dallas to blend with Level3? Assuming Level3 and this other provider would be the only two in the blend for a long time to come? Client was talking to TWT, but now that they are being bought by Level3 that doesn't make much sense.
Re: Checkpoint IPS
On 6 Feb 2015, at 20:08, Ray Soucy wrote: An IDS tied into an internal RTBH setup to leverage uRPF filtering in hardware can be pretty effective at detecting and blocking the typical UDP attacks out there before they reach systems that don't handle that as gracefully (e.g. firewalls or host systems). Using flow telemetry for this scales much, much better. One could easily set something like this up using open source flow telemetry collection/analysis tools. Of course, giving attackers the ability to spoof the IP addresses of their choice and then induce your network infrastructure into blocking said IP addresses isn't necessarily optimal, IMHO. I'm not a big fan of any kind of auto-mitigation for this reason - it's best to have a human operator in the loop. If one is determined to do this kind of auto-mitigation, it's probably a good idea to whitelist certain things which ought never to be S/RTBHed via appropriate route filtering on the trigger and/or edge devices where traffic will be dropped. --- Roland Dobbins rdobb...@arbor.net
RE: mpls over microwave
I would try to recommend finding a microwave guy that knows IP. Quite a lot of them do now since most of their installs are IP traffic backhaul. Steven Naslund Chicago IL -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Scott Weeks Sent: Thursday, February 05, 2015 11:42 PM To: nanog@nanog.org Subject: Re: mpls over microwave Thanks everyone, I feel a lot more confident on this project after this discussion. I will be working with a comm engineer who'll be doing the various radio links. I just need to be sure he can make the best decision as we're moving from ATM to MPLS and he doesn't understand the networking part and I only understand the basics of microwave links. scott
RE: Re: Checkpoint IPS
IPSes are like any security technology, they are only as good as their implementor/administrator. I've seen some installations just set up defaults and leave them that way without any maintenance nor much oversight of alarms. I've even seen some that do 0-day implementation of new signatures, and get some legitimate or even ALL traffic blocked by a bad signature (Astaro/Sophos UTM) update back in ~2004. On the other hand, I've seen some great implementations--some of which did a FANTASTIC job of making a network auditable, some of which made a network less liable legally and financially, and quite a few that made a network more secure. To me, the big drawback of an IPS is, no matter how well integrated, implemented, and maintained--it's fundamental nature is flawed. Instead of default-deny with white lists, it is default-allow with black lists. It will always lag behind. It will always allow infinitely large holes. That's why I prefer an OSI complete firewall instead, or else an IPS in detect mode only, or in certain cases an IPS used in a specific case, e.g. a WAF or SAF for a server/application/zone that is specifically fuzzy or will not adhere to security principles (vendor demilitarized zones, enclaves, whatever the buzz-word is at the moment). I understand the whole argument against state, and dismiss it. That's throwing the baby out with the bathwater. It isn't perfect, it can be overcome via DDOS and saturation, so we should get rid of it. Tanks can be destroyed by bazookas, whatever. Tanks are still useful in the battlefield if utilized properly. Firewalls and IPSes are the same way. --p
RE: mpls over microwave
Hey, We run few mpls links ( 7600s/3600s on the mpls side mostly ) over Ceragon wireless gear. Nothing too fancy, I just treat them as switches ( or even just cables for some boxes, not doing mac learning at all ). No issues whatsoever on the networking side. My thoughts and words are my own. Kind Regards, Spyros -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Scott Weeks Sent: Thursday, February 05, 2015 11:55 PM To: nanog@nanog.org Subject: mpls over microwave Anyone doing MPLS over microwave radios? Please share your experiences on list or off. scott This e-mail and any attachment(s) contained within are confidential and are intended only for the use of the individual to whom they are addressed. The information contained in this communication may be privileged, or exempt from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender and delete the communication without retaining any copies. Rolaware Hellas SA is not responsible for, nor endorses, any opinion, recommendation, conclusion, solicitation, offer or agreement or any information contained in this communication.
Re: Checkpoint IPS
On 6 Feb 2015, at 21:27, Darden, Patrick wrote: I understand the whole argument against state, and dismiss it. One can 'dismiss' the speed of light in a vacuum or the Planck constant, but that doesn't exempt one from their constraints. --- Roland Dobbins rdobb...@arbor.net
Re: Checkpoint IPS
On 6 Feb 2015, at 23:23, Darden, Patrick wrote: And when your opinion is an acknowledged universal constant, I will tip my hat to you. It's been a constant for the last couple of decades - I can't count the number of times I've been involved in mitigating penny-ante DDoS attacks which succeeded *solely* due to state exhaustion on stateful firewalls, 'IPS' devices, and load-balancers. I've seen a 20gb/sec commercial stateful firewall taken down by a 3mb/sec spoofed SYN-flood. I've seen a 10gb/sec commercial load-balancer taken down by 60 second at 6kpps - yes, 6kpps - of HOIC. And so on, and so forth. 'Dismiss' it all you like, but it's a real issue, as others on this list know from bitter experience. --- Roland Dobbins rdobb...@arbor.net
Re: Checkpoint IPS
Thought I would add Astaro IPS works great, great functionality and does prevent ddos and exploits. Colin
RE: Re: Checkpoint IPS
Auto-Update can cause problems. I take the stance that updates should be verified in a CERT or ISO first, before being operationalized. --p -Original Message- From: Colin Johnston [mailto:col...@gt86car.org.uk] Sent: Friday, February 06, 2015 10:46 AM To: Darden, Patrick Cc: Colin Johnston; Roland Dobbins; nanog@nanog.org Subject: [EXTERNAL]Re: Checkpoint IPS Yes, update can cause problems, same as router code updates as well. but update is price of progress. Col On 6 Feb 2015, at 16:44, Darden, Patrick patrick.dar...@p66.com wrote: Sorry, didn't mean to imply otherwise. Had an incident back in ~2004 where an IPS signature update closed ALL network traffic. Including fix-it updates. Definitely a case where the IPS caused major difficulties for a network. --p -Original Message- From: Colin Johnston [mailto:col...@gt86car.org.uk] Sent: Friday, February 06, 2015 10:32 AM To: Darden, Patrick Cc: Colin Johnston; Roland Dobbins; nanog@nanog.org Subject: [EXTERNAL]Re: Checkpoint IPS Thought I would add Astaro IPS works great, great functionality and does prevent ddos and exploits. Colin
Re: Input Regarding Cogent and NTT
Cogent has been very good in my experience. They have some issues they need to work out, but are pretty solid. We have had some issues where they have said they are doing maintenance on such and such night and it comes a day early. We have also seen some routing weirdness when it comes to route selection. Ive had a connection, server, something on Cogent for about 12 years now. I started with a server in Chicago at the Board of Trade building. At that time Cogent was the home of cheap web-hosts, ware, and porn. I remember a year or so after I had that server the big folks like ATT and some others de-peered with Cogent. Many of the web-sites I was hosting were simply not reachable for a few days from a big majority of the Internet. I think the sheer amount of web-sites and content convinced the big folks to bring up the peering. I was working for a large dial-up ISP at the time and remember getting call after call about someone not being able to reach their favorite web-site. Cogent tech support has always been top notch. They answer the phone and I have always been directed to an engineer that can help right away. As of 6 months ago their ticketing system still sucked, but I think everyone’s does. LOL. This is my on-list stuff. I can go into more detail if anyone wants to know. Justin Wilson j...@mtin.net http://www.mtin.net Managed Services – xISP Solutions – Data Centers http://www.thebrotherswisp.com Podcast about xISP topics http://www.midwest-ix.com Peering – Transit – Internet Exchange On Feb 5, 2015, at 12:24 PM, Jack Stonebraker jack.stonebra...@mygrande.com wrote: My organization is currently shopping for some additional Transit Capacity to augment our existing interconnects. We've got around 8 distinct AS's that we're receiving transit routes from, followed by a handful of Public IX's and Private PNI's to AS's that warrant them. That said, the networks that are on our radar are Cogent and NTT. I've done some due diligence poking around on their Looking Glass, but I'd love to hear any user experiences from the community, both from a Layer 3 Perspective, as well as an Operational Perspective (Working with the businesses themselves). Feel free to contact me off-list and thanks in advance for your time. [cid:image002.jpg@01CFE2F3.A6F973D0] Jack Stonebraker | Sr. IP Network Engineer (512) 878-5627 | jack.stonebra...@mygrande.commailto:john.ho...@mygrande.com Grande Communications Networks 401 Carlson Circle | San Marcos, Texas | 78666
Provider to Blend with Level3
We have a network that is single homed with Level3 at this time in Dallas. They already have BGP and their own ASN and IP setup. Who would you recommend for a second provider in Dallas to blend with Level3? Assuming Level3 and this other provider would be the only two in the blend for a long time to come? Client was talking to TWT, but now that they are being bought by Level3 that doesn't make much sense.
Re: Checkpoint IPS
An IPS doesn't have to be in line. It can be something watching a tap and scripted to use something else to block traffic (e.g. hardware filtering options on a router that can handle it). An IDS tied into an internal RTBH setup to leverage uRPF filtering in hardware can be pretty effective at detecting and blocking the typical UDP attacks out there before they reach systems that don't handle that as gracefully (e.g. firewalls or host systems). Even if you keep it from being automated and just have it be an IDS that you can have a human respond to is pretty valuable. On Thu, Feb 5, 2015 at 6:40 PM, Patrick Tracanelli eks...@freebsdbrasil.com.br wrote: On 05/02/2015, at 12:31, Terry Baranski terry.baranski.l...@gmail.com wrote: On Thu, Feb 5, 2015 at 8:34 AM, Roland Dobbins rdobb...@arbor.net wrote: I've never heard a plausible anecdote, much less seen meaningful statistics, of these devices actually 'preventing' anything. People tend to hear what they want to hear. Surely your claim can't be that an IPS has never, in the history of Earth, prevented an attack or exploit. So it's unclear to me what you're actually trying to say here. And the fact that well-known evasion techniques still work against these devices today, coupled with the undeniable proliferation of compromised hosts residing within networks supposedly 'protected' by these devices, militates against your proposition. Your tendency of making blanket statements is somewhat baffling given the multitude of intricacies, details, and varying circumstances involved in a complex topic like this. To me, it's indicative of an overly-simplified and/or biased way of looking at things. In any case, go ahead and stick with your router ACLs and (stateful!) proxies. Different strokes. -Terry There's room for a good engineered strategy for protection which won't turn into a point of failure in the overall networking topology. For decades, since first rainbow series books were written and military strategy started to be added to information security, it's always been about defense in depth and layered defense. Today those buzzwords became an incredibly bullshit bingo on sales force strategy on selling magical boxes and people tend to forget the basics. Layers and the depth is not a theory just to be added to drawings and keynote presentations. Considering a simplistic topology for 3-tier (4 if you count T0) depth protection strategy: (Internet)--[Tier-0]--(Core Router)--[Tier1]--(core switch)--[Tier2]--(DMZ)--[Tier3]--(Golden Secret) One security layer (tier, whatever) is there to try to fill the gap from the previous one. How deep you have to dig depends on who you are. If you are the end organization willing to protect the golden secret, how complex is your topology, or if you are the carrier, the telecom the company worried only about BGP, PPS, BPS and availability other than the actual value for what's the real target for the attack (if not availability) In summary, in my experience what will (not) work is: 1) Tier 0 Tier 1 On border, core, (Tier0) or on Tier-1 protection layers (typical firewall/dmz topological position) - Memory and CPU exaustion will shut down your operations (increase latency and decrease availability) easily, if you have a Protecting Inbound Proxy (Web Application Firewall, for the sales jargon), Stateful Firewall or IPS. The thing here is, you are insane or naive if you believe a finite state machine with finite resources can protect you from a virtually infinite (unlimited) source of attacks. No matter how much RAM you have, how much CPU cycles you have, they are finite, and since those amazing stateful w/ deep inspection, scrub, normalization and reassembly features on a firewall will demand at least 4K RAM per session and a couple CPU cycles per test, you have a whole line rate (1.4Mpps / 14Mpps for 1GbE 10GbE ports) attack potential, and come on, if a single or a 3-way packets sequence will cost you a state, it's an easy math count to find out you are in a bad position trying to secure those Tier0 and Tier1 topological locations. It's just easier and cheaper for the one attacking, than for your amazing firewall or IPS. So what to do here? Try to get rid of most automated/scripted/simple attack you can. You can do ingress filtering, a lot of BCP, protection against SNMP/NTP/DNS amplification, verify reverse path, (verrevpath, antipsoof, verrevreachability), and many good / effective (but limited) protection with ACL, data plane protection mechanisms, BGP blackholing, Null Routing (sending stuff to disc0 on BSD, null0 on Cisco, etc) and Stateles Firewalling. Also, an IDS sensor might fit here, because if CPU/Memory starvation happens on an IDS sensor, the worst thing will happen is some packets getting routed without proper processing. But still, they will get routed. Always stateles, always simple tests. No Layer7 inspection of any
Re: Checkpoint IPS
On Thu, Feb 5, 2015 at 10:47 AM, Roland Dobbins rdobb...@arbor.net wrote: On 6 Feb 2015, at 0:38, Raymond Burkholder wrote: There must some sort of value in that? No - patch the servers. Patching servers protects against 0 Day attacks only. This does not protect against 0 day attacks, unless you know of an OS vendor that writes good code without security holes. What type of device needed depends on risk, what you are protecting, what attacks are important, etc. It's not a simple matter of firewall bad or firewall good. I won't even get into the stateless-vs-stateful debate, because it's more complex than stateful bad (*cough* SIP *cough*). Nor will I mention that it depends on what your protecting to figure out how much of each of availability or confidentiality or integrity you need - you might need lots of integrity but little availability, for instance.
Re: Checkpoint IPS
Hello, On 06/02/2015, at 11:08, Ray Soucy r...@maine.edu wrote: An IPS doesn't have to be in line. AFAIK this is basically what defines an IPS. It can be something watching a tap and scripted to use something else to block traffic (e.g. hardware filtering options on a router that can handle it). You are naming IPS on what is actually an IDS+Active Response as I mentioned before (my #1 option of choice). Not been online won’t for instance prevent the so called single packet attacks and therefore what should be the advantage of an IPS over an IDS is just thrown away. Which, again, I accept what’s missed for what I still have. But I don’t think it can be named IPS acting passively+actively, since it’s not actually not preventing. An IDS tied into an internal RTBH setup to leverage uRPF filtering in hardware can be pretty effective at detecting and blocking the typical UDP attacks out there before they reach systems that don't handle that as gracefully (e.g. firewalls or host systems). That’s exactly the point I agree and adopt. Maybe a first packet will pass, but it takes longer anyway to be deterministic whether the traffic is common or attack traffic. It’s an IPs there and exausting/starving won’t cause issues to the network, only to it’s own capability. Even if you keep it from being automated and just have it be an IDS that you can have a human respond to is pretty valuable. Not a coincidence that Bejtlich’s NSM101and TCP/IP Weapons School courses are usually sold out on Black Hat. Valuable humans behind the tools will always provide better benefits than what vendors may generically sell/deliver. On Thu, Feb 5, 2015 at 6:40 PM, Patrick Tracanelli eks...@freebsdbrasil.com.br wrote: On 05/02/2015, at 12:31, Terry Baranski terry.baranski.l...@gmail.com wrote: On Thu, Feb 5, 2015 at 8:34 AM, Roland Dobbins rdobb...@arbor.net wrote: I've never heard a plausible anecdote, much less seen meaningful statistics, of these devices actually 'preventing' anything. People tend to hear what they want to hear. Surely your claim can't be that an IPS has never, in the history of Earth, prevented an attack or exploit. So it's unclear to me what you're actually trying to say here. And the fact that well-known evasion techniques still work against these devices today, coupled with the undeniable proliferation of compromised hosts residing within networks supposedly 'protected' by these devices, militates against your proposition. Your tendency of making blanket statements is somewhat baffling given the multitude of intricacies, details, and varying circumstances involved in a complex topic like this. To me, it's indicative of an overly-simplified and/or biased way of looking at things. In any case, go ahead and stick with your router ACLs and (stateful!) proxies. Different strokes. -Terry There's room for a good engineered strategy for protection which won't turn into a point of failure in the overall networking topology. For decades, since first rainbow series books were written and military strategy started to be added to information security, it's always been about defense in depth and layered defense. Today those buzzwords became an incredibly bullshit bingo on sales force strategy on selling magical boxes and people tend to forget the basics. Layers and the depth is not a theory just to be added to drawings and keynote presentations. Considering a simplistic topology for 3-tier (4 if you count T0) depth protection strategy: (Internet)--[Tier-0]--(Core Router)--[Tier1]--(core switch)--[Tier2]--(DMZ)--[Tier3]--(Golden Secret) One security layer (tier, whatever) is there to try to fill the gap from the previous one. How deep you have to dig depends on who you are. If you are the end organization willing to protect the golden secret, how complex is your topology, or if you are the carrier, the telecom the company worried only about BGP, PPS, BPS and availability other than the actual value for what's the real target for the attack (if not availability) In summary, in my experience what will (not) work is: 1) Tier 0 Tier 1 On border, core, (Tier0) or on Tier-1 protection layers (typical firewall/dmz topological position) - Memory and CPU exaustion will shut down your operations (increase latency and decrease availability) easily, if you have a Protecting Inbound Proxy (Web Application Firewall, for the sales jargon), Stateful Firewall or IPS. The thing here is, you are insane or naive if you believe a finite state machine with finite resources can protect you from a virtually infinite (unlimited) source of attacks. No matter how much RAM you have, how much CPU cycles you have, they are finite, and since those amazing stateful w/ deep inspection, scrub, normalization and reassembly features on a firewall will demand at least 4K RAM per session and a couple CPU cycles per test, you have a
RE: Re: Checkpoint IPS
Absolutely. Valuable humans behind the tools will always provide better benefits than what vendors may generically sell/deliver.
Re: Dynamic routing on firewalls.
On 2/6/15 8:39 AM, Bill Thompson wrote: You can fix a car with a swiss army knife, but why would you want to? Is it a metric swiss army knife?
RE: IPv6 allocation plan, security, and 6-to-4 conversion
On Jan 30, 2015, at 07:37 , Owen DeLong owen@delong wrote: /48 for all customer sites is not at all unreasonable and is fully supported by ARIN policy. Where Bill is correct is that some customers may have more than one site. The official policy definition of a site is a single building or structure, or, in the case of a multi-tenant building or structure, a single tenant within that building. Yes, this could technically mean that a college dorm contains thousands of sites and could justify thousands of /48s. Is this your recommendation for colleges? Or, are you simply pointing out a possible interpretation of ARIN policy?
Weekly Routing Table Report
This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-st...@lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith pfsi...@gmail.com. Routing Table Report 04:00 +10GMT Sat 07 Feb, 2015 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary BGP routing table entries examined: 531413 Prefixes after maximum aggregation (per Origin AS): 203223 Deaggregation factor: 2.61 Unique aggregates announced (without unneeded subnets): 258742 Total ASes present in the Internet Routing Table: 49323 Prefixes per ASN: 10.77 Origin-only ASes present in the Internet Routing Table: 36426 Origin ASes announcing only one prefix: 16291 Transit ASes present in the Internet Routing Table:6256 Transit-only ASes present in the Internet Routing Table:171 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 108 Max AS path prepend of ASN ( 60548) 101 Prefixes from unregistered ASNs in the Routing Table: 1729 Unregistered ASNs in the Routing Table: 422 Number of 32-bit ASNs allocated by the RIRs: 8523 Number of 32-bit ASNs visible in the Routing Table:6641 Prefixes from 32-bit ASNs in the Routing Table: 24025 Number of bogon 32-bit ASNs visible in the Routing Table: 6 Special use prefixes present in the Routing Table:0 Prefixes being announced from unallocated address space:366 Number of addresses announced to Internet: 2723652128 Equivalent to 162 /8s, 87 /16s and 162 /24s Percentage of available address space announced: 73.6 Percentage of allocated address space announced: 73.6 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 97.2 Total number of prefixes smaller than registry allocations: 180263 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes: 131329 Total APNIC prefixes after maximum aggregation: 38230 APNIC Deaggregation factor:3.44 Prefixes being announced from the APNIC address blocks: 136555 Unique aggregates announced from the APNIC address blocks:55629 APNIC Region origin ASes present in the Internet Routing Table:5025 APNIC Prefixes per ASN: 27.18 APNIC Region origin ASes announcing only one prefix: 1231 APNIC Region transit ASes present in the Internet Routing Table:882 Average APNIC Region AS path length visible:4.6 Max APNIC Region AS path length visible:107 Number of APNIC region 32-bit ASNs visible in the Routing Table: 1290 Number of APNIC addresses announced to Internet: 741427840 Equivalent to 44 /8s, 49 /16s and 74 /24s Percentage of available APNIC address space announced: 86.7 APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 131072-135580 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary Prefixes being announced by ARIN Region ASes:175419 Total ARIN prefixes after maximum aggregation:86719 ARIN Deaggregation factor: 2.02 Prefixes being announced from the ARIN address blocks: 177355 Unique aggregates announced from the ARIN address blocks: 83028 ARIN Region origin ASes present in the Internet Routing Table:16477 ARIN Prefixes per ASN:
RE: Re: Checkpoint IPS
And when your opinion is an acknowledged universal constant, I will tip my hat to you. In the meantime, your argument is extremely soundbitey--sounds great, but stupid. --p -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Roland Dobbins Sent: Friday, February 06, 2015 10:09 AM To: nanog@nanog.org Subject: [EXTERNAL]Re: Checkpoint IPS On 6 Feb 2015, at 21:27, Darden, Patrick wrote: I understand the whole argument against state, and dismiss it. One can 'dismiss' the speed of light in a vacuum or the Planck constant, but that doesn't exempt one from their constraints. --- Roland Dobbins rdobb...@arbor.net
Re: Dynamic routing on firewalls.
Just because a cat has kittens in the oven, you don't call them biscuits. A firewall can route, but it is not a router. Both have specialized tasks. You can fix a car with a swiss army knife, but why would you want to? -- Bill Thompson bi...@mahagonny.com On February 5, 2015 7:19:43 PM PST, Jeff McAdams je...@iglou.com wrote: On Thu, February 5, 2015 20:02, Joe Hamelin wrote: On Feb 5, 2015, at 2:49 PM, Ralph J.Mayer rma...@nerd-residenz.de wrote: a router is a router and a firewall is a firewall. Especially a Cisco ASA is no router, period. Man-o-man did I find that out when we had to renumber our network after we got bought by the French. Oh, I'll just pop on a secondary address on this interface... What? Needed to go through fits just to get a hairpin route in the thing. The ASA series is good at what it does, just don't plan on it acting like router IOS. Sorry, but I'm with Owen. Square : Rectangle :: Firewall : Router A firewall is a router, despite how much so many security folk try to deny it. And firewalls that seem to try to intentionally be crappy routers (ie, ASAs) have no place in my network. If it can't be a decent router, then its going to suck as a firewall too, because a firewall has to be able to play nice with the rest of the network, and if they can't do that, then I have no use for them. I'll get a firewall that does.
Re: Checkpoint IPS
Yes, update can cause problems, same as router code updates as well. but update is price of progress. Col On 6 Feb 2015, at 16:44, Darden, Patrick patrick.dar...@p66.com wrote: Sorry, didn't mean to imply otherwise. Had an incident back in ~2004 where an IPS signature update closed ALL network traffic. Including fix-it updates. Definitely a case where the IPS caused major difficulties for a network. --p -Original Message- From: Colin Johnston [mailto:col...@gt86car.org.uk] Sent: Friday, February 06, 2015 10:32 AM To: Darden, Patrick Cc: Colin Johnston; Roland Dobbins; nanog@nanog.org Subject: [EXTERNAL]Re: Checkpoint IPS Thought I would add Astaro IPS works great, great functionality and does prevent ddos and exploits. Colin
RE: mpls over microwave
We run MPLS over wireless links of all kinds quite extensively. The key is to make sure that packet loss is at a minimum (duh), and to ensure that your wireless links have a large enough MTU to pass the additional bytes for each label. Other than that, we treat the wireless links as wires. -- Tim Huffman Staff Manager - Engineering | Windstream 999 Oak Creek Dr | Lombard, IL 60148 timothy.huff...@windstream.com | windstreambusiness.com o: 630.590.6012 | m: 630.340.1925 | f: 630.986.2496 -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Spyros Kakaroukas Sent: Friday, February 06, 2015 5:46 AM To: 'sur...@mauigateway.com'; nanog@nanog.org Subject: RE: mpls over microwave Hey, We run few mpls links ( 7600s/3600s on the mpls side mostly ) over Ceragon wireless gear. Nothing too fancy, I just treat them as switches ( or even just cables for some boxes, not doing mac learning at all ). No issues whatsoever on the networking side. My thoughts and words are my own. Kind Regards, Spyros -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Scott Weeks Sent: Thursday, February 05, 2015 11:55 PM To: nanog@nanog.org Subject: mpls over microwave Anyone doing MPLS over microwave radios? Please share your experiences on list or off. scott This e-mail and any attachment(s) contained within are confidential and are intended only for the use of the individual to whom they are addressed. The information contained in this communication may be privileged, or exempt from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender and delete the communication without retaining any copies. Rolaware Hellas SA is not responsible for, nor endorses, any opinion, recommendation, conclusion, solicitation, offer or agreement or any information contained in this communication. -- This email message and any attachments are for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message and any attachments.
RE: Re: Checkpoint IPS
Sorry, didn't mean to imply otherwise. Had an incident back in ~2004 where an IPS signature update closed ALL network traffic. Including fix-it updates. Definitely a case where the IPS caused major difficulties for a network. --p -Original Message- From: Colin Johnston [mailto:col...@gt86car.org.uk] Sent: Friday, February 06, 2015 10:32 AM To: Darden, Patrick Cc: Colin Johnston; Roland Dobbins; nanog@nanog.org Subject: [EXTERNAL]Re: Checkpoint IPS Thought I would add Astaro IPS works great, great functionality and does prevent ddos and exploits. Colin
Re: Checkpoint IPS
yes, using new rules via test ips good best practice as well. On 6 Feb 2015, at 16:47, Darden, Patrick patrick.dar...@p66.com wrote: Auto-Update can cause problems. I take the stance that updates should be verified in a CERT or ISO first, before being operationalized. --p -Original Message- From: Colin Johnston [mailto:col...@gt86car.org.uk] Sent: Friday, February 06, 2015 10:46 AM To: Darden, Patrick Cc: Colin Johnston; Roland Dobbins; nanog@nanog.org Subject: [EXTERNAL]Re: Checkpoint IPS Yes, update can cause problems, same as router code updates as well. but update is price of progress. Col On 6 Feb 2015, at 16:44, Darden, Patrick patrick.dar...@p66.com wrote: Sorry, didn't mean to imply otherwise. Had an incident back in ~2004 where an IPS signature update closed ALL network traffic. Including fix-it updates. Definitely a case where the IPS caused major difficulties for a network. --p -Original Message- From: Colin Johnston [mailto:col...@gt86car.org.uk] Sent: Friday, February 06, 2015 10:32 AM To: Darden, Patrick Cc: Colin Johnston; Roland Dobbins; nanog@nanog.org Subject: [EXTERNAL]Re: Checkpoint IPS Thought I would add Astaro IPS works great, great functionality and does prevent ddos and exploits. Colin
