Junos OS

Hi all,

Quick question that will be easy to answer I am sure...

Just configuring an RR Cluster with IGP of OSPF, it is very basic just now before I start making the configuration a lot more complicated.

So, here is the config of the first client and the RR:

Client 1:

set interfaces ge-0/0/0 unit 0 description to-route-reflector-ge-0/0/0.0
set interfaces ge-0/0/0 unit 0 family inet address 192.168.1.1/30
set interfaces lo0 unit 0 family inet address 192.168.1.254/32
set routing-options static route 192.168.1.250/32 next-hop 192.168.1.2
set routing-options router-id 192.168.1.254
set routing-options autonomous-system 44009
set protocols bgp group internal-peers type internal
set protocols bgp group internal-peers local-address 192.168.1.254
set protocols bgp group internal-peers log-updown
set protocols bgp group internal-peers export send-ospf
set protocols bgp group internal-peers neighbor 192.168.1.250
set protocols ospf area 0.0.0.0 interface lo0.0 passive
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0
set policy-options policy-statement send-ospf term 1 from protocol ospf
set policy-options policy-statement send-ospf term 1 then accept

RR:

set system host-name Route-Reflector
set interfaces ge-0/0/0 unit 0 description to-london-prouter-1-ge-0/0/0.0
set interfaces ge-0/0/0 unit 0 family inet address 192.168.1.2/30
set interfaces ge-0/0/1 unit 0 description to-swindon-prouter-1-ge-0/0/1.0
set interfaces ge-0/0/1 unit 0 family inet address 192.168.1.6/30
set interfaces ge-0/0/2 unit 0 description to-london-prouter-2-ge-0/0/2.0
set interfaces ge-0/0/2 unit 0 family inet address 192.168.1.10/30
set interfaces ge-0/0/3 unit 0 description to-swindon-prouter-2-ge-0/0/3.0
set interfaces ge-0/0/3 unit 0 family inet address 192.168.1.14/30
set interfaces lo0 unit 0 family inet address 192.168.1.250/32
set routing-options router-id 192.168.1.250
set routing-options autonomous-system 44009
set protocols bgp group internal-peers type internal
set protocols bgp group internal-peers local-address 192.168.1.250
set protocols bgp group internal-peers log-updown
set protocols bgp group internal-peers export send-ospf
set protocols bgp group internal-peers cluster 192.168.1.250
set protocols bgp group internal-peers neighbor 192.168.1.1
set protocols bgp group internal-peers neighbor 192.168.1.5
set protocols bgp group internal-peers neighbor 192.168.1.9
set protocols bgp group internal-peers neighbor 192.168.1.13
set protocols ospf area 0.0.0.0 interface lo0.0 passive
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0
set policy-options policy-statement send-ospf term 1 from protocol ospf
set policy-options policy-statement send-ospf term 1 then accept

Here are the results from the RR for the route to client 1 loopback:

root@Route-Reflector# run show route 192.168.1.254

