Skip to main content
Flexible Top Header

Featured Topics

Unanswered questions

DDI Multi-primary

We're looking to install another site with recursive and authoritative DNS. I’ve done some looking into the multi-primary function though unsure if this is what we're looking for. The goal is to have this site’s DNS/DHCP intact in a disaster scenario where the primary data center is down or unreachable. I am only finding instructions on how to setup multi-primary roles on new zones without existing primary roles. In my attempt to test this I was not able to use or add a new multi-primary role to existing zone as it complains there is already a primary role. Looks like you would have to remove the existing primary role to add the new role, though not sure of the impact here.Can a multi-primary DNS setup function if the BAM is unreachable? How do you install multi-primary roles on existing zones with little or no impact to clients? 

Race condition causing duplicate IP assignments via API

We have run into a situation where our virtual compute provisioning stack is experiencing duplicate IP assignments from Bluecat.  They are POSTing to the v2 API endpoint /api/v2/networks/{collection}/addresses without specifying an address, allowing BAM to allocate the next available.  When multiple requests are submitted in quick succession (within the same second) for the same network, BAM sometimes returns the same IP to both requests with an HTTP 201 code, causing the provisioning automation to assign the same IP to multiple VMs.Other than single-threading the provisioning (which is problematic if different stacks of provisioning automation are provisioning on the same networks) - are there any thoughts of how to avoid this and has anyone else run into it?  This is supposedly confirmed as a defect and there was originally a recommendation to use the v1 assignNextAvailableIP4Address call instead - but when I pushed for assurance that this call would not suffer from the same susceptibility to race condition that the v2 call did the recommendation was withdrawn.We’re running 9.5.2, and I’ve not been told that this issue is any different in any other versions.

Let's Encrypt Certs in 25.1 vs. 9.6.1

I’ve upgraded my lab to 25.1 and have found that the Let’s Encrypt certs aren’t working as expected.  I don’t see errors in Firefox or Chrome but code to check the certs are failing against 25.1 with the error “ Certificate validation error: FQDN-25.1 [unable to get local issuer certificate]” which lead me to test with curl.I’m wondering if anyone else is seeing the same issue or is this something I’m doing wrong.This is the error I see with “curl -v https://FQDN/”:root@bam:~# curl -v https://FQDN/* Trying 10.0.10.26:443...* Connected to FQDN (10.0.10.26) port 443 (#0)* ALPN: offers h2,http/1.1* TLSv1.3 (OUT), TLS handshake, Client hello (1):* CAfile: /etc/ssl/certs/ca-certificates.crt* CApath: /etc/ssl/certs* TLSv1.3 (IN), TLS handshake, Server hello (2):* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):* TLSv1.3 (IN), TLS handshake, Certificate (11):* TLSv1.3 (OUT), TLS alert, unknown CA (560):* SSL certificate problem: unable to get local issuer certificate* Closing connection 0curl: (60) SSL certificate problem: unable to get local issuer certificateMore details here: https://curl.se/docs/sslcerts.htmlI don’t see the error on a 9.6.1 BAM using the same certificate file and key.If I look at /data/server/conf/server.cert on the 25.1 BAM I just see the local cert.  The local and issuer certs are both in the file on the 9.6.1 BAM.The BAM was upgraded from 9.6.1 to 25.1.  After the upgrade I had to load a renewed certificate and that’s when the issue started.  I spun up a new 9.6.1 BAM and loaded the new certificate on it to compare.

Here for a specific product? Jump right into posting

Click on the product you'd like to start a conversation or ask a question

Recent activity

V25.1.x docker builds failing due to issues within Debian apt sources

