In 20 years, you will be more dissapointed by what you didn't do than by what you did.

Showing posts with label Troubleshooting. Show all posts
Showing posts with label Troubleshooting. Show all posts

BGP Weight Explained: Local Path Preference, Outbound Control and Troubleshooting

Short answer: BGP Weight is a local path-selection value used by Cisco-style BGP implementations to make one router prefer one BGP path over another. Higher Weight wins, Cisco documents it as the first best-path comparison step, and Cisco also states that Weight is local to the router where it is configured.[1][2]

Use Weight when one router needs a local outbound preference. Use LOCAL_PREF when the whole autonomous system should agree on an outbound exit. Do not use Weight when you expect a policy to propagate through iBGP, influence inbound Internet traffic, or become a portable standards-based BGP attribute.

Read More ->>

BGP MED Explained: Inbound Traffic Influence, Limits and Troubleshooting

Short answer: BGP MED, also called MULTI_EXIT_DISC, is an optional non-transitive BGP attribute used to suggest which entry point a neighboring autonomous system should use when it sends traffic into your AS. RFC 4271 defines it as a four-octet value that can help discriminate among multiple entry points to a neighboring AS, and Cisco and Juniper both document the operational rule most engineers remember: lower MED is preferred when MED is compared.[1][2][4]

The practical catch is important: MED is a hint, not a command. It can influence inbound traffic from a directly connected neighboring AS, but it does not override that neighbor's local policy, local preference, AS-path decisions, hot-potato routing, or provider-specific traffic-engineering rules.

Read More ->>

BGP LOCAL_PREF Explained: Outbound Traffic Control, Policy and Troubleshooting

Short answer: BGP LOCAL_PREF is the cleanest attribute for choosing which exit point your autonomous system uses for outbound traffic. Higher LOCAL_PREF wins inside the local AS, it is carried across iBGP, and it is not advertised to external BGP neighbors because RFC 4271 defines LOCAL_PREF as a well-known discretionary attribute used inside an AS.[1]

If you remember one rule, remember this: use LOCAL_PREF to choose your outbound exit; do not expect it to directly force how the Internet sends traffic back to you.

Read More ->>

Prisma SD-WAN Traffic Using the Wrong Link: Path Policy Troubleshooting Matrix

A branch has two healthy circuits, yet an application keeps using the link you did not expect. Before changing circuit priorities, separate three questions: did the intended rule match, was the preferred path eligible, and what did the configured selection mode actually optimize? This troubleshooting matrix is designed to answer those questions without turning a narrow application issue into a branch-wide routing change.

Scope: Prisma SD-WAN ION path policies, not PAN-OS Policy-Based Forwarding or the separate PAN-OS SD-WAN plugin. The tables below are original operational worksheets, not recorded customer incidents. Device tests are proposed, not executed. The current Administrator’s Guide is the reference for policy controls; the older Dynamic Path Selection paper supplies background on affinity and session behavior, not a universal description of every newer selection mode.[2][1]

Read More ->>

Palo Alto PBF Failover Not Working: Dual-ISP Troubleshooting Checklist

A backup internet circuit is not useful if the firewall keeps selecting a broken path—or switches paths but the application still cannot reconnect. Use this Palo Alto policy-based forwarding (PBF) checklist to separate rule selection, path monitoring, fallback routing, NAT and return-path faults before changing production policy.

This is an original diagnostic worksheet for a hypothetical dual-ISP branch, not a recorded lab result. Product behavior is anchored to the PAN-OS 11.1 documentation and a Palo Alto LIVEcommunity technical article; validate it against your installed release. It is not a Prisma SD-WAN or firewall HA configuration guide.

Read More ->>

GPUDirect RDMA Slow or Not Working? GPU-to-NIC Troubleshooting Matrix

A GPU cluster can have active network ports and still fail to move GPU-resident data efficiently. The useful search question is not simply “is InfiniBand working?” It is: does the intended GPU-to-NIC path work, and what changes when the buffer moves from host memory to GPU memory? NVIDIA recommends that host-versus-GPU comparison when troubleshooting GPUDirect RDMA.[5]

