Does anyone have a good link on how to properly configure BGP route reflectors on Mikrotik OS? We will eventually have about 15 MikroTIk RouterOS routers running ibgp peers between them and are trying to get all our full internet Ebgp routes (from several upstream providers) and internal iBGP routes to properly propagate across the entire network. We are planning on solely using BGP for routing on this network. We currently are running into issues with the latest couple routers getting some recursive routes and routing loops for some of the new ibgp advertised networks. Rather than meshing the entire IBGP network (which would result in hundreds of peers) I assumed we could just turn on route reflection, but this seems easier said than done. I originally thought that this would be as simply as turning on route reflect on every ibgp peer and making sure each bgp instance (one per router with our AS #) had client to client reflection turned on.

This doesn't seem to be quite right and from what I have been reading I need to designate only several routers as route reflectors and not all of them, but I'm not sure how the best way to do this is. What do you think? Am I going about this the right way or should I use another protocol such as OSPF for my internal routes and just redistribute them into BGP where I connect to my upstream providers?

# Route Reflector # Clients

How do we configure iBGP peers if we want to have two Route Reflectors for redundancy? Do we have to configure peering between RR? If yes, do we have to enable "route-reflect" on this particular peering between the two?

Silly question why not use ospf for internal routing ?

Because I am using BGP por MPLS IP VPN. I am also using OSPF for backbone routes

How do we configure iBGP peers if we want to have two Route Reflectors for redundancy? Do we have to configure peering between RR? If yes, do we have to enable "route-reflect" on this particular peering between the two?

Did you ever get an answer to this question?

2 x Route Reflectors ... 100 clients including 3 or 4 "edge" routers which talk BGP to your upstreams (for example)

Do you configure the RR to talk to each other with route-reflect=yes or no ?

Also worth confirming, should the clients all be on the same subnet or can they be multiple hops (segments) away?

in our scenario we use OSPF for internal routes and then want the "clients" to route out based on various BGP options (MED/priority/etc)

Jon

It is the same as IOS and JunOS...

Set all client connection on your RR's to reflect.
On the sessions between reflectors DO NOT set them to reflect routes.

Also make sure both RR's have the cluster ID set the same.

Bingo, clustered Route Reflectors

Also to answer your other question, yes you can have your clients multiple hops away from the reflector. This requires the use of loopback interfaces and OSPF for reachability.

This is a fairly advanced topic, I would suggest you understand OSPF and BGP fully before trying to implement this, and test your understanding in a lab before trying to deploy to production.

hello, my routes learned by RR appear unreachable in the peers, why is that?

hello, my routes learned by RR appear unreachable in the peers, why is that?

Most likely your border routers' Internet attachement circuits' IP ranges are not being advertised into your OSPF.

iBGP does not modify the next hop address when it propagates prefixes. So if you have some Border router connected to an ISP on a circuit addressed as 192.0.2.64/30, for instance, then 192.0.2.64/30 would need to be reachable in your OSPF. So this border router announces prefixes learned from ISP1 to your route reflector (RR1) - the next hop of each such prefix will be 192.0.2.65. If some other BGP router (R2) in your AS receives some prefix 8.8.8.0/24 with next hop 192.0.2.65, then R2 will need to perform a recursive next-hop lookup for 8.8.8.0/24 - i.e. what local next hop is the best one for reaching 192.0.2.65? Whatever hop that turns out to be will then be used as the actual next hop IP for 8.8.8.0/24 in the RIB on R2.

TL/DR:
On your border routers, be sure to add network=x.x.x.x/30 for each ISP-facing interface, and set them as passive interfaces in OSPF so that iBGP peers will know how to reach the ISP.

The other likely possibility is that if you have made changes to the default scope/target scope configuration on your routers, you've accidentally caused them to fail at recursive lookups, but this is far less likely.

You need to configure both Route-reflector in the same cluster ID.

Others has all ready provided insights to your question. I just had one more. When using MT as a route reflector and if you follow guides that the reflector actually not participating in the data path.

MT will only reflect installed routes it can't currently (it has been asked for) be pure reflector only (without fib update)

hello, my routes learned by RR appear unreachable in the peers, why is that?

Most likely your border routers' Internet attachement circuits' IP ranges are not being advertised into your OSPF.
...
On your border routers, be sure to add network=x.x.x.x/30 for each ISP-facing interface, and set them as passive interfaces in OSPF so that iBGP peers will know how to reach the ISP.

Or set next hop to be force self towards the RR on the clients, if you don't want to advertise external networks into your OSPF domain.

You need to configure both Route-reflector in the same cluster ID.

This is not a requirement, and can actually black hole traffic if not thought carefully. If not all clients are fully-meshed to both route reflectors, or you have multiple link failures, the route reflectors may not forward routing information to their connected peers due to the cluster IDs being the same. In certain topologies, setting the same cluster ID on both route reflectors is a bad thing.

Actually, according to the RFC 4456 (https://tools.ietf.org/html/rfc4456) it's a must, even when you configure a big network with multiple RR, then you can add different Cluster-IDs. One of the best practices is exactly what you said, each router need to be configured as a route-reflector client for both route-reflectors, that's the point of installing two RRs. However, i'm wondering in wich topologyes may the redundant router reflectors configured within the same cluster-id may generate an issue??

Can you please point out the part in the RFC that says you must use the same ID on all members of the same cluster?

I was going to draw a diagram of a scenario that would cause blackholing, but I found one on this website http://network-101.blogspot.co.uk/2011/ ... ntion.html

When the cluster IDs are the same, R2 does not learn the prefixes from R4. Once the cluster IDs are different all prefixes are learned on all routers. Sure, this is a lab, but anytime you don't have a full mesh between both RRs and each client you have the potential to lose routing information when cluster IDs are the same.

I still can't think of a scenario where you would need to use the same cluster ID on the RRs. Can you perhaps provide one?

Can you please point out the part in the RFC that says you must use the same ID on all members of the same cluster?

I was going to draw a diagram of a scenario that would cause blackholing, but I found one on this website http://network-101.blogspot.co.uk/2011/ ... ntion.html

When the cluster IDs are the same, R2 does not learn the prefixes from R4. Once the cluster IDs are different all prefixes are learned on all routers. Sure, this is a lab, but anytime you don't have a full mesh between both RRs and each client you have the potential to lose routing information when cluster IDs are the same.

I still can't think of a scenario where you would need to use the same cluster ID on the RRs. Can you perhaps provide one?

I would be suspicious of anyone posting BGP articles who uses link IP addresses for iBGP session peering, as that is against the very well-known best practice of using loopback IP addresses for iBGP peering. Maybe the author was just being lazy for a quick-and-dirty lab example, but firing off loopback IP addresses in GNS3 is something that only takes mere seconds to do whenever you've been making labs for a while.

On the other hand, I myself have not played around much with RRs and cluster IDs so I'm interested to see what sri2007 has to say on the matter.

Indeed, however I think it's less of a 'how to' and more of an example of how cluster IDs work.

The point being it's not simply a matter of setting the same cluster ID on all route reflectors in the cluster every time you turn on reflection. You need to way up whether it's something you need and not just because someone said that's what you need to do.

The only type of scenario I can think of where you would need to use the same cluster ID is if you had a large network of multiple clusters, and you were changing some attributes as the updates got passed along from cluster to cluster, such as next-hop. You would want to make sure each cluster only received the update once.

This post from PacketPushers has a great section on both ways of configuring this http://packetpushers.net/bgp-rr-design-part-1/

hello!! yesterday was a busy monday...

1. The RFC explicit saids this:
"Usually, a cluster of clients will have a single RR. In that case,
the cluster will be identified by the BGP Identifier of the RR.
However, this represents a single point of failure so to make it
possible to have multiple RRs in the same cluster, all RRs in the
same cluster can be configured with a 4-byte CLUSTER_ID so that an RR
can discard routes from other RRs in the same cluster."

So anyone can understand this as a suggestion, however I got your point when a router has only a single homed (just to explain the topology) to a RR, in this scenario is a really bad idea to configure the same Cluster ID because of the behaviour of BGP when it got the same Cluster-ID in a prefix.

But, this example seems to be a bad practice and for my opinion it doesn't have sense, because, the idea of getting two RR is to increase the uptime of any iBGP solution, so why are you going to configure a Route-Reflect client to only one RR instead of configuring to both of RRs??

I've created several scenarios by deploying two RRs, and lots of routers (since 4 routers to hundreds), so each router can establish an iBGP session with both Route-Reflectors then you can get a HA topology easiliy

But, this example seems to be a bad practice and for my opinion it doesn't have sense, because, the idea of getting two RR is to increase the uptime of any iBGP solution, so why are you going to configure a Route-Reflect client to only one RR instead of configuring to both of RRs??

I think this is the key point about the example. The RRs are supposed to ignore prefixes from each other when clustered, and this is because it is assumed that all RR clients are peering with both RRs. That makes sense to me.

Furthermore, I'm generally dubious about solutions that use "next hop self" because the entire point of iBGP is to leave the next hop untouched so that the client can utilize the IGP (OSPF/EIGRP/IS-IS/etc) for finding the best actual next-hop to reach the advertised gateway for any given prefix. These IGP distances may even factor in to the actual best path selection itself.

1. The RFC explicit saids this:
"Usually, a cluster of clients will have a single RR. In that case,
the cluster will be identified by the BGP Identifier of the RR.
However, this represents a single point of failure so to make it
possible to have multiple RRs in the same cluster, all RRs in the
same cluster can be configured with a 4-byte CLUSTER_ID so that an RR
can discard routes from other RRs in the same cluster."

But the RFC does not say you must use the same cluster ID on all route reflectors in the cluster, and that's my point. The only downside I can see of not using the same cluster ID is that you end up with two copies of each update, which uses a little more memory and processing power. Now if this was an entire global table I might consider the resource requirements to process this, but for ~2000 prefixes I'm not worried.

By using different cluster IDs (or by simply not setting them defaulting to cluster_id = router_id) in a single cluster you still have HA, you still have full routing info and you are protected against multiple (though maybe unlikely) link failures that could blackhole traffic. I'd rather know why I'm turning a particular feature on or off rather than just setting it because someone told me that's what I had to do. I'm just curious like that.

And while we all like to harp on about best practices (I know I do) not every topology is the same perfect design where you can have redundant this and resilient that. Sometimes you have to do the best with what you have, and that's why there are multiple ways of accomplishing the same end goal - flexibility in deployment is key.