Tagged: bgp
33 posts · browse all tags
-
FortiGate BGP Cookbook Part 1: Dual-ISP Edge Recipes
Six FortiGate BGP recipes for a dual-homed internet edge: stop being a transit AS, accept only a default route, steer traffic in both directions, advertise a prefix with no connected route, originate a default, and authenticate the session with TCP-AO.
-
FortiGate BGP Cookbook Part 2: Verify and Debug
The commands I run after every FortiGate BGP change: read the session, compare received and advertised routes before and after policy, soft-clear safely, triage a session that will not establish, and run BGP debug without leaving it on.
-
BGP Deep Dive Part 1: The Application That Runs Between Autonomous Systems
The first post in a deep dive into BGP. Why EGP failed, the two napkins that became RFC 1105, and the distinction that took a bad Halabi read and a good Doyle read to finally land: an IGP finds the best path inside a network you own, BGP negotiates policy between networks you don't.
-
BGP Deep Dive Part 10: Multiprotocol BGP, or How One Session Learned to Carry Everything
RFC 4760 turned BGP from an IPv4-unicast-only protocol into a generic reachability-advertisement transport. Here's how AFI/SAFI, MP_REACH_NLRI, and one session carrying multiple address families actually works.
-
BGP Deep Dive Part 11: Convergence, Stability, and Scale
Route flap dampening, graceful restart, BFD, and ADD-PATH: four mechanisms that shape how fast, how stable, and how scalable a BGP deployment actually is.
-
BGP Deep Dive Part 12: Security, or Why BGP Trusts You Until Proven Otherwise
BGP was built on trust between operators, not cryptographic proof. Real hijack incidents, RPKI/ROV, BGPsec, and MANRS: what actually protects the internet's routing today.
-
BGP Deep Dive Part 2: The Session, From TCP SYN to Established
Part 2 of the BGP Deep Dive: TCP port 179 and why BGP needed a transport layer at all, the full six-state finite state machine from Idle to Established, what the OPEN message actually negotiates, and the hold timer, keepalive, and session-security mechanics underneath it.
-
BGP Deep Dive Part 3: The UPDATE Message and the Attribute Catalog That Is BGP's Actual Policy Engine
Part 3 of the BGP Deep Dive: the UPDATE message's real structure, RFC 4271's four categories of path attribute, and a walk through ORIGIN, AS_PATH, NEXT_HOP, MED, LOCAL_PREF, ATOMIC_AGGREGATE, and AGGREGATOR, including the classic unreachable-next-hop gotcha.
-
BGP Deep Dive Part 4: The Best Path Algorithm, Step by Step
Part 4 of the BGP Deep Dive: the full best path selection algorithm that consumes every attribute from Part 3, walked step by step from Cisco-proprietary Weight down to the final router-ID tiebreak, including why hot-potato routing is baked into step 8, not a separate design choice.
-
BGP Deep Dive Part 5: eBGP and iBGP Are Not the Same Protocol Wearing One Name
Part 5 of the BGP Deep Dive: why AS_PATH loop prevention does nothing inside an AS, the iBGP split-horizon rule that actually prevents internal loops, and why that one rule is the direct, mechanical reason full-mesh iBGP exists at all.
-
BGP Deep Dive Part 6: Route Reflectors and Confederations, Two Ways to Break the Full Mesh
Part 6 of the BGP Deep Dive: RFC 4456 route reflection and RFC 5065 confederations, the two sanctioned ways to relax iBGP's full-mesh requirement from Part 5 without giving up its loop safety, plus the path-hiding tradeoff route reflection quietly introduces.
-
BGP Deep Dive Part 7: Communities, BGP's General-Purpose Signaling Channel
Part 7 of the BGP Deep Dive: standard communities from RFC 1997, extended and large communities that fixed their real limitations, the three well-known values every implementation understands, and why the whole mechanism only works because two networks agree on what a number means.
-
BGP Deep Dive Part 8: Policy in Practice, Prefix Filters, AS-Path Filters, and RFC 7454
Part 8 of the BGP Deep Dive: the actual tools operators use to apply policy, prefix filtering, AS-path filtering, the route-map pattern every vendor implements some version of, and RFC 7454's real operational recommendations for filtering, max-prefix limits, and session hardening.
-
BGP Deep Dive Part 9: Traffic Engineering, or Why Outbound Is Easy and Inbound Never Fully Is
Part 9 of the BGP Deep Dive: multihoming and traffic engineering using nothing but attributes this series has already covered. Outbound TE is a solved problem with LOCAL_PREF. Inbound TE never fully is, and this post explains why prepending, MED, and communities are all, honestly, best-effort.
-
Route Leaking Between VRFs on FortiGate: What Happens When You Actually Build It
I set out to build the BGP leak-target VRF route-leaking mechanism from my own earlier post, on a real FortiGate 70G. It hit three undocumented platform quirks in a row. The real answer turned out to be a static route over a VDOM-link — no BGP required.
-
Cloud On-Ramp Part 1: The Architecture Decision and AWS Transit Gateway
Hub Placement Part 3 said the hub goes where the VPC is. This post answers the question that raises immediately: how does it actually get there? BGP-over-IPsec to AWS Transit Gateway, ASN selection, and mapping on-prem VRFs onto TGW route tables.
-
Cloud On-Ramp Part 2: Azure Virtual WAN and a Dual-Cloud Resilience Design
Azure Virtual WAN looks like AWS Transit Gateway from a distance — a managed hub that attachments plug into. Up close, the BGP mechanics, the route-propagation model, and the failure modes all differ in ways that decide whether a dual-cloud on-ramp actually survives a bad day.
-
Fortinet SDWAN Hub Placement Part 1: The Traditional Model — Hubs in the DC
Why hubs traditionally sit in the DC, the job they actually do there, how they protect FMG/FAZ, and how BGP on loopback ties it together. Part 1 of a series that goes on to challenge the assumption that the hub belongs in the DC at all.
-
Fortinet SDWAN Hub Placement Part 2: The MSSP Shift — When the Hub Becomes Customer-Centric
What changes when one FMG/FAZ pair manages many customers through ADOMs: the hub stops being "the DC's hub" and becomes a per-customer design decision, with its own routing domain, AS plan, and placement logic.
-
Fortinet SDWAN Hub Placement Part 3: Cloud, SASE, and the Death of "The DC" as the Default
Closing out the hub-placement series: what changes about hub design when the destination is Azure, AWS, or GCP rather than a DC, and what changes again for customers migrating from a DC-centric WAN to a SASE-centric one.
-
BGP Route Dampening Part 1: The Flapping Problem, Exponential Decay, and Cisco Configuration
A deep dive into how BGP route dampening works: the 1990s internet instability that created it, the exponential decay algorithm behind it, every Cisco parameter explained, and a full configuration and verification reference.
-
BGP Route Dampening Part 2: RFC 7454, BFD, and Where Dampening Still Belongs
Why the IETF now discourages global BGP route dampening, how Bidirectional Forwarding Detection interacts with it, what RFC 7454 actually says, and the specific modern scenarios where dampening remains the right answer.
-
SDWAN Resilience Part 1: Design and Assumptions
A multi-part deep dive into building a resilient Fortinet SDWAN on a real, slightly unfashionable topology — HA FortiManager, dual hubs in active/standby, no DCI, and an independent DCE. Part 1 lays out the topology, the AS plan, and challenges the design choices up front.
-
SDWAN Resilience Part 2: BGP on Loopback
Why we peer BGP on loopbacks instead of tunnel-interface IPs, the FortiOS dynamic-IPsec config that makes it work, the spoke-side reciprocal config, and why hub-to-hub iBGP is the wrong answer in a no-DCI active/standby topology.
-
SDWAN Resilience Part 3: DC to DCE Routing — Static, OSPF, and BGP
The hub FortiGate has to glue the spoke overlay to the data-centre environment that hosts the services. Static, OSPF, and eBGP each work — but only two of them fail correctly when the DCE peering goes down on one DC and not the other.
-
SDWAN Resilience Part 4: BFD and Convergence Tuning
Default BGP timers detect failure in three minutes. That's unacceptable for active/standby SDWAN. This post is the timer-math: DPD vs BFD on tunnels, BFD-for-BGP, holdtime ratios, the Graceful Restart trade-off, and what convergence numbers each combination actually delivers.
-
SDWAN Resilience Part 5: Performance SLAs and Service Steering
BGP and BFD catch every failure that takes a tunnel or session with it. They don't catch the failure where everything looks healthy at the network layer but the application is gone. That's the gap SDWAN Performance SLAs fill — and the place where careful health-check design earns its keep.
-
SDWAN Resilience Part 6: Building It Right — Full DCI and Dual-Active ADVPN
The first five parts defended a topology with real constraints. This final post is the version without those constraints — Fortinet's reference design: full DCI, dual-active ADVPN, iBGP between hubs, symmetric routing, ECMP across both paths. The full shebang.
-
FortiOS 7.6.6 SDWAN: VRF1 Transport and Loopback Design
A refined VRF reference design for FortiOS 7.6.6 — transport in VRF 1, separate transport and management loopbacks, complete management-plane pinning, and NPU-VLINK guidance for inter-VRF acceleration.
-
MP-BGP and VRFs on FortiGate SDWAN
A practical reference design using MP-BGP (VPNv4) and VRFs on FortiOS to keep management (VRF20), customer SDWAN (VRF30), and Guest Wi-Fi DIA (VRF99) isolated end-to-end. Includes config, traffic flows, and the gotchas that bite people in production.
-
Linux Networking from the Ground Up: Network Namespaces, veth Pairs, and Building a Multi-Router Lab on One Host
Build a real multi-router BGP and OSPF lab on a single Linux box using network namespaces, veth pairs, and FRRouting — no VMs, no containers, no GNS3. A practical walk-through of the primitives that GNS3, Docker, and Kubernetes are quietly using under the hood.
-
Route Leaking Between VRFs on Cisco IOS: From BGP First Principles to Advanced Manipulation
A practical end-to-end walkthrough of route leaking between VRFs on Cisco IOS — starting with the BGP and VRF fundamentals you need to actually understand what's happening, the static and MP-BGP options for the leak itself, and the route-map machinery that lets you control exactly what crosses.
-
Route Leaking Between VRFs on FortiGate: Why It's Trickier Than You Think
VRF route leaking is a daily reality in any multi-tenant or shared-services network design. On FortiGate it's harder to find — and harder to get right — than the equivalent on Cisco or Juniper. Here's how to do it, why it's easy to miss, and the practical pitfalls.