BGP · Topic 3 of 7
Stub and Non-Stub Scenarios, Private AS Removal
Compare stub and transit autonomous systems, when a customer needs BGP at all, how private AS numbers are removed, and how to avoid becoming a transit AS.
- 5 min
- A stub AS carries only its own traffic. A transit AS carries traffic for others.
- A single homed stub normally needs only a static default route.
- A stub with several links to one provider can use a private AS number.
What it is
A stub AS only carries its own traffic, while a non-stub AS also carries traffic for other autonomous systems.
A stub network connects to the rest of the internet through one provider or a few links. A non-stub network, also called a transit AS, passes traffic between its neighbours.
The scenario decides whether you need BGP, a public AS number, and which filters are essential.
How it works
Pick the simplest design that meets the redundancy needs, then add filters to control what is advertised.
Single homed stub
A customer with one link to one provider usually does not need BGP. The customer uses a static default route toward the provider. The provider uses a static route toward the customer prefix and may announce it on the customer's behalf.
Stub with several links to one provider
If the customer has two links to the same provider, BGP can help with failover and load sharing. The customer does not need a public AS number, because the provider is the only upstream.
The customer can use a private AS number. The provider accepts the session and announces the customer prefix to the world. The private number must not leak to the internet, so the provider removes it.
Private AS removal
The private AS number appears in the AS path of the customer routes. Public peers should not see it. On RouterOS v6 the peer setting remove-private-as=yes strips private numbers from the AS path when advertising to that peer.
/routing bgp peer add name=upstream remote-address=203.0.113.1 remote-as=100 remove-private-as=yes
/routing bgp peer add name=cust remote-address=192.0.2.2 remote-as=65010 default-originate=alwaysremove-private-as=yesis applied on the peer that faces the public side.default-originate=alwaysmakes the router send a default route to that peer.
A provider can use default-originate so a stub customer receives just a default route and does not take the full table.
Multihomed to different providers
A customer connected to two different providers has a real need for BGP and a public AS number. The upstreams then see a unique AS.
The customer can receive full tables, a partial table, or only default routes. The choice depends on router memory and on how fine the control must be.
Non-stub, transit scenarios
A transit AS accepts traffic from one neighbour and forwards it to another. This needs a complete design.
- All border routers need the external routes, so iBGP is used between them.
- An interior protocol carries the internal prefixes and the next hop addresses.
- Reflectors or confederations keep the iBGP mesh manageable.
- Filters decide which neighbour may send or receive which prefixes.
Never redistribute the full BGP table into an interior protocol. The interior protocol should carry only the addresses needed to reach the BGP next hops.
The accidental transit problem
A customer connected to two providers must not advertise provider routes to the other provider. Otherwise it becomes a transit AS and carries traffic it cannot afford.
The fix is an out filter on each upstream peer that sends only the customer's own prefixes.
/routing filter add chain=to-isp prefix=198.51.100.0/24 action=accept
/routing filter add chain=to-isp action=discard
/routing bgp peer set upstream out-filter=to-ispA dual homed customer without an out filter can leak one provider's routes to the other and become a transit network by mistake.
What to remember for the exam
Seven facts cover most questions here.
- A stub AS carries only its own traffic. A transit AS carries traffic for others.
- A single homed stub normally needs only a static default route.
- A stub with several links to one provider can use a private AS number.
remove-private-as=yesstrips private numbers from the AS path on advertisement.default-originatesends a default route to a peer.- A customer with two different providers needs BGP and a public AS number.
- Out filters stop a multihomed customer from becoming a transit AS.
Ask two questions first. How many providers, and does the AS need to carry other people's traffic?
Common mistakes
These four errors are common.
Running BGP when a default route is enough. A single homed customer gains complexity and nothing else.
Letting a private AS reach the internet. Without removal, public peers see numbers that should never appear in the global table.
Redistributing BGP into the IGP. The interior protocol is overloaded and can lose stability.
Forgetting outbound filters. A multihomed customer then advertises routes it learned from one provider to the other.
Check yourself
Work through these three questions.
Which design usually needs no BGP at all?
A single homed stub, which uses a static default route toward its provider.
What does
remove-private-as=yesdo, and where is it applied?It removes private AS numbers from the AS path when routes are advertised to that peer. It is applied on the peer that faces the public side.
How does a dual homed customer avoid becoming a transit AS?
It uses an out filter on each upstream peer so that only its own prefixes are advertised.
Topic 3 of 7 in BGP
Test yourself on BGP
The full MikroTik MTCINE question bank has 475 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by MikroTik. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.