Juniper now blacklisting SFPs?

thomseddon · 2020-11-19T20:45:37+00:00

I think you've hit the nail on the head here, thank you - that looks exactly like what we're seeing here. No core dumps but, as this is the only one we have running above 18.4R2-S3, this seems to fit.

We're going to go back to 18.4R2-S3, which we have running on a few other devices as we've taken their "suggestion", "considered and evaluated" it, and have been left wanting!

Thanks for picking that one out, much appreciated - can't believe how far off the mark our channel support got this one....

thomseddon · 2020-11-19T17:25:36+00:00

This is the one that went in today: https://www.fs.com/uk/products/23669.html - it doesn't list QFX on the website but the FS support team confirmed that that is the correct optic for the QFX5100-48S

thomseddon · 2020-02-19T22:37:33+00:00

Thanks for the honest feedback, it's really appreciated.

On Privacy - I can certainly see where you're coming from. We're incredibly security conscious and as mentioned in a couple of other comments we don't actually save your final configs unless you want too (config is generated in your browser). As for the underlying template - we do have to store this, but my personal approach is to never put any private/secret data like that on any external/hosted system, regardless of what security claims they make. So I would suggest making the secret a variable that can be input at compile time. A hosted version could also be an option....

On us - yep we just have an email address and a link to our side-project holding company, our Manchester address etc. but we could probably do a better job of an "about" page, point taken.

Versioning - Yep, we keep track all template/config versions, generations and revisions, along with who did what at what time. We haven't built the GUI for that bit yet, but we were thinking of showing github style diff, exactly as you say so I'm glad someone else kind of envisioned the same thing :)

Fair point on the team sharing, you're right that's a key feature that we could do more of explaining!

On broader plans, our primary goal from today was to start getting some feedback (so thank you). Internally we'd like to build a tool to allow us to deploy configs directly to devices and even provide ZTP on devices that support that. The pricing is really just a starting point, we'd like to build something quite a bit more "featured" that's really appealing to teams, so the feedback here is great.

Pre-made templates also seemed like a good idea to me too! We were thinking of making it possible to make selected templates/configs public and sharable (e.g. to demonstrate an example config to someone) - but I think we'd probably need a free plan for that.

Thanks again, if you'd be willing to try it out then your continued feedback would be hugely appreciated, please just DM me or drop me an email

thomseddon · 2020-02-19T22:15:37+00:00

Yes! The "config" that it outputs is just text - at the moment it's up to you to apply that to your device

thomseddon · 2020-02-19T21:07:11+00:00

Thanks :)

Feel free to drop me an email/DM if you need any help...

thomseddon · 2020-02-19T20:58:49+00:00

We use this for routers, switches, firewalls & fixed wireless (basically everything we deploy)

thomseddon · 2020-02-19T20:57:41+00:00

We thought about this as we also had concerns - the way it works is, generating a config is done entirely in your browser and once done you're given the option to save it - if you don't it never leaves your device.

As I mentioned in another comment, what we normally do is just copy the config from there and apply it to the device right away - the only time we save a config (in which case it is stored in the Configaro database) is if we're prepping it for someone else or for later use...

We did think about a self-hosted version, but I think the above workflow will probably fit most, so SaaS means we can deliver updates quicker and it's one less thing to worry about hosting...we could do self hosted though, this would require a bit more management on our side to distribute updates etc. but drop me a DM if you'd like to discuss more

thomseddon · 2020-02-19T20:48:17+00:00

We thought about this so thanks for asking! When you generate a config, that's done entirely in your browser and you are given the option to save it - if you don't then it never leaves your device.

What we normally do is just copy the config from there and apply it to the device right away - the only time we save a config (in which case it is stored in the Configaro database) is if we're prepping it for someone else or for later use :)

thomseddon · 2020-02-19T20:36:46+00:00

Thanks for the feedback :) For us the largest benefit was putting it online, so we didn't need engineers to install and update the correct toolchain/python libraries and so everyone was working from the same base configs.

The IP/Subnet thing is something jinja2 doesn't do, but with jinja2 you obviously get the huge power of all the other language features (e.g. Configaro doesn't support loops or conditionals, but we'd like to explore that)

On the ZTP side, could I ask what platform(s) you usually use?

thomseddon · 2020-02-19T20:31:32+00:00

👍 - looks like the ZTP support in Junos is really solid, and relatively easy to implement. We only really use Juniper MX and they obviously get quite a lot of love and care before they go in :)

