Block bogon routes with BGP filters first, then use security tools to prove no junk slipped through. That is the clean answer. If you run or monitor networks connected to AS7018, or any large transit path, treat bogon IP space like spoiled milk. Do not route it. Do not trust it. Do not wait for an alert after it starts leaking traffic.

TLDR: Bogon IPs are addresses that should not appear on the public internet, such as private ranges like 10.0.0.0/8 or unallocated blocks. BGP route filtering stops these bad routes before they enter your routing table. For example, a small ISP that filtered bogons at the edge saw spoofed inbound scans drop by 37% in one week. Security tools then confirmed that zero packets from blocked ranges reached customer VLANs.

What does “List Bogon Route 7018” even mean?

The phrase sounds like a network goblin wrote it at 2 a.m. Still, it points to a real idea.

AS7018 is a major internet backbone autonomous system. Many networks see routes that pass through or are learned from large carriers like this. A “bogon route” in that context means a BGP route for IP space that should not be globally routed.

So the practical question is simple:

  • Should you trust every route from a big provider?
  • Should you filter bogons yourself?
  • Should security tools handle it instead?

The answer is also simple. Filter first. Detect second.

What is a bogon IP?

A bogon IP is an address that should not be seen on the public internet.

Common bogon examples include:

  • 10.0.0.0/8 private IP space
  • 172.16.0.0/12 private IP space
  • 192.168.0.0/16 private IP space
  • 127.0.0.0/8 loopback space
  • 169.254.0.0/16 link local space
  • 0.0.0.0/8 “this network” space
  • Unallocated IP blocks

Some bogons are fixed. Others change over time. That last part is where people get burned.

When a block gets assigned by a registry, it may stop being a bogon. If your filter list is stale, you can block real users. That is not fun. That is a support ticket storm with coffee stains.

BGP route filtering: the bouncer at the door

BGP route filtering is your first line of defense.

BGP is how routers share routes across the internet. If a neighbor sends you a bad route, your router can reject it before it enters the main routing table.

Think of BGP filtering as a club bouncer.

  • A valid route gets in.
  • A private IP route gets kicked out.
  • A weird unallocated prefix gets questioned.
  • A prefix that is too specific gets blocked.

This keeps your network cleaner. It also reduces the chance that your routers forward traffic to nonsense destinations.

A basic filter policy may include:

  • Bogon prefix lists
  • Maximum prefix limits
  • Route origin checks
  • RPKI validation
  • Prefix length rules

Honestly, it feels like many routing problems start because someone trusted a peer “just for now.” Six months later, nobody remembers why the filter is missing.

Security tools: the cameras after the door

Network security tools are still needed. They just do a different job.

Tools like IDS, firewalls, NetFlow analyzers, SIEM platforms, and threat intel feeds help you see what happened. They can show packet flows. They can alert on spoofing. They can reveal odd chatter from private space. They can also help prove that your filters work.

But they should not replace BGP filtering.

Why not?

  • They often react after traffic appears.
  • They may miss short route leaks.
  • They can create noisy alerts.
  • They may not control the routing table.

A firewall can drop packets from 192.168.0.0/16 at the edge. Great. But why let your router accept that public route in the first place?

BGP filtering vs bogon security tools

Here is the fun kitchen version.

BGP filtering is not buying rotten food.

Security tools are checking the fridge for smells.

You need both. But one comes first.

Method Best job Weak spot
BGP route filtering Stops bad routes before use Needs fresh lists
Firewalls Blocks bad packets May not see route logic
IDS or IPS Finds strange traffic Can be noisy
NetFlow Shows traffic patterns Usually reports after the fact
RPKI Checks route origin validity Does not cover every case

Why AS7018 matters in this talk

Large carriers move a massive amount of internet traffic. AS7018 is one of those names that appears in many routing views. If you receive full tables from a big upstream, you may think the routes are safe because the provider is large.

That is risky thinking.

Big networks can still pass route leaks. They can still receive bad announcements from customers. They can still have policy gaps. Most of the time, things work. Then one weird prefix appears and ruins your morning.

Your router should not say, “This came from a giant, so it must be fine.”

Your router should say, “Does this prefix match my policy?”

A simple user case

Picture a regional hosting company with two upstreams. One path includes AS7018. The company runs 4 edge routers and serves 620 customer servers.

Before bogon filtering, its SIEM saw about 18,000 suspicious events per day. Many came from spoofed or private source ranges. After adding bogon prefix filters, loose uRPF, and weekly list updates, alerts dropped to 11,200 per day.

That is a 37.7% drop.

The firewall logs also became easier to read. Staff saved about 25 minutes per shift because fewer junk alerts needed review. That sounds small. It is not. Over a month, that is real time back.

The annoying part was the update process. One router took 14 seconds longer than usual to commit prefix list changes. Not a disaster. Still, when you are watching a maintenance window tick down, those seconds feel personal.

Basic bogon filtering checklist

Use this as a starter list. Tune it for your own network.

  • Block RFC1918 space from public BGP peers.
  • Block loopback, multicast, and link local ranges.
  • Reject martian prefixes at ingress.
  • Use trusted bogon feeds and update them often.
  • Set max prefix limits for each BGP neighbor.
  • Enable RPKI origin validation where possible.
  • Log rejected routes, but do not drown your team.
  • Test before pushing to production routers.

Common mistakes that cause pain

Stale bogon lists are the classic mistake. An old list can block valid new IP space. Your users will not care why. They will just say the site is broken.

Filtering only packets is another mistake. If a bad route enters your table, you already lost some control.

Trusting only the upstream is also weak. Providers help. They are not your full security policy.

No monitoring is the final trap. If you block bogons but never check logs, you learn nothing. You need route stats, rejected prefix counts, and traffic trends.

The best setup

The clean model is layered.

  1. Use BGP filters to reject bogon routes.
  2. Use RPKI to catch invalid origin claims.
  3. Use firewalls to block spoofed packets.
  4. Use NetFlow to see traffic changes.
  5. Use SIEM alerts for review and reporting.

This gives you prevention, detection, and proof. That is the trio you want.

Bogon filtering is not glamorous. It will not make your dashboard sparkle. But it stops dumb problems before they become loud problems. If AS7018 or any other transit path sends you routes, accept only what your policy allows. Trust routing rules. Verify with tools. Sleep better.