inet.0: 14 destinations, 14 routes (14 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

192.168.1.254/32 *[OSPF/10] 00:40:11, metric 1
> to 192.168.1.1 via ge-0/0/0.0

No route in the BGP routing-table under "show route protocol bgp".

This configuration is taken from:

https://www.juniper.net/documentation/en_US/junos/topics/topic-map/bgp-route-reflectors.html

Now, I can show perfectly well the route-reflection working with no IGP in place, but that defeats the purpose. For example, I configure the RR without the cluster command and, quite rightly, cannot see other clients routes. When I turn on the cluster I see the routes on the other clients, but obviously not pingable.

Now, if I then configure as per the Juniper docs I only get a route showing in the OSPF routing table yet the docs quite clearly show there should be a BGP route there too.

Any ideas please?

Just wanted to clear this up before I start configuring the other clients.

I also realise what the "Passive" statement does.

Hello,

First things first - I strongly recommend to read this book https://www.amazon.com/Juniper-Cisco-Routing-Protocols-Multivendor/dp/0471215929 , it has all the answers to the questions You asked and many more.

Next:

---

@adgwytc wrote:

 

 

Now, if I then configure as per the Juniper docs I only get a route showing in the OSPF routing table yet the docs quite clearly show there should be a BGP route there too.

I already mentioned to You in the other thread that JUNOS exports only ACTIVE route, be it into OSPF, into BGP, etc.

So, with Your config, You are exporting only active OSPF routes into iBGP and You are expecting 192.168.1.254/32 route to appear in the  RR' inet.0 as BGP route.

There are 2 problems with this expectation:

1/  192.168.1.254/32 is NOT an active OSPF route on "Client 1", it is an active Direct route

2/ You haven't included "from protocol direct" match into Your "send-ospf" policy.

Moreover, even if You do include "from protocol direct" into "send-ospf" policy on Client 1, then You'd get the 192.168.1.254/32 route exported into iBGP then the RR would receive it

BUT

the RR won't see it as active route because RR already has 192.168.1.254/32 OSPF/10 route and 192.168.1.254/32 BGP/170 route would lose the Protocol Preference contest. Hence, RR won't reannounce this route to the other clients (if You have any other clients of course)

Hope this makes sense.

If not I strongly urge You to read the book I cited above before You attempt to do anything else with Your BGP RR config.

HTH

Thx

Alex

Hi Alex,

Yep, apologies. Brain freeze moment. Of course the route has to be active. All good. I'll do a quick re-config with another router and post here as an example for others.

Thanks

Hi Alex,

The issue was easier to resolve than adding another system.

Looking at the config again on client-1 I added the following line:

set protocols bgp group internal-peers local-address 192.168.1.254

As I wanted to change it to the loopback from the physical. And on the route reflector it still stated the following:

set protocols bgp group internal-peers neighbor 192.168.1.1

So, I had made the change on the client but for not seeing the wood for the trees, forgot to make the same change on the RR.

All routes now appear in the BGP routing table as expected.

Result with the "cluster" command OFF:

root@London-prouter-1# run show route 192.168.10.252

inet.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

192.168.10.252/32 *[OSPF/10] 00:07:01, metric 2
> to 192.168.1.2 via ge-0/0/0.0

Result with the "Cluster" command ON:

root@London-prouter-1# run show route 192.168.10.252

inet.0: 13 destinations, 16 routes (13 active, 0 holddown, 2 hidden)
+ = Active Route, - = Last Active, * = Both

192.168.10.252/32 *[OSPF/10] 00:05:45, metric 2
> to 192.168.1.2 via ge-0/0/0.0
[BGP/170] 00:05:44, MED 1, localpref 100, from 192.168.1.250
AS path: I, validation-state: unverified
> to 192.168.1.2 via ge-0/0/0.0

Perfect. Route Reflector working as expected.

Cheers

Hi Alex,

I do have a good understanding of BGP and its operation and maybe this is some other issue. To simplify matters I have made a very, very basic configuration (it did seem to work above - but now I am seeing something weird:

Firstly, the main reason for a route-reflector is to get around the need for a full mesh and it is obviously more scaleable. This is in place to stop loops forming and basically means that an iBGP router that receives a route from a neighbor is not allowed to pass that route on (hence the requirement of a full mesh). So, here is my very basic topology (again, using the Juniper recommendations to test why this is happening):

lon-prouter (192.168.1.254 lo0) <--> RR (192.168.50.250 lo0) <--> Swin-prouter (192.168.10.252)

So, I have only, as an initial test, configured the lon-prouter as a bgp neighbor to the RR. The RR does not yet have a cluster command and so therefore is acting as a normal iBGP router. I have OSPF configured to include the loopback addresses and the lo interface is also the RID for the three systems. Here are the very basic configs:

lon-prouter:

set interfaces ge-0/0/0 unit 0 description to-rr
set interfaces ge-0/0/0 unit 0 family inet address 192.168.1.1/30
set interfaces ge-0/0/1 unit 0 description to-dummy
set interfaces ge-0/0/1 unit 0 family inet address 172.16.10.2/24
set interfaces lo0 unit 0 family inet address 192.168.1.254/32
set routing-options router-id 192.168.1.254
set routing-options autonomous-system 44009
set protocols bgp group internal-peers type internal
set protocols bgp group internal-peers local-address 192.168.1.254
set protocols bgp group internal-peers log-updown
set protocols bgp group internal-peers export export-route
set protocols bgp group internal-peers peer-as 44009
set protocols bgp group internal-peers neighbor 192.168.50.250
set protocols ospf area 0.0.0.0 interface lo0.0 passive
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0
set policy-options policy-statement export-route term 1 from protocol ospf
set policy-options policy-statement export-route term 1 then accept

Route-Reflector:

set interfaces ge-0/0/0 unit 0 description to-london-pr1
set interfaces ge-0/0/0 unit 0 family inet address 192.168.1.2/30
set interfaces ge-0/0/1 unit 0 description to-swindon-pr1
set interfaces ge-0/0/1 unit 0 family inet address 192.168.1.6/30
set interfaces ge-0/0/2 unit 0 description to-london-pr2
set interfaces ge-0/0/2 unit 0 family inet address 192.168.1.10/30
set interfaces ge-0/0/3 unit 0 description to-swindon-pr2
set interfaces ge-0/0/3 unit 0 family inet address 192.168.1.14/30
set interfaces lo0 unit 0 family inet address 192.168.50.250/32
set routing-options router-id 192.168.50.250
set routing-options autonomous-system 44009
set protocols bgp group internal-peers type internal
set protocols bgp group internal-peers local-address 192.168.50.250
set protocols bgp group internal-peers log-updown
set protocols bgp group internal-peers export export-route
set protocols bgp group internal-peers peer-as 44009
set protocols bgp group internal-peers neighbor 192.168.1.254
set protocols ospf area 0.0.0.0 interface lo0.0 passive
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0
set policy-options policy-statement export-route term 1 from protocol ospf
set policy-options policy-statement export-route term 1 then accept

Swin-prouter:

set interfaces ge-0/0/1 unit 0 description to-rr
set interfaces ge-0/0/1 unit 0 family inet address 192.168.1.5/30
set interfaces lo0 unit 0 family inet address 192.168.10.252/32
set routing-options router-id 192.168.10.252
set routing-options autonomous-system 44009
set protocols bgp group internal-peers type internal
set protocols bgp group internal-peers local-address 192.168.10.252
set protocols bgp group internal-peers log-updown
set protocols bgp group internal-peers export export-route
set protocols bgp group internal-peers peer-as 44009
set protocols bgp group internal-peers neighbor 192.168.50.250
set protocols ospf area 0.0.0.0 interface lo0.0 passive
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0
set policy-options policy-statement export-route term 1 from protocol ospf
set policy-options policy-statement export-route term 1 then accept

Why am I seeing the loopback address for the swi-prouter in the bgp forwarding table on lon-prouter when:

1: swi-prouter is not even peer'd with the RR?

2: The RR is not yet even configured as an RR?

So the RR (normal router currently) is forwarding the loopback address anyway, thus ignoring all the BGP full mesh rules, as shown below (with the above config):

root@london-prouter-1# run show route 192.168.10.252

inet.0: 9 destinations, 12 routes (9 active, 0 holddown, 2 hidden)
+ = Active Route, - = Last Active, * = Both

192.168.10.252/32 *[OSPF/10] 00:02:57, metric 2
> to 192.168.1.2 via ge-0/0/0.0
[BGP/170] 00:02:14, MED 1, localpref 100, from 192.168.50.250
AS path: I, validation-state: unverified
> to 192.168.1.2 via ge-0/0/0.0

This seems strange. It is as though the RR is getting the route from OSPF, which is being injected into BGP but even though the reflector rule states:

A prefix advertised by a client is advertised to all peers - but, in this case the RR is not even configured yet as an RR but as an iBGP router with 2 peers.

Maybe I am missing something silly, but this seems to be going against the rules unless OSPF is causing some fundamental issue.

As an add on, I have also tested by adding "swin-prouter" to the neighbor list on the RR so there is a peering there just in case the RR was seeing the route from swi-prouter via OSPF and injecting it into BGP and therefore seeing lon-prouter as its neighbor. So now it should 100% not be passing it on as it is NOT an RR yet.

Hello,

---

@adgwytc wrote:

it should 100% not be passing it on as it is NOT an RR yet.

---

It is not "passing" , You are redistrubuting OSPF into BGP on RR itself.

Please double-check Your RR config and remove "export-route" OSPF->BGP export policy there.

Oh, and actually reading the book I recommended would be beneficial, trust me 

HTH

Thx

Alex

Hi Alex,

Thanks for the reply. Yes, that's what I meant, "Advertising". However, the thought process regarding the rules, I would still have thought that as it is not yet configured as an RR it would not re-advertise the route, but I guess the RR sees each peer as a separate identity and simply advertises all OSPF routes it sees into BGP and therefore both peers (but that seems to negate the need for an actual RR then).

I did actually test with no policy on the RR.

So, I tested the following:

1: Removing the "export export-route" command from the bgp group on the RR - result. Only see OSPF routes and no BGP routes.

2: Removed the policies from the p-routers to see what would happen and "no change".

3: Set up a dummy system attached to lon-prouter with a 172.16.10.0/24 network and added to OSPF and advertised via the policy into BGP on the lon-prouter but on the swi-prouter I only see that network via OSPF.

Just seems a very weird scenario. Does not seem to matter what I do I either get nothing or everything everywhere even when not an RR.

I'll try some other tests and get back with the results.

Thanks again Alex. Very much appreciated.

Hi Alex,

Nope, no luck. I have tried so many different ways of achieving this and the result is the same. I either get everything (as mentioned before, thus negating the need for a route-reflector) or I get nothing. For example the following:

dummy --> Router A --> RR --> Router B

Link between Dummy and Router A is a completely differnt network range and is advertised into BGP as an Aggregate (with a contributing prefix). The RR sees this and should pass to Router B but Router B does not see the route.

Weird. It should work.

I'll give it another go later but if not working I'll just close this with no resolution.

Thanks

Hello,

---

@adgwytc wrote:

 

 

dummy --> Router A --> RR --> Router B

 

Link between Dummy and Router A is a completely differnt network range and is advertised into BGP as an Aggregate (with a contributing prefix). The RR sees this and should pass to Router B but Router B does not see the route.

 

---

Is this link/aggrregate also in IGP? Have You added "cluster" statement on the node whose hostname is "RR"? 

If yes+yes then let me repeat once again for You:

JUNOS BGP advertises only ACTIVE route, be it via redistribution/export, or during route reflection process.

So, the explanation is simple - once RR sees this link subnet via both IGP and BGP, then IGP wins because of smaller Protocol Pref and RR does not reflect the inactive BGP route for this link subnet.

If this link/aggregate is NOT in IGP, then there is a potential problem with nexthop resolution on RR. "next-hop self" on Router A should help.

HTH

Thx

Alex

P.S. I get it that You haven't yet read the book I recommended? So sad 

Hi Alex,

That's why I wrote "Contributing route"... or active.... Otherwise it would not work at all....  🙂 I would not have asked otherwise.

I'll try the next-hop self. The only one I have not tried yet is with no IGP at all anywhere, and static routes only.

Cheers

Hello,

---

@adgwytc wrote:

 

I'll try the next-hop self.

 

Oki doki.

And please post the following printouts to turn assumptions into facts:

## From Router A:
show route advertising-protocol bgp <RR peering IP address> detail
## From RR:
show route advertising-protocol bgp <Router B peering IP address> detail

Finally, here is the example minimal configuration for Your Router A to redistribute aggregate into BGP that always works for me:

set interfaces lo0.0 family inet address 203.0.113.1/32
set interfaces ge-1/1/1.0 family inet address 198.51.100.1/25
set interfaces ge-1/1/1 description "link to Dummy"
set routing-options autonomous-system 65000
set routing-options aggregate route 198.51.100.0/24 discard
set policy-options policy-statement AGG-2-BGP term 1 from protocol aggregate
set policy-options policy-statement AGG-2-BGP term 1 from route-filter 198.51.100.0/24 exact
set policy-options policy-statement AGG-2-BGP term 1 then next-hop self
set policy-options policy-statement AGG-2-BGP term 1 then accept
set policy-options policy-statement AGG-2-BGP term 2 then reject
set protocols bgp group iBGP type internal
set protocols bgp group iBGP local-address 203.0.113.1
set protocols bgp group iBGP neighbor 203.0.113.3 description RR
set protocols bgp group iBGP export AGG-2-BGP

And that's it.

No need to redistribute aggregate or ge-1/1/1.0 link subnet into IGP, as this is going to break the reflection on RR.

HTH

Thx

Alex

Hi Alex,

So, I removed all OSPF configurations from the 3 systems and have now added a loopback interface to the dummy system (10.10.10.1).

To bring up the BGP peering I have added static routes for now to test (the only thing I had not completed). Here are the results with RR turned ON:

Router-A:
set routing-options aggregate route 10.10.10.0/24
set policy-options policy-statement export-route term 1 from protocol aggregate
set policy-options policy-statement export-route term 1 then accept
set protocols bgp group internal-peers export export-route

show route advertising-protocol bgp 192.168.50.250
inet.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)
Prefix                                 Nexthop                      MED                 Lclpref                   AS path
* 10.10.10.0/24                  Self                                                        100                          I

Route-Reflector:
set protocols bgp group internal-peers cluster 192.168.50.250

show route advertising-protocol bgp 192.168.10.252 (Router-B)

inet.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden)
Prefix                         Nexthop                         MED               Lclpref            AS path
* 10.10.10.0/24   192.168.1.254                                             100                   I