Is anyone else out there experiencing failures when building custom containers using either v25.1.0 or v25.1.1 as their dockerfile FROM sources?Example:0.372 Get:1 http://deb.debian.org/debian bullseye InRelease [75.1 kB] 0.454 Get:2 http://deb.debian.org/debian-security bullseye-security InRelease [27.2 kB] 0.497 Get:3 http://deb.debian.org/debian bullseye-updates InRelease [44.0 kB] 0.543 Ign:4 http://deb.debian.org/debian bullseye-backports InRelease0.581 Get:5 http://deb.debian.org/debian bullseye/main amd64 Packages [8066 kB]1.235 Get:6 http://deb.debian.org/debian-security bullseye-security/main amd64 Packages [422 kB]1.300 Err:7 http://deb.debian.org/debian bullseye-backports Release1.300 404 Not Found [IP: 146.75.30.132 80]1.339 Get:8 http://deb.debian.org/debian bullseye-updates/main amd64 Packages [18.8 kB]1.933 Reading package lists...2.231 E: The repository 'http://deb.debian.org/debian bullseye-backports Release' does not have a Release file.I have a CARES ticket open for this, but maybe someone from the Gateway team will see this first and be able to resolve this quicker.Yes, I know that v25.2.0 is the most recent, but I need to stick with python 3.9.2 for now (moving to 3.11 as I rewrite workflows using APIV2). I don’t have apt-get update failures when using 25.2.0, however.Thanks,Martin.

Blog

Blog: Layer 8 Lounge Recap: What DDI Metrics Actually Matter?

Blog: Layer 8 Lounge Recap: What DDI Metrics Actually Matter?   TL;DR The community wants alerts driven by a tight set of meaningful metrics, not wall-to-wall dashboards. Top pain points: log volume and cost, inconsistent JSON formats, and the lack of sensible, role-based default alerts. Capacity trends (queues, leases, range headroom) and DHCP “noisy talkers” surfaced as practical early warnings. See questions, answers, and open follow-ups below.  Key Findings  Alerts over dashboards: Day-to-day ops should rely on right-sized alerts; dashboards are for investigations and reviews.  Cut noise at the source: Logging is too verbose/variable; JSON needs normalization and tunable profiles.  Make “base alerts” turnkey: Ship sensible defaults by role (BAM/DNS/DHCP/edge) with global apply.  Watch capacity + chatter: Short-horizon trends and DHCP churn/noisy talkers are reliable early signals.  Operator vs. exec: Operators need thresholds/anomalies; leadership wants summarized health/utilization.   Questions Asked → Answers Given  1) What do you actually check first? Many start with email/Teams for incident signals; desire to replace manual checks with automated alerts. Real incident: misconfig multiplied DHCP requests (~10K/day → 65M/day), stressing DNS registration. Still needed: A starter alert pack (metrics + thresholds) so teams aren’t building from zero. Today Infrastructure Assurance can provide that and there will be more to come with Integrity X, with the support of this call in the future.  2) What metrics/logs are too much?  Log deluge (often debug-like) drives SIEM cost; JSON logs are heavier and harder to parse.  Query logging can slow external resolvers; teams sample (log one node, keep others fast).  What helps:  Normalized JSON schema across components and a minimal/standard/verbose profile.  Guidance on which fields are critical vs. optional for incident workflows.   3) Where should default alerts exist by… default?  Out-of-box coverage is thin; teams want role-based default alerts and global apply.  Examples requested: subnet ≥90% utilization, DNS/DHCP rate anomalies, queue saturation, zone transfer failures, health thresholds.  What helps:  A monitoring blueprint: 10–15 must-have alerts + example thresholds and suppression rules.  Easier grouping/targeting of notifications at scale.   4) Activity vs. query logging — what’s practical?  JSON activity logs produce higher ingestion; inconsistent fields across sources break dashboards.  Performance metric that matters: query processing time (receive→resolve) to catch outliers (normally sub-ms).  What helps:  Guidance on when to use activity vs. query logging, sampling strategies, and safe verbosity levels.   5) Which log levels and can we forward to multiple SIEMs?  Levels are hierarchical (higher includes lower).  Need proper source-type classification so logs don’t appear as generic “Linux/Debian.”  What helps:  Recipes for multi-destination forwarding (e.g., Splunk + QRadar) and source-type mapping best practices.  Clear mapping of syslog vs. data audit (coverage and use cases).   6) Do you forecast capacity? How about DHCP “noisy talkers”?  Yes to short-term trends (leases, ranges, queues).  DHCP chatter/noisy talkers are tracked but should inform alerts instead of requiring constant dashboard watching.  Case: Windows “Relentless Renewals” (thousands/hour) tied to client power settings; trends exposed it.  What helps:  Simple capacity trend recipes (2–4 weeks) and alert examples for queue saturation, range headroom, lease churn, noisy talkers.   Open Follow-Ups:  Starter alert pack: Curate a default set of alerts (metrics, thresholds, scope) by role.  JSON normalization: Publish a unified field schema + minimal/standard/verbose profiles.  Logging guidance: Document when to use activity vs. query logging, and sampling patterns for externals.  Multi-SIEM forwarding: Show dual-destination examples (Splunk + QRadar), with port/transport notes.  Source-type mapping: Provide recipes to classify logs correctly (no more “generic Debian”).  Global notifications: How to apply alert groups at scale (current and future BDDS).   Capacity/churn playbooks: Quick starts for queue, range, lease churn, noisy talker alerts (plus anti-flap tuning).   Magic Moments and useful anecdotes  DHCP multiplier meltdown: One misconfig turned each request into eight, creating ~65M/day; illustrates the need for anomaly alerts and guardrails.  Query logging vs. performance: Heavy query logging slowed external DNS; teams now sample one node for visibility.  Relentless renewals: Abnormal DHCP renewals traced to client power settings, proving the value of short-term capacity trends.   Bottom Line Teams want to start with a narrow, meaningful alert set, keep logs lean and consistent, and rely on short-term capacity trends plus DHCP chatter detection for early warning. We’ll compile community inputs to help direct future releases! 

