Juniper: BGP Route Reflectors

As with IOS I am presenting the Route Reflector setup between 3 Juniper routers (Olive).

The setup is almost the same, but I am going to cover the configuration in slightly more detail, as familiarity with IOS appears to be more common. This assumes that the Juniper boxes have already been configured with hostnames and root passwords.

Here is the topology I am using:

1. Configure IP addressing (RR as example)

I always configure the loopback address first. Many routing protocols rely on this.

# set interfaces lo0 unit 0 family inet address 1.3.3.7/32

# set interfaces em0 unit 0 family inet address 10.12.0.1/24

# set interfaces em1 unit 0 family inet address 10.13.0.1/24

(Aside: an easy way to pull these commands after they have been configured is

# run show configuration interfaces lo0.0 | display set

)

2. Set up routing autonomous system

In this case we are working with iBGP so all three routers will be within the same AS

# set routing-options autonomous-system 503

3. Configure the BGP group

Groups allow Junos to logically bunch settings together. Much like the peer-group in IOS. I chose the name IBGP to reflect the work we will be doing. I also like to use all-caps when defining names in Junos as it is easier for me to recognize.

# edit protocols bgp group IBGP

(Another bonus with Junos is all variable names are tab completable:

# edit protocols bgp group ?

Possible completions:

Group name

IBGP Group name

Cool huh?)

4. Edit BGP group settings

Here we set the AS of the peers, their IP addresses and other things like policies :)

Note: usually we would peer using loopback addresses for redundancy. In most production designs redundant connections would allow multiple IGP paths to lo0.0. That is not the case in this example.

RR:

[edit protocols bgp group IBGP]

# set peer-as 503

# set type internal

# set neighbor 10.12.0.2

# set neighbor 10.13.0.3

# commit

R2:

[edit protocols bgp group IBGP]

# set peer-as 503

# set type internal

# set neighbor 10.12.0.1

# commit

R3:

[edit protocols bgp group IBGP]

# set peer-as 503

# set type internal

# set neighbor 10.13.0.1

# commit

5. Stand by and allow BGP to come up (30s or so). Verify:

# run show bgp summary

Groups: 1 Peers: 2 Down peers: 0

Table Tot Paths Act Paths Suppressed History Damp State Pending

inet.0 0 0 0 0 0 0

Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...

10.12.0.2 503 3 3 0 2 0 0/0/0/0 0/0/0/0

10.13.0.3 503 3 2 0 2 0 0/0/0/0 0/0/0/0

See if you can notice something odd with this output

5. Check routing table on the RR:

# run show route protocol bgp

inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)

No routes?

The default behavior of Junos is to accept all NLRIs advertised from peers, but not to advertise any prefixes unless they are specified in an export policy.

6. Define an export policy to send all connected routes:

Policies can be very complex, so I am going to create a very simple one named IBGP:

# edit policy-options policy-statement IBGP

[edit policy-options policy-statement IBGP]

# set policy-options policy-statement IBGP from protocol direct

# set policy-options policy-statement IBGP then accept

This takes all prefixes that are directly connected and places them in the BGP Adjacency-RIB-out for advertisement.

7. Apply the policy to the BGP group

# top edit protocols bgp group IBGP

[edit protocols bgp group IBGP]

# set protocols bgp group IBGP export IBGP

# top commit

8. Verify that prefixes are being seen by the routers

# run show bgp summary

Groups: 1 Peers: 2 Down peers: 0

Table Tot Paths Act Paths Suppressed History Damp State Pending

inet.0 4 2 0 0 0 0

Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...

10.12.0.2 503 22 22 0 2 8:23 1/2/2/0 0/0/0/0

10.13.0.3 503 22 21 0 2 8:23 1/2/2/0 0/0/0/0

And check the routing table on the RR:

# run show route protocol bgp