Router-B:

show route 10.10.10.1

I do not see anything in the routing table regarding this address, however, in the following output:

show bgp neighbor

RIB State: BGP restart is complete
Send state: in sync
Active prefixes:                 0
Received prefixes:             1
Accepted prefixes:            1
Suppressed due to damping: 0
Advertised prefixes:          0

The lack of showing a route could be down to it not being active. Actually, I am surprised. I thought the "show route 10.10.10.1" would show the route as BGP?

Now let's see the results without it being an RR (I will remove the Cluster command):

Route-Reflector:

show route advertising-protocol bgp 192.168.10.252

Nothing.

Router-B:

show bgp neighbor
RIB State: BGP restart is complete
Send state: in sync
Active prefixes: 0
Received prefixes: 0
Accepted prefixes: 0
Suppressed due to damping: 0
Advertised prefixes: 0

So, nothing received.

Now we are getting somewhere. I will now start adding the IGP back in and see what the results are.

So, removing all IGP statements and using static routes has worked. It's a starting point.

Cheers Alex,

Hello,

---

@adgwytc wrote:

 

 

Router-B:

 

show route 10.10.10.1

 

I do not see anything in the routing table regarding this address, however, in the following output:

show bgp neighbor

RIB State: BGP restart is complete
Send state: in sync
Active prefixes:                 0
Received prefixes:             1
Accepted prefixes:            1
Suppressed due to damping: 0
Advertised prefixes:          0

 

