Anyone have an example of a BGP setup with a single peer and route filters they could share?

The wiki covers that: http://wiki.mikrotik.com/wiki/Manual:BGP_Case_Studies

Keep in mind there is a problem with filters in 5.x to be fixed in the next release 5.7 ;-( (at least using the gui)

(see http://forum.mikrotik.com/viewtopic.php?f=14&t=54616)

You really have only to setup the instance and peer, I found that depending on what OS I am peering with, I usually select the interface on the peer as opposed to leaving it unassigned...

an example of some filters on the outbound.. for example to make sure you don't inadvertently advertise something you don't mean to...

/routing filter

(be sure to use all combination of routes and their aggregates if appropriate)

add action=accept chain=peer1-out comment="" disabled=no invert-match=no prefix=1.1.1.0/22
add action=accept chain=peer1-out comment="" disabled=no invert-match=no prefix=2.2.2.0/22
add action=discard chain=peer1-out comment="" disabled=no invert-match=no

an example of a filter on the inbound to keep only the shortest path routes (1 or 2 as-paths)...

add action=discard bgp-as-path-length=3-32 chain=in-short-only comment="" disabled=no invert-match=no protocol=bgp

an example of a filter on the outbound to pad with additional as-path...

add action=passthrough chain=peer1-out comment="Prepend on peer1" disabled=no invert-match=no set-bgp-prepend=1

Do you have an example of pre-pending the inbound routes? I know its not called prepending in that case. Something like preference or like. Just something to make it less lkely to go out that route.

You have two options for that. You can set the BGP weight (used for local (THAT router only) BGP selection process), or you can set the local preference - that's an actual BGP attribute that is passed along to any iBGP peers you might have. Here's an example:
Similarly use commands like 'set-bgp-local-pref' to use other methods.

That doesn't make it 'less likely' to go out that route, though. The BGP route selection process is deterministic. If you get the same prefix from multiple peers setting the weight or local preference selects one of the paths over the others.

As I understand it if you prepend like so 'set-bgp-prepend=1' you are faking you are one more hop out then you really are when advertising. I would like when receiving routes to make the ones coming from a certain place to also appear one hop further out then they really are (or the received bgp info indicated they are) when my Mikrotik evaluates where or which provider to route a packet.

You want to write a policy to determine which route gets chosen, I understand that. You want to do that by padding the AS path length. That's not best practice. Best practice is to use the weight or the local preference.

http://wiki.mikrotik.com/wiki/Manual:BG ... _Algorithm

Read that to understand how the router selects the best path. First it looks at the weight and picks the route with the highest weight for the prefix. Then it looks at the local preference, and picks the route with the highest local preference for the prefix. Then it looks at the AS path length, and chooses the route with the shortest AS path to the prefix. There is no thing such as 'more likely'. BGP picks ONE best path. One. That route gets installed into the routing table.

If you want to make the AS path longer inbound so that your router doesn't pick that route, you might as well just raise the weight or local preference (which one you use depends on whether you want to share that policy with potential iBGP peers) because they achieve the same thing (influence which route gets picked) but are easier to manage, less error prone, and are evaluated earlier so it saves you processing resources.

Therefore you should write a filter that changes the weight or local preference.

You pad AS paths on OUTBOUND advertisements because it is the only mandatory well known attribute that affects the route selection process in other autonomous systems, so it is literally the only thing you can do to affect how other people see routes INTO your AS: can't use weight because it's the local system only, can't use local preference because it only works between iBGP peers. For multiple peers with one directly connected autonomous system you can use the MED, but that isn't passed on to other autonomous systems that AS in turn peers with. Inbound you have better tools, so you don't use the AS path.

Does this look right for a simple single peer BGP example?

/routing bgp instance
set default as=12xxx client-to-client-reflection=no disabled=no \
ignore-as-path-len=no name=default out-filter="" redistribute-connected=no \
redistribute-ospf=no redistribute-other-bgp=no redistribute-rip=no \
redistribute-static=no router-id=0.0.0.0 routing-table=""

/routing bgp peer
add address-families=ip as-override=no default-originate=never disabled=no \
hold-time=3m in-filter="" instance=default multihop=no name=\
xxxxxxxxxxxxxx.com nexthop-choice=default out-filter="" passive=no \
remote-address=x.x.x.1 remote-as=123xx remove-private-as=no \
route-reflect=no tcp-md5-key="" ttl=default use-bfd=no

/routing bgp network
add disabled=no network=x.x.x.0/24 synchronize=no
add disabled=no network=x.x.x.0/24 synchronize=no
add disabled=no network=x.x.x.0/24 synchronize=no
add disabled=no network=x.x.x.0/24 synchronize=no

/ip address
add address=x.x.x.2/30 disabled=no interface=ether1 network=x.x.x.x
add address=x.x.x.1/24 disabled=no interface=bridge1 network=x.x.x.0
add address=x.x.x.1/24 disabled=no interface=bridge1 network=x.x.x.0
add address=x.x.x.1/24 disabled=no interface=bridge1 network=x.x.x.0
add address=x.x.x.1/24 disabled=no interface=bridge1 network=x.x.x.0

Looks OK, but why assign IPs to a bridge? Those IPs were routed to you, you can do whatever you want with them. Bridging sucks. It doesn't scale. You should consider routing those IPs with an IGP.

PPPoE, webservers and etc sit right on that bridge. No users directly on bridge. Some of the worst things about bridging are insecurity and ARP traffic floating around network. Does not really apply here. There are other ways but this has worked well for years.

The thing I am wandering about is filters. I do not 'currently' have any listed in this example. But I have:

client-to-client-reflection=no
redistribute-connected=no
redistribute-ospf=no
redistribute-other-bgp=no
redistribute-rip=no
redistribute-static=no

So I would think the only IP's BGP would advertise would be those in '/routing bgp network' right? I should have nothing to filter out right?

Even if I had two peers I should still be ok if I am not trying to make the traffic prefer one over the other with prepends or weight right?

That's right for one peer.

If you have two peers you have to be way more careful. redistribute-other-bgp means BGP routes learned from OTHER instances. By default it will absolutely advertise any routes learned from one peer to the other if both are in the same instance. With two peers you want to make a prefix-list that enumerates all your local networks, and then apply an outbound filter allowing only those prefixes. Otherwise you risk telling peer A about networks learned via peer B. If that is the best route to a prefix for peer A, peer A will then use you as a transit to get to that prefix via peer B. That can cost you a LOT of bandwidth. Now, most ISPs should be set up to filter that kind of stuff (and in fact may require you to tell them what prefixes of your own you will advertise so they can set up inbound filters to limit what you can tell them), but not all ISPs do that.

But if I add a second peer for access only I can leave 'redistribute-other-bgp=no' off and still not have issues. If on the other hand I add a peer that wants to buy access from I will need to turn 'redistribute-other-bgp=no' on and then I will need to filter my BGP. If my thinking is right here?

No. Again, redistribute-other-bgp means BGP routes from OTHER BGP instances, for complicated BGP setups. In the vast majority of cases you have both peers against the same instance, in which case routes would be passed on unless filtered.

Rule of thumb: Whenever you have more than one peer you want to have an outbound filter unless you'd like to be a transit network, which you never do want unless you're an actual ISP that does ISP level peering with other ISPs.

No. Again, redistribute-other-bgp means BGP routes from OTHER BGP instances,

Oh, I see. Good thing I asked. I notice this under Routing/Filters:

locally-originated-bgp (yes|no;)

I could likely use that to filter out everything but 'locally originated bgp' on my outbound filter not? The documentation on that property is pretty slim though.

I can't say I've used that property before, but a quick test says this: works just fine in a lab to advertise all locally originated BGP routes when the 'bgp-out' filter is applied as an out-filter to a peer.

I've got that running in my lab on a rb433 on 5.6 towards a rb750g on 5.6 and it's only advertising routes included in "/routing bgp network". The rb433 also has a BGP session with a vyatta router and is learning a prefix it isn't redistributing to the rb750g.

That's right for one peer.

If you have two peers you have to be way more careful. redistribute-other-bgp means BGP routes learned from OTHER instances. By default it will absolutely advertise any routes learned from one peer to the other if both are in the same instance. With two peers you want to make a prefix-list that enumerates all your local networks, and then apply an outbound filter allowing only those prefixes. Otherwise you risk telling peer A about networks learned via peer B. If that is the best route to a prefix for peer A, peer A will then use you as a transit to get to that prefix via peer B. That can cost you a LOT of bandwidth. Now, most ISPs should be set up to filter that kind of stuff (and in fact may require you to tell them what prefixes of your own you will advertise so they can set up inbound filters to limit what you can tell them), but not all ISPs do that.

But what does this do if set to no?

client-to-client-reflection (yes | no; Default: yes)
In case this instance is a route reflector: whether to redistribute routes learned
from one routing reflection client to other clients.

You are probably not going to run a route reflector. Route reflectors are for large iBGP networks where you don't want to mesh all iBGP peers with one another. So that simply doesn't apply to you.

Well I added this so I should be good for now especially with just one peer at moment. Just trying to understand everything.

out-filter=x.coom-out

/routing filter
add action=accept chain=x.coom-out disabled=no invert-match=no locally-originated-bgp=yes prefix=0.0.0.0
add action=discard chain=x.coom-out disabled=no invert-match=no prefix=0.0.0.0

Thanks.

Ah, you got caught by a bug. You're using 5.6 and used the GUI (winbox) to add those? It added a field it shouldn't have (prefix=0.0.0.0). On top of that you can't unset that property from the CLI. That will make those filter entries not match.

Delete both filter entries and add this via the command line: And yes, that should work absolutely fine with one or more peers.

Fixed. Thanks!