configuration sanity check
Hi Nanogers, Any recommendation about a software which check the live config of cisco/juniper devices against some templates ? The goal is to have a template about different function device, like: - CORE device must have this bloc and this clock - PE device must have at least that and that - CPE must have this and that - Distrib switch block 1 and block2 - etc... And the software run once every day to check which device do not comply with those rules and generate an alert. Thank, - Marcel
BGP hold timer on IX LAN
Hello, As all of us know BGP was designed for scalability, thus slow convergence. But it was also when CPU was slow :-). What do you think about the standard eBGP hold timer of 180sec ? Conservative ? I'm asking because we see more and more peering partners which force the hold timer to a lower value, and when BGP negotiate the timer, the lowest hold timer is the winner. Shall we all decide that for global faster convergence we should ALL decrease the hold timer ? Or those guys which are lowering their (and our) timers on IX LAN play a dangerous game ? See a example of our peering router at AMS-IX (hold from 30s to 180s): .. BGP neighbor is 193.239.116.13x, remote AS 12x54, external link Last read 00:00:42, last write 00:00:13, hold time is 180, keepalive interval is 60 seconds BGP neighbor is 193.239.116.13x, remote AS 31x77, external link Last read 00:00:09, last write 00:00:03, hold time is 90, keepalive interval is 30 seconds BGP neighbor is 193.239.116.13x, remote AS 4x562, external link Last read 00:00:30, last write 00:00:07, hold time is 180, keepalive interval is 60 seconds BGP neighbor is 193.239.116.14x, remote AS 4x350, external link Last read 00:00:01, last write 00:00:01, hold time is 30, keepalive interval is 10 seconds BGP neighbor is 193.239.116.14x, remote AS 341x1, external link Last read 00:00:09, last write 00:00:27, hold time is 180, keepalive interval is 60 seconds BGP neighbor is 193.239.116.14x, remote AS 2x028, external link Last read 00:00:00, last write 00:00:21, hold time is 180, keepalive interval is 60 seconds BGP neighbor is 193.239.116.15x, remote AS 41x52, external link Last read 00:00:27, last write 00:00:11, hold time is 90, keepalive interval is 30 seconds BGP neighbor is 193.239.116.18x, remote AS 1x041, external link Last read 00:00:20, last write 00:00:14, hold time is 90, keepalive interval is 30 seconds BGP neighbor is 193.239.116.18x, remote AS 162x8, external link Last read 00:00:28, last write 00:00:06, hold time is 180, keepalive interval is 60 seconds BGP neighbor is 193.239.116.20x, remote AS 47x86, external link Last read 00:00:59, last write 00:00:21, hold time is 180, keepalive interval is 60 seconds BGP neighbor is 193.239.116.21x, remote AS x3350, external link Last read 00:00:02, last write 00:00:01, hold time is 30, keepalive interval is 10 seconds BGP neighbor is 193.239.116.24x, remote AS x5133, external link Last read 00:00:24, last write 00:00:03, hold time is 90, keepalive interval is 30 seconds . I've somehow basically anonymized ip and AS just in case I'm not allowed to publish those details. Best Regards, -Marcel
Re: NX-OS as LSR router
related to the discussion about IGP choice, I had a quick look and found that NX-OS ISIS for IPv6 support is quiet recent. Was not supported on 5.x, but it supported on 7.x (2015). This might explain why not so many ISP use NX-OS. On 21.10.2015 08:25, marcel.durega...@yahoo.fr wrote: Dear Nanog'er, Anybody using NX-OS on MPLS LSR and/or Edge-LSR ? We are evaluating the replacement of 7600 LSR routers. Our natural carrier/ISP choice would go for XR everywhere, but we are also curious about NX-OS on the core. Why not NX-OS for LSR and XR for Edge-LSR ? Thank, -Marcel
Re: IGP choice
Hi Matthew, Thank a lot for your answer. This help me to understand, and make more sense to me :-). Thanks, -Marcel On 23.10.2015 18:31, Matthew Petach wrote: On Fri, Oct 23, 2015 at 1:41 AM, marcel.durega...@yahoo.fr wrote: sorry for that, but the only one I've heard about switching his core IGP is Yahoo. I've no precision, and it's really interest me. I know that there had OSPF in the DC area, and ISIS in the core, and decide to switch the core from ISIS to OSPF. Wait, what? *checks memory* *checks routers* Nope. Definitely went the other way; OSPF -> IS-IS in the core. Why spend so much time/risk to switch from ISIS to OSPF, _in the core_ a not so minor impact/task ? So I could guess it's for maintain only one IGP and have standardized config. But why OSPF against ISIS ? What could be the drivers? People skills (more people know OSPF than ISIS) --> operational reason ? I'm sorry you received the wrong information, the migration was from OSPF to IS-IS, not the other way around. Thanks! Matt
Re: IGP choice
by having multiple areas, therefore ABR which deny routers and network LSA, you introduce summarization (ABR only send summary LSA, mean subnet info, not topology info) in your network. Thus you loose informations and do not have a complete topology of your network. I guess MPLS/TE prefer to seat on top of a real topology ? On 22.10.2015 23:22, Bill Blackford wrote: I don't have all the details because I don't fully understand it, but I've heard that if you're running an MPLS/RSVP core, you can only use a single OSPF area. This introduces a scalability ceiling. On Thu, Oct 22, 2015 at 12:35 PM, Dave Bell wrote: On 22 October 2015 at 19:41, Mark Tinka wrote: The "everything must connect to Area 0" requirement of OSPF was limiting for me back in 2008. I'm unsure if this is a serious argument, but its such a poor point today. Everything has to be connected to a level 2 in IS-IS. If you want a flat area 0 network in OSPF, go nuts. As long as you are sensible about what you put in your IGP, both IS-IS and OSPF scale very well. The differences between the two protocols are so small, that people really grasp at straws when 'proving' that one is better over the other. 'IS-IS doesn't work over IP, so its more secure'. 'IS-IS uses TLVs so new features are quicker to implement'. While these may be vaguely valid arguments, they don't hold much water. If you don't secure your routers to bad actors forming OSPF adjacencies with you, you're doing something wrong.Who is running code that is so bleeding edge that feature X might be available for IS-IS, but not OSPF? Chose whichever you and your operational team are most comfortable with, and run with it. Regards, Dave
Re: IGP choice
sorry for that, but the only one I've heard about switching his core IGP is Yahoo. I've no precision, and it's really interest me. I know that there had OSPF in the DC area, and ISIS in the core, and decide to switch the core from ISIS to OSPF. Why spend so much time/risk to switch from ISIS to OSPF, _in the core_ a not so minor impact/task ? So I could guess it's for maintain only one IGP and have standardized config. But why OSPF against ISIS ? What could be the drivers? People skills (more people know OSPF than ISIS) --> operational reason ? In my understanding of both protocols, from 3 year old documentation (2012): OSPF is more or less limited to hundred routers in the backbone area. Yeah, ok, but back in 2005 I know some ISP which run 200 routers in the backbone area (only one area) w/o problem. What about today ? protocol design limitation or resources (memory+cpu) limitation ? If ressources only, as of today we can put also 1000 ospf routers in one area... Cisco recommend no more than 50 routers per area with OSPF. Is it a conservative value ? It also depend on the number of networks/router, of course. ISIS is not. ISIS scale up to thousand routers in the same area. Some docs say that ISIS converge faster due to fewer LSP traffic (compare to OSPF which generate more LSA traffic, therefore use more CPU) and better timers. Timers can also be tuned with OSPF, so I do not sea a real argument with better timers for ISIS (same story between HSRP versus VRRP with better timers for VRRP). As your doc say (reason to choose ISIS): better convergence, better security, simplicity. -Marcel On 22.10.2015 19:25, Niels Bakker wrote: * marcel.durega...@yahoo.fr (marcel.durega...@yahoo.fr) [Thu 22 Oct 2015, 18:57 CEST]: Anybody from Yahoo to share experience on IGP choice ? What a weird way to limit your audience. This is NANOG, not Yahoo. Otherwise, http://userpages.umbc.edu/~vijay/work/ppt/oi.pdf -- Niels.
IGP choice
Hi everyone, Anybody from Yahoo to share experience on IGP choice ? IS-IS vs OSPF, why did you switch from one to the other, for what reason ? Same question could apply to other ISP, I'd like to heard some international ISP/carriers design choice, please. Thank in advance, Best regards, -Marcel
NX-OS as LSR router
Dear Nanog'er, Anybody using NX-OS on MPLS LSR and/or Edge-LSR ? We are evaluating the replacement of 7600 LSR routers. Our natural carrier/ISP choice would go for XR everywhere, but we are also curious about NX-OS on the core. Why not NX-OS for LSR and XR for Edge-LSR ? Thank, -Marcel
Re: Experience on Wanguard for 'anti' DDOS solutions
One thing which is not so obvious is to reduce false positive. This is hard when you have a mix of traffic profiles/patterns within your network, with customers in differents domains (scientists, financials, video addicted, torrent addicted, etc...) with different bandwidth. a) Does anybody tried to separate ip range by traffic profile to apply specific rule/profile per ip allocation? puts all financials clients into range X/X and define rule Z puts all scientists clients into range Y/Y and apply rule Q etc Does this help ? b) One other method could be to classify customers by their bandwidth. profile 1. from 10-100M profile 2. 100-500M profile 3. 500M-1000M profile 4. >1000M Like this you do not mix big BW with small BW customer, and do not get alerted when client from profile 4 start to download at 1G. Any experience ? My guess is that solution b is better than a. Not so easy to classify traffic pattern per group of client. Thank, best regards. - Marcel On 13.08.2015 06:42, Ramy Hashish wrote: Hello Fabien, And why don't you use A10 for both detection and mitigation? Thanks, Ramy On Wed, Aug 12, 2015 at 6:42 PM, Fabien Delmotte wrote: Hello My 2 cents You can use Wanguard for the detection and A10 for the mitigation, you have just to play with the API. Regards Fabien Le 12 août 2015 à 16:28, Ramy Hashish a écrit : Date: Tue, 11 Aug 2015 08:14:54 +0200 From: "marcel.durega...@yahoo.fr" To: nanog@nanog.org Subject: Re: Experience on Wanguard for 'anti' DDOS solutions Message-ID: <55c992de.3020...@yahoo.fr> Content-Type: text/plain; charset=windows-1252; format=flowed anybody from this impressive list ?: https://www.andrisoft.com/company/customers -- Marcel Anybody here compared Wanguard's performance with the DDoS vendors in the market (Arbor, Radware, NSFocus, A10, RioRey, Staminus, F5 ..)? Another question, have anybody from the reviewers tested the false positives of the box, or experienced any false positive incidents? Thanks, Ramy
Re: Experience on Wanguard for 'anti' DDOS solutions
you can try to get some financials (probably poor technical) view on DDOS : http://www.infonetics.com/pr/2014/1H14-DDoS-Prevention-Appliances-Market-Highlights.asp The DDOS prevention Appliances report is not free, and I doubt it's really technical :-) But at least you could know what your financial guys might think. Could help you if you want to convince them to buy Arbor :-). - Marcel On 12.08.2015 16:28, Ramy Hashish wrote: Date: Tue, 11 Aug 2015 08:14:54 +0200 From: "marcel.durega...@yahoo.fr" To: nanog@nanog.org Subject: Re: Experience on Wanguard for 'anti' DDOS solutions Message-ID: <55c992de.3020...@yahoo.fr> Content-Type: text/plain; charset=windows-1252; format=flowed anybody from this impressive list ?: https://www.andrisoft.com/company/customers -- Marcel Anybody here compared Wanguard's performance with the DDoS vendors in the market (Arbor, Radware, NSFocus, A10, RioRey, Staminus, F5 ..)? Another question, have anybody from the reviewers tested the false positives of the box, or experienced any false positive incidents? Thanks, Ramy
Re: Experience on Wanguard for 'anti' DDOS solutions
Aaron, Do you remember which release or when it was ? Are you talking about detection or filtering which failed for many sources targeting a single destination ? Which sensor did you test, packet sensor or flow sensor ? Thank, Regards, - Marcel On 11.08.2015 17:42, Aaron wrote: We tested it a while back and found that it was fine for single source attacks but fell over with multiple sources. Has that changed? On 8/11/2015 9:42 AM, Nick Rose wrote: We have processed just under a million anomalies with this software, we use the Chelsio cards for filtering. We had some troubles with packet loss on the filter side until we started using those which were a new feature in the latest release. If you have any questions I would be happy to answer them. Regards, Nick Rose | CTO Enzu Inc nick.r...@enzu.com www.enzu.com <http://www.enzu.com/> On 8/11/15, 2:14 AM, "NANOG on behalf of marcel.durega...@yahoo.fr" wrote: anybody from this impressive list ?: https://www.andrisoft.com/company/customers -- Marcel On 11.08.2015 03:28, Paul Ferguson wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 8/10/2015 6:07 PM, valdis.kletni...@vt.edu wrote: On Tue, 11 Aug 2015 09:36:07 +1000, Nick Pratley said: Once setup correctly. very good product - it's been running for 8 months now and hasn't had any issues. It's been very reliable. I'll bite - (roughly) how many times has it triggered and mitigated an actual DDoS during those 8 months? We probably draw different conclusions from "8 months and 1 DDoS" reliable and "8 months of 5-a-week" reliable... I think that would definitely depend on how the network is base-lined. That is sometimes more of an art than a science. :-) - - ferg - -- Paul Ferguson PGP Public Key ID: 0x54DC85B2 Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlXJT7EACgkQKJasdVTchbJXoQD+Mhyy7gwtMkp+mdaEUiqvwlWe 70mSH8n5ALmcp+qOqMoBAKo60u/ryb9IdvsclzPpoAvq+r9CtZgh+t/9YpkUIgnP =d7d1 -END PGP SIGNATURE-
Re: Experience on Wanguard for 'anti' DDOS solutions
anybody from this impressive list ?: https://www.andrisoft.com/company/customers -- Marcel On 11.08.2015 03:28, Paul Ferguson wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 8/10/2015 6:07 PM, valdis.kletni...@vt.edu wrote: On Tue, 11 Aug 2015 09:36:07 +1000, Nick Pratley said: Once setup correctly. very good product - it's been running for 8 months now and hasn't had any issues. It's been very reliable. I'll bite - (roughly) how many times has it triggered and mitigated an actual DDoS during those 8 months? We probably draw different conclusions from "8 months and 1 DDoS" reliable and "8 months of 5-a-week" reliable... I think that would definitely depend on how the network is base-lined. That is sometimes more of an art than a science. :-) - - ferg - -- Paul Ferguson PGP Public Key ID: 0x54DC85B2 Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlXJT7EACgkQKJasdVTchbJXoQD+Mhyy7gwtMkp+mdaEUiqvwlWe 70mSH8n5ALmcp+qOqMoBAKo60u/ryb9IdvsclzPpoAvq+r9CtZgh+t/9YpkUIgnP =d7d1 -END PGP SIGNATURE-