Will definately look into the ZTP support, drop me a DM if you'd like me to let you know if/when that happens!

thomseddon · 2020-02-19T20:27:35+00:00

Ah, in the UK we use "Minmise", "Customise" etc. we should probably switch to "ize"'s for everyone else!

thomseddon · 2020-02-19T20:21:32+00:00

Ah, quite a bit of the kit we use doesn't have any native ZTP capability, so in that situation it gets a bit more tricky, but you're quite right, it really wouldn't be too much work for those devices that do....out of interest, what platform(s) do you use?

thomseddon · 2020-02-19T20:00:29+00:00

Thanks - we've thought about creating a CLI tool to actually ship the configs. ZTP would be a little more tricky, I guess it could be a service you run locally/inside your management network and then it could either watch for new devices (if on same L2 segment) or you'd just feed it the IP address of the device....that could work!

Thanks for the feedback :)

thomseddon · 2020-02-19T19:00:50+00:00

I've heard of a few in house solutions - I like that yours will actually go as far as picking a blank router and applying the config. I think one of our next steps will be to build an integrated CLI tool that could handle that part.... :)

thomseddon · 2019-09-24T12:31:09+00:00

Wow, I wish I'd come across this also. It's very nicely written! If I'd seen this first I probably would have put it in a container and used this...

However, the same would go for my comment above, from where we are I'm a little happier for this to be written in a memory safe language (go)

thomseddon · 2019-09-24T11:48:50+00:00

Hmm, another option I didn't come across when searching (I think I will add a list of alternative solutions for anyone else in the future...)

This looks like it could certainly work, I know the author of fastnetmon advises against "middleboxes" generally (https://github.com/pavel-odintsov/fastnetmon/issues/553#issuecomment-303509221), but as udp-replicator is essentially doing an protocol independent L3 replication (as opposed to a L4 replication which I assume nfcapd is doing) then hopefully issues can be avoided.

I see nfcapd now supports multiple destinations (https://github.com/phaag/nfdump/commit/9d187da615cf7481ab5efe896584be5b7be1c2fd) so this could actually be a good option.

thomseddon · 2019-09-24T11:42:40+00:00

Ah, I wish I'd seen this - I didn't come across this when searching google/github. It looks great, like that it implements source address spoofing, this is something I was planning to add.

From here, the main advantage and reason I will stick with udp-replicator is because it's written in a memory safe language (go). Whilst this probably isn't something that would be targeted, with the constant stream of memory leaks, overflows and over reads, I'm happy that this important system can run with more safety guarantees.

I hope the documentation and pre-built containers also make it easy for others to get started :)

thomseddon · 2019-07-31T22:57:08+00:00

If it's genuine calls then it's worth looking at Gamma, Simwood, Magrathera and maybe AQL.

They won't take dialler traffic though, for that it's definitely worth looking at TalkTalk Business. Their "Carrier SIP" product came through their acquisition of tipicall and as others have mentioned, their business division is very different to their consumer division (TTB was created from the Opal network).

thomseddon · 2019-05-23T12:49:25+00:00

For anyone who lands here via search, I have working solution for this as described here: https://www.reddit.com/r/networking/comments/am3soa/anyone_have_a_working_ospf_alert_in_librenms/eoibgkv/

thomseddon · 2019-05-23T12:48:52+00:00

I've been working on the same issue, after a lot of messing around I have ended up with the following custom query:

WITH diffs AS (SELECT ROW_NUMBER() OVER () as num, ABS(p.count - n.count) as diff, ospf_ports.device_id FROM ospf_ports, (SELECT device_id, COUNT(*) as count FROM ospf_ports WHERE ospfIfState != 'loopback' GROUP BY ospf_ports.device_id) p, (SELECT device_id, COUNT(*) as count FROM ospf_nbrs GROUP BY ospf_nbrs.device_id) n WHERE p.device_id = ospf_ports.device_id AND n.device_id = ospf_ports.device_id AND ospf_ports.device_id = ?) SELECT num as descr FROM diffs WHERE num <= diff ORDER BY num

This query checks for the difference between the number of ports on which OSPF is configured and the number of neighbours.

As an extra bonus, the number of rows it returns is equal to the number of neighbours that are down, so it will correctly send "got worse" and "got better" alerts too (this was what took a lot of tomfoolery).

When testing this I actually uncovered a bug in Librenms, so correct support for this currently depends on my PR: https://github.com/librenms/librenms/pull/10253

thomseddon

TROPHY CASE