The lack of showing a route could be down to it not being active. Actually, I am surprised. I thought the "show route 10.10.10.1" would show the route as BGP?

This is expected if Router B has no route towards 192.168.1.254 and no 0/0 route and therefore cannot resolve BGP nexthop 192.168.1.254 for 10.10.10.1/32 to an outgoing interface. Therefore this route is hidden on Router B.

---

@adgwytc wrote:

 

Now we are getting somewhere. I will now start adding the IGP back in and see what the results are.

 

---

Please do NOT redistribute anything into Your IGP. Only enable IGP on links and loopbacks.

HTH

Thx

Alex

Hi Alex,

Yes, I should have noted a route back requirement.

All is now working as should:

Router-B:

set routing-options static route 0.0.0.0/0 next-hop 192.168.1.6

show bgp neighbor

RIB State: BGP restart is complete
Send state: in sync
Active prefixes: 1
Received prefixes: 1
Accepted prefixes: 1
Suppressed due to damping: 0
Advertised prefixes: 0

show route 10.10.10.1

10.10.10.0/24 *[BGP/170] 00:00:09, localpref 100, from 192.168.50.250
AS path: I, validation-state: unverified
> to 192.168.1.6 via ge-0/0/1.0

All is good.

I will get the IGP up and running. And, as you said, without really knowing what is happening you should NEVER redistribute BGP into an IGP  🙂

Thank you.