inet.0: 7 destinations, 9 routes (7 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

2.3.3.7/32 *[BGP/170] 00:05:04, localpref 100

AS path: I

> to 10.13.0.3 via em1.0

3.3.3.7/32 *[BGP/170] 00:05:04, localpref 100

AS path: I

> to 10.12.0.2 via em0.0

10.12.0.0/24 [BGP/170] 00:05:04, localpref 100

AS path: I

> to 10.12.0.2 via em0.0

10.13.0.0/24 [BGP/170] 00:05:04, localpref 100

AS path: I

> to 10.13.0.3 via em1.0

Looks good....right?

Remember that pesky split horizon rule of iBGP? Let's check the routing table on one of the spoke routers for the loopback address of the other spoke (3.3.3.7/32):

# run show route 2.3.3.7

[edit]

Apparently reflection is not running. This can also be seen from the full BGP neighbor output:

# run show bgp neighbor | match cluster

[edit]

Nothing. All we have to do to fix this is turn on router-reflection on the hub router. In IOS we would define each peer or peer-group as being a route-reflector-client. In juniper the idea is similar, but we set a cluster ID on the desires route reflector(s):

# edit protocols bgp group IBGP

[edit protocols bgp group IBGP]

# set cluster 7.3.3.1

[edit protocols bgp group IBGP]

# commit

commit complete

And let's check the full BGP neighbor output:

# run show bgp neighbor | match cluster

Options:

Options:

This should allow the spokes to see each other's loopback prefix:

# run show route 2.3.3.7

inet.0: 6 destinations, 7 routes (6 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

2.3.3.7/32 *[BGP/170] 00:01:04, localpref 100

AS path: I

> to 10.12.0.1 via em0.0

And the other spoke:

# run show route 3.3.3.7

inet.0: 6 destinations, 7 routes (6 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

3.3.3.7/32 *[BGP/170] 00:01:38, localpref 100

AS path: I

> to 10.13.0.1 via em0.0

To recap, here are the configs:

RR# show | display set | except "version|system"

set interfaces em0 unit 0 family inet address 10.12.0.1/24

set interfaces em1 unit 0 family inet address 10.13.0.1/24

set interfaces lo0 unit 0 family inet address 1.3.3.7/32

set protocols bgp group IBGP type internal

set protocols bgp group IBGP export IBGP

set protocols bgp group IBGP cluster 7.3.3.1

set protocols bgp group IBGP peer-as 503

set protocols bgp group IBGP neighbor 10.12.0.2

set protocols bgp group IBGP neighbor 10.13.0.3

set policy-options policy-statement IBGP from protocol direct

set policy-options policy-statement IBGP then accept

R3# show | display set | except "version|system"

set interfaces em0 unit 0 family inet address 10.12.0.2/24

set interfaces lo0 unit 0 family inet address 3.3.3.7/32

set protocols bgp group IBGP type internal

set protocols bgp group IBGP export IBGP

set protocols bgp group IBGP peer-as 503

set protocols bgp group IBGP neighbor 10.12.0.1

set policy-options policy-statement IBGP from protocol direct

set policy-options policy-statement IBGP then accept

R3# show | display set | except "version|system"

set interfaces em0 unit 0 family inet address 10.13.0.3/24

set interfaces lo0 unit 0 family inet address 2.3.3.7/32

set protocols bgp group IBGP type internal

set protocols bgp group IBGP export IBGP

set protocols bgp group IBGP peer-as 503

set protocols bgp group IBGP neighbor 10.13.0.1

set policy-options policy-statement IBGP from protocol direct

set policy-options policy-statement IBGP then accept

That's all for now. Please ask any questions you may have.

/m

BGP Route Reflectors, or “Disabling BGP split horizon”

Aside: In keeping with the goals of 3Facets, I am starting off with an article on BGP Route Reflection (professional). This may show up elsewhere on the internet however I am the original author.

One of the most dreaded stipulations of the Border Gateway Patrol, as taken directly from RFC4271:

“When a BGP speaker receives an UPDATE message from an internal peer,

the receiving BGP speaker SHALL NOT re-distribute the routing

information contained in that UPDATE message to other internal peers”

This presents quite a problem in organizations where the iBGP speakers are not all fully meshed, as seen below:

Imagine if this organization had 30 routers, or 230 routers--this would be impossible to setup and maintain.

There are two possible remedies. One is BGP confederations, the other is Route Reflectors (Henceforth referred to as RRs). A RR effectively disables the split-horizon mechanisms of BGP by allowing an iBGP speaker to advertise iBGP learner routes to other internal speakers. Documented in RFC2796, Route Reflectors are formally defined as “[a method of] alleviate the the need for "full mesh" IBGP” through “a BGP speaker advertising an IBGP learned route to another IBGP peer”

The effective use of RRs reduce the topology above to this:

This is an effective reduction in connections from (n2 - n) / 2 to n - 1, where n equals the number of iBGP speakers. For example, in the networks mentioned above with 30 and 230 speakers, they would be reduced from 435 to 29 connection and from 26335 to 229. The comparative graph of meshed connections to RRs is:

Now that the need for RRs is understood, the theory is quite simple:

1. A RR is peered with other iBGP speakers normally

2. The RR has a configuration option set to designate the downstream iBGP peers as RR clients

3. Non-client iBGP speakers peering with an RR is still subject to the non-transitive nature of iBGP to iBGP route advertisements

The term is self explanatory--The RR bounces routes down to the client speakers. The format of the advertisement is very similar to a standard BGP update:

As seen above the standard BGP update (with default attribute settings) contains the three well known mandatory attributes and two optionals: LOCAL_PREF and MED.

With the RR update, the inclusion of CLUSTER_LIST and ORIGINATOR. Not only do these signal the downstream router to add the route to its table, ignoring the iBGP rules. These attributes provide RR clusters with loop prevention.

Loop prevention in an RR topology is provided via:

1. The CLUSTER_ID BGP attribute. Each RR adds its cluster ID, which is by default the router ID (RID) of the RR, to route updates that are reflected to its downstream peers. This way routes do no become re-reflected into the cluster by way of redundant connections or multiple cluster RRs

2. ORIGINATOR_ID is labeled as the first iBGP speaker to advertise a prefix in a given AS. I a BGP speaker receives an advertisement with its own RID in said field, it discards the prefix.

3. Just as through normal operation of BGP, only the best routes are advertised to neighbors.

Configuration:

Easy as pie! All that needs to change is the addition of one statement per downstream peer in relation to the RR ‘server’. Here is the topology:

One of the spoke routers is advertising the network 33.3.3.3/29 into AS 503 via iBGP. Here is the BGP table on the RR server:

LolaBoat#sh ip bgp

BGP table version is 7, local router ID is 1.3.3.7

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

*> 1.3.3.7/32 0.0.0.0 0 32768 i

*> 10.1.12.0/24 0.0.0.0 0 32768 i

*> 10.1.13.0/24 0.0.0.0 0 32768 i

*>i33.3.3.0/29 10.1.13.3 0 100 0 i

And the BGP table on the far spoke:

R2#sh ip bgp

BGP table version is 18, local router ID is 10.1.12.2

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

*>i1.3.3.7/32 10.1.12.1 0 100 0 i

r>i10.1.12.0/24 10.1.12.1 0 100 0 i

*>i10.1.13.0/24 10.1.12.1 0 100 0 i

Note that the 33.3.3.0/29 prefix is missing. This is due to the hub router not advertising an iBGP learned route to another iBGP peer. We can see the hub is not advertising this route

LolaBoat#show ip bgp neighbors 10.1.12.2 advertised-routes

BGP table version is 9, local router ID is 1.3.3.7

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

*> 1.3.3.7/32 0.0.0.0 0 32768 i

*> 10.1.12.0/24 0.0.0.0 0 32768 i

*> 10.1.13.0/24 0.0.0.0 0 32768 i

To fix this, the hub router is made into an RR. Please note this will drop any active BGP sessions:

LolaBoat(config)#router bgp 503

LolaBoat(config-router)#neighbor 10.1.12.2 route-reflector-client

*Mar 1 00:07:01.295: %BGP-5-ADJCHANGE: neighbor 10.1.12.2 Down RR client config change

*Mar 1 00:07:03.327: %BGP-5-ADJCHANGE: neighbor 10.1.12.2 Up

LolaBoat(config-router)#neighbor 10.1.13.3 route-reflector-client

LolaBoat(config-router)#

*Mar 1 00:07:16.467: %BGP-5-ADJCHANGE: neighbor 10.1.13.3 Down RR client config change

LolaBoat(config-router)#

*Mar 1 00:07:18.611: %BGP-5-ADJCHANGE: neighbor 10.1.13.3 Up

Now the RR (formerly referred to as the hub) will advertise the 33.3.3.0/29 prefix to the far spoke router:

LolaBoat#show ip bgp neighbors 10.1.12.2 advertised-routes

BGP table version is 11, local router ID is 1.3.3.7

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

*> 1.3.3.7/32 0.0.0.0 0 32768 i

*> 10.1.12.0/24 0.0.0.0 0 32768 i

*> 10.1.13.0/24 0.0.0.0 0 32768 i

*>i33.3.3.0/29 10.1.13.3 0 100 0 i

And on the far spoke, success!

R2#sh ip bgp

BGP table version is 26, local router ID is 10.1.12.2

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

*>i1.3.3.7/32 10.1.12.1 0 100 0 i

r>i10.1.12.0/24 10.1.12.1 0 100 0 i

*>i10.1.13.0/24 10.1.12.1 0 100 0 i

*>i33.3.3.0/29 10.1.13.3 0 100 0 i

You can see that the 33.3.3.0/29 prefix was reflected by closer inspection. The cluster list is present and is equal to the Loopback0 of the RR:

R2#sh ip bgp 33.3.3.0

BGP routing table entry for 33.3.3.0/29, version 26

Paths: (1 available, best #1, table Default-IP-Routing-Table)

Flag: 0x820

Not advertised to any peer

Local

10.1.13.3 from 10.1.12.1 (1.3.3.7)

Origin IGP, metric 0, localpref 100, valid, internal, best

Originator: 10.1.13.3, Cluster list: 1.3.3.7

This can be changed on the RR simply (remember the decimal value will be converted to binary):

LolaBoat(config)#router bgp 503

LolaBoat(config-router)#bgp cluster-id 8675309

R2#sh ip bgp 33.3.3.0 | i Cluster

Originator: 10.1.13.3, Cluster list: 0.132.95.237

That is all for now. Stay tuned for a post detailing this in Junos as opposed to Cisco IOS :)

/m