Customer Webinar — On Demand

[Customer Webinar] Introducing LiveAssist — AI Powered Net Ops

 Introducing LiveAssist — AI Powered Net Ops Video Sections (skip to the listed minute below for specific topics covered)Architecture Review: 1:00 - 6:50  Data Sources Available to LiveAssist: 6:50 - 10:45  Root Cause Analysis: 10:45 - 14:16 AI Dashboard: 14:16 - 15:58 LiveAssist for WAN Capacity and Network Analysis: 15:58 - 17:37 Demo: 17:37 - 58:24  Q&A: 58:24 - 101:40

VISIONARY WHITEBOARD

Visionary Whiteboard: Simplifying Network Management with BlueCat Micetro and Edge

Visionary Whiteboard: Simplifying Network Management with BlueCat Micetro and Edge See how BlueCat’s Visionary Whiteboard session reimagines DNS and DHCP for today’s hybrid, multi-cloud environments. Follow the story of an IT admin as their network grows from simple Active Directory infrastructure to a complex mix of on-prem, open-source, and cloud systems.Watch how Micetro by BlueCat centralizes visibility, unifies automation, and simplifies integration with tools like ServiceNow and Azure Private Link—culminating in a look at the intelligent, secure future of network operations

Finding IP Blocks that (might) contain a CIDR block

We are working on a script to read route tables and with some automatic enrichment and human validation, add missing IP Networks (as IP4Network/IP6Network objects) to Integrity. Since creating a network requires providing the parent IP Block ID, I am wondering what the ‘right’ way is to find the parent for a CIDR range that may or may not exist as an IP?Network already in the IPAM database.I have tried the following:filter=range:contains(“204.0.113.0/24”) - which errors (because ‘contains’ doesn’t work with CIDR)filter=range:contains(“204.0.113.0”) - where I just take the lowest IP in the CIDR range. This works but seems sub-optimal to me for some reason. Maybe because I can’t be sure if the block fits the entire CIDR, though that seems unlikely to be a real problem in practice.I have also tried various forms of range:le and range:ge but (as documented) they only match on the prefix length and protocol (determined based on whether the address is v4 or v6), and so is not useful in this case.Anyway, I am reasonably certain I am missing some better way and likely obvious way that I just can’t see for some reason.Any ideas?

Customer Webinar

[Video] Integrity X Customer Webinar

Integrity X Customer Webinar This session is designed to give you a first-hand look at how Integrity X is evolving to make DDI management more intuitive, automated, and resilient.Here are some of the highlights we’ll cover:A redesigned, accessible interface that makes DHCP, IP management, and DNS investigations easier than ever. Full automation through APIs — everything you can do in the UI, you can script. Smarter visibility with tagging, real-time metrics, and built-in dashboards. Simplified operations like database backup/restore and support bundle access directly from the UI. Join Christy G, Product Manager for Integrity, to get a highlight of whats new in Integrity X!

Terms & ConditionsCookie settingsAccessibility statement