---
title: "Discussion on \"BGP ORF: Stop Unwanted Updates—Keep Your Free /48 Sessions Lean\" | Hashnode"
description: "Discussion on \"BGP ORF: Stop Unwanted Updates—Keep Your Free /48 Sessions Lean\". Disclosure up front: I run IPYE, a company that leases IP space. Most of this article is practical how-to; IPYE appears where a free /48, LOA, or ROA helps you try the work, with a short call to actio"
url: "https://hashnode.com/posts/bgp-orf-stop-unwanted-updates-keep-your-free-48-sessions-lean/6af271a84e969c99b1145131"
---

[Feed](https://hashnode.com/feed) /

Discussion

# [BGP ORF: Stop Unwanted Updates—Keep Your Free /48 Sessions Lean](https://ipye-com.hashnode.dev/bgp-orf-stop-unwanted-updates-keep-your-free-48-sessions-lean?utm_source=hashnode&utm_medium=feed)

Disclosure up front: I run IPYE, a company that leases IP space. Most of this article is practical how-to; IPYE appears where a free /48, LOA, or ROA helps you try the work, with a short call to actio

4d ago · 6 min read · ipye-com.hashnode.dev  
Read the article

-   [#bgp](https://hashnode.com/tag/bgp)
-   [#networking](https://hashnode.com/tag/networking)

## Written by

[IPYE](https://hashnode.com/@ipye)

@ipye

  
[View profile](https://hashnode.com/@ipye)

## Responses 1

Markdown supported · ⌘↵ to post

[OneLifeVibe](https://hashnode.com/@onelifevibe)

[4d ago](https://hashnode.com/posts/bgp-orf-stop-unwanted-updates-keep-your-free-48-sessions-lean/6af271a84e969c99b1145131/comment/6af3343d85b443493d1d5a68)

This is a useful framing — ORF as an optimisation on top of local filters, not a replacement for them. The fail-closed point stood out to me: if a peer ignores the ORF advertisement, the local inbound prefix-list still has to do the work, so a shrinking received-prefix count is a nice signal but not a safety guarantee on its own. I also liked the caution about filtering so aggressively that soft failures become invisible, and treating allow-list edits like firewall changes. One question: in your FRR lab, did you find the route-refresh behaviour after an allow-list change reliable enough to trust without a session reset, or did you end up bouncing the session to be sure the peer applied the new entries?