BGP Route reflector rule

[alex_ciobanu]

Hello,

Could anyone please explain me this route reflector rule, that states: a route received from a non-client router is not forwarded a client router.

What could be its purpose ? Loop prevention is managed by different attibutes so... I cannot think of another

Thanks !

[Peter Paluch]

Hello Alexandru,

What could be its purpose ?

To me, this rule is simply and purely about upholding the basic iBGP rule. If a route is received from an iBGP peer that is a non-client then that peer assumes that we do not propagate this iBGP-learned route to any other iBGP neighbor. In other words, for a non-client, we are just another iBGP peer and so the usual iBGP rules should apply.

Also note that a non-client must have its own means of advertising routes to all other iBGP speakers in an AS. If a router reflector reflected routes from a non-client to other iBGP speakers, it would be a duplication of effort - so there's no point in doing that.

Please feel welcome to ask further!

Best regards,

Peter

[alex_ciobanu]

Ok, but here its where im getting stucked. For another non-client, we are just another iBGP peer and the usual iBGP rules should apply. These rules are applied to prevent routing loops.

But in order to prevent routing loops, route reflector is using different attributes, no ?

[smehrnia]

Hi Alex,

from your original question I think you might have gotten something slightly wrong, for a 'BGP Route Reflector' the following rule applies:

* Routes learned from non-client peers can be sent to eBGP peers, client peers, but NOT to other non-clients.

* Routes learned from client peers, can be sent to eBGP, client and non-client peers. same goes for R learned via eBGP.

But in order to prevent routing loops, route reflector is using different attributes, no ?

Yes, two new attributes are added onto the reflected prefixes: Originator ID and Cluster List.

Originator ID = router-id of the neighbor it learned the prefix from.

Cluster List = cluster-ID of the route reflectors that the route was transited through. Unless the BGP cluster-id command is manually configured, the value defaults to the router-id of the RR (Route Reflector).

plz Rate if it helped! 
Soroush,

[alex_ciobanu]

Hello,

Yes sorry, my mistake.

I was refering to the rules "prefixes learned from non-clients are not sent to other non-clients".

I know the originator ID and the Cluster List attributes, what it wasn't so clear is why  this rule exists, and what could be the problem without it.

[PolymorphismIce]

Hi, Alex:

    The default loop prevention mechanism in the AS is not pass the route learned from a iBGP peer to another iBGP peer, but you can use route reflector to break the rule only, the route reflector client configuration is to tell the route reflector which iBGP peer should the route be passed to.

      Thks, Best Regards.

GGM

[alex_ciobanu]

Hello Guao meng, thank you for the help, but I know the definition of route reflectors. If you will go more in depth for the explanation of the route reflector, you will get to a rule regarding route reflectors. My post is regarding a question based on that rule.

[smehrnia]

Alex,

remember about the old time split horizon rule? "not to advertise a route from the same interface that you received it from" well, it was for IGP protocols.

Remember, BGP is rather a TCP Application to propagate prefixes over large scale networks, not an actual routing protocol. considering that iBGP peers could be physically one hop away, or many hops away, as long as there is reachablity between them, to implement the same concept as spilt horizon to prevent loops in BGP, its became a rule not to re-advertise a route learned from a peer within an Autonomous System (iBGP peers) to other peers.

Because from an Administrative point of view, it is assumed that all the iBGP peers are aware of eachother and have full connectivity, unless they are set to be RR clients.

When there are Route Reflectors implemented in the network, are route learned from a client is advertised to clients but with the Originator ID attrib set. this way the originally advertising router, ignores its own route!

have you ever heard BGP is a tricky protocol and misconfig could lead to routing blackholes? well, thats right

plz Rate if it helped,

Soroush.

[alex_ciobanu]

Yes, we all know how iBGP peers work, what will happen if we implement route reflectors, how the split horizon works in BGP, what do the ORIGINATOR_ID and CLUSTER_LIST attribute stands for, but my question was "WHY" there is need for that rule regarding the advertisment between non-clients . . . 

[smehrnia]

lets clarify it once n for all lol

As you said, you know all these stuff, I guess the only confusion for u is this:

a non-client is simply another iBGP peer for Route Reflector.

in an RR environment, only the RR itself knows who is its client n who is not, with a simple route-reflector-client keyword at the end of the neighbor statement. even the client itself doesnt know abt it.

so, in one phrase: The general rule of not advertising back between iBGP peers are enforcing here. we just changed the term of those machines to non-clients instead of iBGP peers!

plz Rate if it helped,

Soroush.

[MCYagli89]

Understanding the Problem is 90% of the Solution

---

When we configure ibgp Route Reflectors

Our RR creates Two Internal Groups  ( show ip bgp update-group )

Client Peers

Non-Client Peers

Client Peers need NOT be fully Meshed.

But Non-Client Peers MUST Be Fully Meshed !!!

This is a rule.

Thats why RR does not send a route it receives from one NC to another NC.

The reason is simple

As Soroush Said

"The general rule of not advertiseing back between ibgp peers are enforcing here. We just changed the term of those machiens to non

clients instead of ibgp peers!"

Mehmet Ceyhan YAĞLI

Cisco Instructor