This guide provides a staged test matrix, a hypothetical 256-GPU coverage worksheet and an evidence-based acceptance checklist. It targets the boundary between server topology, GPU-memory registration and network transport—not general collective tuning. All hardware layouts and planning thresholds below are illustrative. Commands are unexecuted examples; only the sizing worksheet was executed for this article. No GPU benchmark results are claimed.

Read More ->>

F5 Pool Member Up but Application Down: Readiness Monitor Troubleshooting Checklist

A green pool member is not a promise that a customer transaction will work. If your search is “F5 pool member up but application down,” begin by writing down exactly what the monitor tests: destination, port, request, response match and application dependency. BIG-IP can check specific returned content, but an empty receive expression can accept any retrieved content; leaving both send and receive strings empty reduces the check to a connection test.[1]

This guide provides a false-green troubleshooting matrix, a reusable readiness-monitor worksheet and a controlled failure acceptance test. It is an original design example, not a report of tests executed on a BIG-IP appliance. Documentation references cover the cited BIG-IP monitor concepts and the 15.1 HTTP-monitor configuration procedure; verify field names and behavior on your installed release before making changes.

Read More ->>

InfiniBand P_Key Troubleshooting: 256-GPU Partition Design and Test Matrix

An InfiniBand link can be active while the application is still unable to reach its peers. For a shared AI cluster, the useful question is not simply “is the fabric up?” It is “which workload ports should communicate, through which partition, and can we prove the unwanted paths are blocked?” This guide provides a partition inventory worksheet, a worked 256-GPU example and a deployment test matrix.

Scope: this is a hypothetical design and an unexecuted fabric configuration example, not a benchmark or a validated production deployment. The worksheet arithmetic was executed locally. Configuration behavior is grounded in the version-pinned NVIDIA MLNX_OFED documentation and the UFM documentation linked below; confirm the corresponding behavior on your installed release.

Read More ->>

Palo Alto Traffic Log Aged Out: Troubleshooting Matrix and Packet Capture Checklist

An allowed Palo Alto session ending with aged-out is not, by itself, proof that the firewall blocked the connection. Palo Alto defines allow as a session allowed by policy, while aged-out describes why a session ended.[3] The useful question is: did the application complete its transaction, and if not, where did the expected packet disappear?

This guide provides a reusable troubleshooting matrix, a NAT-aware capture worksheet and an acceptance checklist. It focuses on traffic passing through a PAN-OS firewall managed directly or through Panorama, not Prisma SD-WAN ION diagnostics. The workflow and hypothetical examples are recommendations, not results from a production incident or an executed lab.

Read More ->>

F5 BIG-IP Client IP Missing: X-Forwarded-For Troubleshooting Checklist

An application behind F5 BIG-IP works, but every access-log entry shows the load balancer instead of the visitor. Before disabling SNAT, separate two requirements: preserving the packet source address and conveying a client address in an HTTP header. BIG-IP SNAT changes the source address of a connection; an HTTP profile can insert client-address information into a request without undoing that translation.[1][2]

This troubleshooting guide provides a reusable decision table, a narrowly scoped NGINX configuration example, and an acceptance matrix for detecting spoofed or incorrectly trusted X-Forwarded-For headers. The examples are hypothetical and unexecuted on BIG-IP or NGINX; the workflow is an original operational recommendation, not a vendor-certified deployment recipe.

Read More ->>

Palo Alto User-ID Wrong User: IP Mapping Troubleshooting Matrix

An application is blocked for the right employee, but the Palo Alto firewall log shows a different username. Before changing the Security policy, answer a narrower question: which identity source associated this connection with that user, and was an IP address alone enough to identify them?

This guide provides a User-ID troubleshooting matrix, a read-only evidence workflow and a change-acceptance checklist. It focuses on incorrect or missing IP-to-user mappings, including the shared-IP case on terminal servers. All examples are hypothetical; commands are templates, not results from a production firewall.

