Implementing Route reflectors - Questions

nel

Hey,

Considering this is a bgp/SP Q i thought i would ask here

Our network is growing and within the next 12 months theres a good chance the number of bgp speakers in the network is going to double and possibly treble. Currently we use a full mesh between about 6 devices, so to ease administration i was thinking about looking into a project to install a few RR's.

After reading some articles i have a few questions:

1) with the number of devices mentioned, will it be worth it?
2) can RR modify BGP attributes? from my research it doesnt appear so, but would like confirmation as this would affect the location of them.
3) where is the recommend position for a RR?
4) i have seen a few posts recommending a RR follows the "physical topology" but I cant see any explanation Why this is? Could anyone clear this up.
5) when using multiple RR's, how are they viewed by the clients in terms of primary/secondary status? or is it simply a case of them being "equals"? so when a route is received from RR1 first it is placed into the routing table and the route reflected from RR2 is discarded? and vice versa?

Thanks

networker050184

nel wrote: »

1) with the number of devices mentioned, will it be worth it?

I think so. It can drastically cut down overhead and resource utilization. Just make sure reflection is redundant. You don't want one router taking out your BGP network.

nel wrote: »

2) can RR modify BGP attributes? from my research it doesnt appear so, but would like confirmation as this would affect the location of them.

It can, but that's usually not the purpose of them.

nel wrote: »

3) where is the recommend position for a RR?

I had a guy from Cisco saying they shouldn't be in the forwarding path. I've seen them both in and out and never any issues. With your small amount of devices I don't think you really need a couple extra devices for RR only.

nel wrote: »

4) i have seen a few posts recommending a RR follows the "physical topology" but I cant see any explanation Why this is? Could anyone clear this up.

Not sure exactly what you mean here. I have mainly seen them set up in a hierarchical set up. Core reflects down to distribution, distribution down to edge etc. Some people use dedicated devices that all routers peer with for reflection only.

nel wrote: »

5) when using multiple RR's, how are they viewed by the clients in terms of primary/secondary status? or is it simply a case of them being "equals"? so when a route is received from RR1 first it is placed into the routing table and the route reflected from RR2 is discarded? and vice versa?

The RR just reflects the route down. Your basic BGP path selection remains the same.

nel

networker050184 wrote: »

I think so. It can drastically cut down overhead and resource utilization. Just make sure reflection is redundant. You don't want one router taking out your BGP network.




It can, but that's usually not the purpose of them.



I had a guy from Cisco saying they shouldn't be in the forwarding path. I've seen them both in and out and never any issues. With your small amount of devices I don't think you really need a couple extra devices for RR only.



Not sure exactly what you mean here. I have mainly seen them set up in a hierarchical set up. Core reflects down to distribution, distribution down to edge etc. Some people use dedicated devices that all routers peer with for reflection only.



The RR just reflects the route down. Your basic BGP path selection remains the same.

Yeah, i cant see us having dedicated devices for RR only, we are just simply not at that scale. even hierarchical RR is questionable. whats the max number of devices to use before having to migrate to a hierarchical model? if its a small number then i would just implement that initially rather than having to migrate again, even if it is overkill at this moment in time.

Daniel333

nel wrote: »

Hey,

Considering this is a bgp/SP Q i thought i would ask here

Our network is growing and within the next 12 months theres a good chance the number of bgp speakers in the network is going to double and possibly treble. Currently we use a full mesh between about 6 devices, so to ease administration i was thinking about looking into a project to install a few RR's.

After reading some articles i have a few questions:

1) with the number of devices mentioned, will it be worth it?
2) can RR modify BGP attributes? from my research it doesnt appear so, but would like confirmation as this would affect the location of them.
3) where is the recommend position for a RR?
4) i have seen a few posts recommending a RR follows the "physical topology" but I cant see any explanation Why this is? Could anyone clear this up.
5) when using multiple RR's, how are they viewed by the clients in terms of primary/secondary status? or is it simply a case of them being "equals"? so when a route is received from RR1 first it is placed into the routing table and the route reflected from RR2 is discarded? and vice versa?

Thanks

I am not the BGP expert I probably should be. But Ill toss in my $.02 as it's been a few weeks since I was flamed for incompetence.
1) Is it worth it? Unless you think you'll be adding another BGP spearers + sites in the next couple years I would say no. You're talking downtime and possible human error. Given RR need you to configure redudancy you might save 1? 2? Neighbor statements in your config? Seriously not worth the effort unless you foresee some more growth. In which case I would say go for it

2) I think so, you're gonna have to double check me. But a route-map is a route-map no matter what device it's on
3) RR need to be central in your design. Remember you need to set up at least 2 route reflectors for redundancy then cross pair them
4) Link? But they are probably talking about the physical design regarding redudancy
5) Not clear on what you're asking? But they are seen like any other device as far as I know. So it will follow normal BGP path selections before entering the routes into the routing tables afaik.

Given the small amount of routers you have. You might want to fire up GNS3 and test your config. No reason why you can't get 10+ routers flying on a i5 with Ubuntu.

I hope that helps. Let me know if you discover something different and how it works out.

networker050184

Daniel333 wrote: »

I am not the BGP expert I probably should be. But Ill toss in my $.02 as it's been a few weeks since I was flamed for incompetence.
1) Is it worth it? Unless you think you'll be adding another BGP spearers + sites in the next couple years I would say no. You're talking downtime and possible human error. Given RR need you to configure redudancy you might save 1? 2? Neighbor statements in your config? Seriously not worth the effort unless you foresee some more growth. In which case I would say go for it

It would save a lot more than 1 or 2 peers. He has 6 routers now so each has 5 peers. If this doubles as the OP says each router will have 11 peers. What if more come in the future? End up with all these peers and and all this churn in the network anytime anything changes. I'd also say there's a lot more potential for human error configuring 30 BGP peers rather than 18, and that's just initially. You always want to build a scalable network and adding a peer to every router each time one is turned up is not very scalable.

nel

networker050184 wrote: »

It would save a lot more than 1 or 2 peers. He has 6 routers now so each has 5 peers. If this doubles as the OP says each router will have 11 peers. What if more come in the future? End up with all these peers and and all this churn in the network anytime anything changes. I'd also say there's a lot more potential for human error configuring 30 BGP peers rather than 18, and that's just initially. You always want to build a scalable network and adding a peer to every router each time one is turned up is not very scalable.

Yeah, this is the reason why im looking into this now, whilst the network is a small manageable size, rather than it growing by 2-3x's its current size and they thinking, Damn maybe i should implement RR now . seems more logical to do it now than later

vinbuck

#4 - I think what they are getting at here is to try and avoid having a route reflector cross a Route Reflector client to reach another route reflector. Also, it is recommended to fully mesh your RRs. I came across this when I was redesigning our RR setup to include redundancy. Also, if you do choose to deploy them redundantly, don't use the cluster-id command as it can cause partial connectivity in certain situations. Peer groups can also simplify your life if you have a lot of common attributes to use.

Good resources to use when designing BGP RRs

RFC 4456 - BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)
http://www.pacnog.org/pacnog1/day4/b3-6up.pdf

Why not to use cluster-id

BGP route reflectors - CT3

cxzar20

Your RR logical path should always follow its physical path. Having RR clients cross each other or through other non clients can lead to routing loops.