BGP

BGP is how separate networks on the internet tell each other which address ranges they hold. You need it when you have your own AS number and your own IP space, or when you have an agreement with a party that does. If you have neither, you do not need BGP, however often it comes up in conversations about redundancy.

This chapter is about what the tool sets up for you and, just as important, where it stops.

Where it lives

In the Routing (OSPF, BGP, policy) section, in the BGP group. That section is off by default. In the wizard it is part of the Core router role, in the Routing step, together with the addresses and OSPF.

The fields

Local AS

Your own AS number. Required, because nothing is generated without it. For a private setup between your own routers, use a number from 64512 to 65534.

Router-ID

Leaving it empty means: the loopback address you entered at the top of the section. If you left that empty too, fill this one in.

Networks to advertise

Comma-separated prefixes, for example 192.0.2.0/24. This is what you offer to the world.

Below that is the peers table. Per peer:

• A name and the peer address.
• Remote AS. If that is the same number as your own AS, the tool makes it an iBGP session; otherwise eBGP. So you do not have to make that choice yourself.
• Local address, optional. Fill it in when the session has to come from a particular address, your loopback for instance.
• TCP MD5 password, optional. Leave it empty and the tool warns you. Do not leave it empty: a session without a password is a session someone else can try to bring up.
• Multihop, when the peer is not in a directly connected subnet.
• Accept default only. The next section is about that one.

Full table or just a default

This is the choice that matters most, and it sits in a single switch.

Leave Accept default only off and the router takes what the peer sends. From a transit provider that is the full internet table: well over a million prefixes at the time of writing. That costs memory and it costs time while the session comes up. On a CCR with enough RAM that is fine; on an RB5009 or smaller it usually is not.

Switch it on and you get only the default route from that peer. For this the tool generates a filter chain bgp-in-default-only that rejects everything except 0.0.0.0/0, and attaches it to the session as input.filter. For most connections with one or two transits this is what you want: a working way out without carrying the whole table.

The practical rule: if you only want redundant internet, take a default. If you genuinely want to choose per destination which transit to use, you need the full table, and you also need the router that can hold it.

What the tool generates

• If you entered networks, an address list bgp-networks in /ip firewall address-list holding your prefixes.
• /routing bgp template set default with your AS, the router id and, when networks exist, output.network=bgp-networks.
• Two filter chains under /routing filter rule: bgp-in-default-only as described above, and bgp-out-networks, which lets only your own prefixes out and rejects the rest.
• Per peer a /routing bgp connection with the name, the default template, remote.address and remote.as, the iBGP or eBGP role, optionally local.address, multihop and tcp.md5-key, the outbound filter chain, address-families=ip and routing-table=main.

That outbound filter is the most important line in the whole block. Without one, a misconfigured router can pass routes it learned from one peer on to another, and then you are transit for people who never asked for it. So the tool always sets a filter that lets only your own networks out. If you entered no networks, the chain is reject: you announce nothing.

Check it with /routing bgp session print for the status and /ip route print where bgp for what is coming in.

Where the form stops

This is the part where the tool is at its most modest, and that is on purpose. BGP is negotiation, not form filling.

• Filters are hand work. The two chains you get are a safety net, not a policy. Prefix lists, AS path filters, communities, local preference, MED, prepending: none of that comes out of this form. What your peer expects from you is in the agreement with that peer, and you type it yourself in /routing filter rule.
• No max prefix. No limit is set on how many prefixes a peer may send. With a full table that is something to add yourself.
• No RPKI. Route origin validation is not in the tool.
• IPv4 only. The sessions get address-families=ip. For IPv6 you add an address family or a second session yourself.
• One routing table. Everything goes into main. No VRFs.
• A v6 BGP configuration is not converted. As with OSPF, /routing bgp lines from a RouterOS v6 export are kept as comments labelled "convert by hand", routing filters included. The BGP implementation was rewritten in v7; guessing automatically would do real damage here.

So use this block as a starting point: the sessions come up, your own prefixes go out and nothing else, and then you finish the policy on the device.

Read on

OSPF for routing inside your own network, Static routes and policy routing when BGP is too much, and From RouterOS v6 to v7 for what does and does not get converted on import.