Read More ->>

Slurm Job Pending with Idle GPUs: A 256-GPU Sizing and Troubleshooting Checklist

A Slurm job can remain pending while a dashboard shows dozens of idle GPUs. Before buying more accelerators or changing the fabric, ask a narrower question: can the scheduler assemble the exact node, GPU, CPU, memory, policy and locality shape requested by this job? A cluster-wide free-GPU total is not enough to answer it.

This guide provides a 256-GPU capacity worksheet, a pending-job troubleshooting matrix, two original diagrams and a deployment checklist. The design and queue snapshots are hypothetical; the arithmetic was executed in Python. Configuration and diagnostic commands are unexecuted examples, not results from a production cluster. They require adaptation to your installed Slurm release and site policy.

Read More ->>

Panorama Out of Sync: Commit and Push Troubleshooting Checklist

Panorama commit succeeded, but the firewall still shows an old setting—or the managed-device view says out of sync. Do not start by selecting Force Template Values. First identify which boundary failed: commit to Panorama, push selection, the firewall job, or the effective configuration on the target.

This guide provides a reusable troubleshooting matrix and push approval worksheet for that investigation. It is a proposed operational workflow, not a report of a production incident or an executed firewall test. Product behavior is grounded in the PAN-OS 11.2 Commit Operations reference and the vendor's Templates and Template Stacks page; check the matching documentation for your deployed release.[1][3]

Read More ->>

F5 BIG-IP Server SSL Handshake Failed: SNI and Certificate Troubleshooting Matrix

A browser reaches the F5 virtual server, the pool looks healthy, yet the application fails after a backend certificate renewal. Before changing ciphers or disabling certificate checks, identify which TLS conversation fails. This guide provides a Server SSL troubleshooting matrix, a profile-review worksheet and a controlled acceptance test plan.

Scope: conventional BIG-IP LTM reverse-proxy TLS termination with re-encryption to HTTPS pool members—not TLS passthrough, SSL Orchestrator or forward proxy. Recommendations below are an original operational workflow, not results from a production incident or a completed lab. F5's BIG-IP 17.5.1 SSL administration guide is the main configuration reference; the older v14 TMSH reference is used only for explicitly identified command and field semantics.[4][3]

Read More ->>

RoCE PFC Buffer Sizing Guide: 400G Headroom Worksheet and ECN Checklist

A GPU cluster can pass a quiet link test and still collapse under synchronized traffic. Before buying switches with a bigger advertised buffer, ask a more precise question: how much traffic can arrive after a congested port requests a pause, and where can that traffic be stored? This guide provides a headroom worksheet, an incast calculation and a deployment test matrix for that decision.

The worked design is hypothetical: 32 servers, eight GPUs per server, and a selected 400 Gb/s Ethernet fabric. Calculations are executed arithmetic, not benchmark measurements or validated switch settings. The configuration examples are explicitly pinned to NVIDIA Cumulus Linux 5.9 documentation; they are not claims about the newest release or every Spectrum generation. Use your actual ASIC, network operating system and NIC support matrix before making changes.

Read More ->>

Palo Alto SSL Decryption Breaking Applications: Troubleshooting Matrix and Exception Checklist

When an application stops working after SSL decryption is enabled, the useful question is not simply “should we bypass it?” It is: which connection leg failed, which certificate did the client receive, and what evidence distinguishes a trust problem from certificate pinning? This guide provides a troubleshooting matrix, a controlled comparison workflow and an exception-review worksheet for Palo Alto Networks SSL Forward Proxy deployments.

Scope: outbound SSL Forward Proxy, not inbound inspection or a GlobalProtect portal certificate. The worksheets and hypothetical example are original operational recommendations, not a report of executed firewall tests. Confirm menus, log availability and supported settings against your PAN-OS release and management platform before using them.

Read More ->>

Popular Posts