Routing
Highlighted
Routing

Route Reflector Design concerns

[ Edited ]
‎05-06-2020 10:05 AM

Hello Everyone,

I appologize for the long thread but I had to provide background info first.

I know the general rule of thumb is for RR to drop the route if it sees a locally configured cluster ID part of the Cluster-List on the route. with that in mind, below is my scenario: (please note I am only sharing info regarding this portion of the network for sake of simplicity). please see picture for topology, sorry its something quick I put together. 

 

1- I have a IGP (OSPF Flat area0) network in core. both PE1 and PE2 have ibgp session with RR (over ospf area0), as well as labels between each other as well as RR. so PE1 and PE2 are clients of RR.

2- Routing-Instance TEST-INET is built on PE1 and PE2. PE1 sees PE2's directly attached subnets(PC2), and PE2 sees PE1's directly attaches subnets (PC1).  this shows RR is doing its job just fine. 

3- Here is where it becomes interesting. This RR is in-line for Internet traffic for the instance. meaning RR has 3 BGP groups. 

A: EBGP with upstream-works!

B: MPBGP with PE1/PE2 over ospf area0 for route reflecting purposes-works!

C: iBGP over a single link (/31 IP) to PE2. this link is part of Instance TEST-INET- works to some extent

4- RR advertises a default into PE2 (routing-instance TEST-INET) and imports all routes exported by PE2 (again from instance INET-TEST). 

5- RR sees PE2s directly connected routes (PC2) and can ping it. PE2 receive the default route as expected.

6- RR does NOT see PE1s directly connected routes. PE1 receives the default route RR advertised to PE2. 

 

And here is the problem: PE2 sees PE1 routes and is advertising all routes in the instance to RR. RR only receives PE2 routes and not PE1 routes. log is not showing anything but a traceoption shows a few lines that basically state the route was released by RR. here is an example log entry:

May 6 01:28:07.686184 bgp_rcv_nlri: 10.10.18.0/30
May 6 01:28:07.686193 bgp_rcv_nlri: Uninstalling 10.10.18.0/30: route entry not found

 

I dont see any indication of this being blocked due to cluster-id in traceoption but I see no other reason for it to drop those routes. I also dont see any hidden routes. I added another router to the mix, basically replicated RR minus the MPBGP session for Route reflecting functionality. this router receives all routes as expected! so im at a loss to what is causing this behavior on RR? how to work around it or if so, what is the major design flaw with this?

how can I use a router a RR for mpbgp while being a typical ibgp router with a neighbor to allow incoming routes from the L3VPN that itself controls (as far as route reditribution between PEs I mean).

 

below is the configs I think related to this setup for your refrence:

**************PE1:**************
set protocols ospf traffic-engineering
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 interface-type p2p
set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 interface-type p2p
set protocols ospf area 0.0.0.0 interface ge-0/0/3.0 interface-type p2p
set protocols ospf area 0.0.0.0 interface lo0.0 passive

set protocols bgp group RR-MPBGP type internal
set protocols bgp group RR-MPBGP description "Internal BGP to RR"
set protocols bgp group RR-MPBGP local-address 1.1.1.1
set protocols bgp group RR-MPBGP family inet-vpn unicast
set protocols bgp group RR-MPBGP family inet6-vpn unicast
set protocols bgp group RR-MPBGP family l2vpn signaling
set protocols bgp group RR-MPBGP family evpn signaling
set protocols bgp group RR-MPBGP family route-target
set protocols bgp group RR-MPBGP peer-as 65019
set protocols bgp group RR-MPBGP neighbor 100.100.100.100

set interfaces lo0 unit 0 family inet address 1.1.1.1/32
set interfaces lo0 unit 5001 family inet address 172.16.255.12/32

set routing-instances TEST-INET instance-type vrf
set routing-instances TEST-INET interface ge-0/0/7.0  (PC1)
set routing-instances TEST-INET interface lo0.5001
set routing-instances TEST-INET route-distinguisher 172.16.255.12:5001
set routing-instances TEST-INET vrf-target target:65019:5001
set routing-instances TEST-INET vrf-table-label
set routing-instances TEST-INET routing-options router-id 172.16.255.12
**************PE2:**************
set protocols bgp group RR-MPBGP type internal
set protocols bgp group RR-MPBGP description "Internal BGP to RR"
set protocols bgp group RR-MPBGP local-address 2.2.2.2
set protocols bgp group RR-MPBGP family inet-vpn unicast
set protocols bgp group RR-MPBGP family inet6-vpn unicast
set protocols bgp group RR-MPBGP family l2vpn signaling
set protocols bgp group RR-MPBGP family evpn signaling
set protocols bgp group RR-MPBGP family route-target
set protocols bgp group RR-MPBGP peer-as 65019
set protocols bgp group RR-MPBGP neighbor 100.100.100.100

set protocols ospf traffic-engineering
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 interface-type p2p #Links to P routers
set protocols ospf area 0.0.0.0 interface ge-0/0/3.0 interface-type p2p #Links to P routers

set interfaces lo0 unit 0 family inet address 2.2.2.2/32
set interfaces lo0 unit 5001 family inet address 172.16.255.7/32
set interfaces ge-0/0/7 description "Link to RR"
set interfaces ge-0/0/7 flexible-vlan-tagging
set interfaces ge-0/0/7 encapsulation flexible-ethernet-services
set interfaces ge-0/0/7 unit 100 description "TEST-INET GATEWAY"
set interfaces ge-0/0/7 unit 100 vlan-id 100
set interfaces ge-0/0/7 unit 100 family inet address 172.27.7.1/31


set routing-instances TEST-INET instance-type vrf
set routing-instances TEST-INET interface ge-0/0/0.0  (PC2)
set routing-instances TEST-INET interface ge-0/0/7.100  (Connected to RR for Internet)
set routing-instances TEST-INET interface lo0.5001
set routing-instances TEST-INET route-distinguisher 172.16.255.7:5001
set routing-instances TEST-INET vrf-target target:65019:5001
set routing-instances TEST-INET vrf-table-label
set routing-instances TEST-INET routing-options router-id 172.16.255.7
set routing-instances TEST-INET protocols bgp group RR-INET type internal
set routing-instances TEST-INET protocols bgp group RR-INET family inet unicast
set routing-instances TEST-INET protocols bgp group RR-INET family inet6 unicast
set routing-instances TEST-INET protocols bgp group RR-INET export EXPORT-TEST-INET

set routing-instances TEST-INET protocols bgp group RR-INET peer-as 65019
set routing-instances TEST-INET protocols bgp group RR-INET local-as 65019
set routing-instances TEST-INET protocols bgp group RR-INET neighbor 172.27.7.0 import DEFAULT-ROUTE-IMPORT-LP100


set policy-options policy-statement EXPORT-TEST-INET term accept-temp then accept
set policy-options policy-statement DEFAULT-ROUTE-IMPORT-LP100 term DEFAULT-V4 from route-filter 0.0.0.0/0 exact
set policy-options policy-statement DEFAULT-ROUTE-IMPORT-LP100 term DEFAULT-V4 then local-preference 100
set policy-options policy-statement DEFAULT-ROUTE-IMPORT-LP100 term DEFAULT-V4 then accept
set policy-options policy-statement DEFAULT-ROUTE-IMPORT-LP100 term DEFAULT-V6 from route-filter ::/0 exact
set policy-options policy-statement DEFAULT-ROUTE-IMPORT-LP100 term DEFAULT-V6 then local-preference 100
set policy-options policy-statement DEFAULT-ROUTE-IMPORT-LP100 term DEFAULT-V6 then accept
set policy-options policy-statement DEFAULT-ROUTE-IMPORT-LP100 term REJECT then reject
**************RR:**************
set protocols bgp group EBGP type external
set protocols bgp group EBGP local-address 172.26.255.7
set protocols bgp group EBGP import FULL-TABLE-IMPORT
set protocols bgp group EBGP family inet unicast
set protocols bgp group EBGP family inet6 unicast
set protocols bgp group EBGP export FULL-TABLE-EXPORT
set protocols bgp group EBGP peer-as 65020
set protocols bgp group EBGP local-as 65019
set protocols bgp group EBGP neighbor 172.24.255.7
set protocols bgp group TEST-INET type internal
set protocols bgp group TEST-INET import IMPORT-ONNET
set protocols bgp group TEST-INET family inet unicast
set protocols bgp group TEST-INET family inet6 unicast
set protocols bgp group TEST-INET export EXPORT-DEFAULT
set protocols bgp group TEST-INET peer-as 65019
set protocols bgp group TEST-INET local-as 65019
set protocols bgp group TEST-INET neighbor 172.27.7.1
set protocols bgp group RR-PE-MPBGP type internal
set protocols bgp group RR-PE-MPBGP local-address 100.100.100.100
set protocols bgp group RR-PE-MPBGP family inet-vpn unicast
set protocols bgp group RR-PE-MPBGP family inet6-vpn unicast
set protocols bgp group RR-PE-MPBGP family l2vpn signaling
set protocols bgp group RR-PE-MPBGP family evpn signaling
set protocols bgp group RR-PE-MPBGP family route-target
set protocols bgp group RR-PE-MPBGP cluster 19.0.0.9
set protocols bgp group RR-PE-MPBGP peer-as 65019
set protocols bgp group RR-PE-MPBGP local-as 65019
set protocols bgp group RR-PE-MPBGP neighbor 2.2.2.2
set protocols bgp group RR-PE-MPBGP neighbor 1.1.1.1

set policy-options policy-statement IMPORT-ONNET term ACCEPT from protocol bgp
set policy-options policy-statement IMPORT-ONNET term ACCEPT then accept

set policy-options policy-statement EXPORT-DEFAULT term ACCEPT from route-filter 0.0.0.0/0 exact
set policy-options policy-statement EXPORT-DEFAULT term ACCEPT then accept

Here are my Routing tables:

**************PE1:**************
show route table TEST-INET.inet.0 TEST-INET.inet.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 *[BGP/170] 15:09:22, localpref 100, from 100.100.100.100 AS path: I, validation-state: unverified > to 172.16.14.0 via ge-0/0/3.0, label-switched-path to-PE2 10.10.18.0/30 *[Direct/0] 17:49:30 > via ge-0/0/7.0 10.10.18.2/32 *[Local/0] 17:49:30 Local via ge-0/0/7.0 10.20.18.0/30 *[BGP/170] 15:40:52, localpref 100, from 100.100.100.100 AS path: I, validation-state: unverified > to 172.16.14.0 via ge-0/0/3.0, label-switched-path to-PE2 172.27.7.0/31 *[BGP/170] 15:40:52, localpref 100, from 100.100.100.100 AS path: I, validation-state: unverified > to 172.16.14.0 via ge-0/0/3.0, label-switched-path to-PE2 2.2.2.2/32 *[BGP/170] 15:40:52, localpref 100, from 100.100.100.100 AS path: I, validation-state: unverified > to 172.16.14.0 via ge-0/0/3.0, label-switched-path to-PE2 1.1.1.1/32 *[Direct/0] 15:44:02 > via lo0.5001 show route table inet.3 inet.3: 24 destinations, 27 routes (2 active, 0 holddown, 24 hidden) + = Active Route, - = Last Active, * = Both 2.2.2.2/32 *[RSVP/7/1] 17:49:00, metric 2 > to 172.16.14.0 via ge-0/0/3.0, label-switched-path to-PE2 100.100.100.100/32 *[RSVP/7/1] 23:08:08, metric 4 > to 172.16.14.0 via ge-0/0/3.0, label-switched-path to-RR
**************PE2:**************
show route table TEST-INET.inet.0 TEST-INET.inet.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 *[BGP/170] 14:39:27, localpref 100 AS path: I, validation-state: unverified > to 172.27.7.0 via ge-0/0/7.100 10.10.18.0/30 *[BGP/170] 15:09:44, localpref 100, from 100.100.100.100 AS path: I, validation-state: unverified > to 172.16.7.0 via ge-0/0/1.0, label-switched-path to-PE1 10.10.20.0/30 *[Direct/0] 16:43:15 > via ge-0/0/0.0 10.10.20.1/32 *[Local/0] 16:43:15 Local via ge-0/0/0.0 172.27.7.0/31 *[Direct/0] 17:53:05 > via ge-0/0/7.100 172.27.7.1/32 *[Local/0] 17:53:05 Local via ge-0/0/7.100 2.2.2.2/32 *[Direct/0] 15:13:25 > via lo0.5001 1.1.1.1/32 *[BGP/170] 15:09:44, localpref 100, from 100.100.100.100 AS path: I, validation-state: unverified > to 172.16.7.0 via ge-0/0/1.0, label-switched-path to-PE1 show route table inet.3 inet.3: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 172.16.255.12/32 *[RSVP/7/1] 17:10:11, metric 2 > to 172.16.7.0 via ge-0/0/1.0, label-switched-path to-PE1 100.100.100.100/32 *[RSVP/7/1] 17:00:57, metric 2 > to 172.25.7.3 via ge-0/0/3.0, label-switched-path to-RR
**************RR:**************
show route table bgp.l3vpn.0 

bgp.l3vpn.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

2.2.2.2:5001:0.0.0.0/0                 
                   *[BGP/170] 15:18:24, localpref 100, from 2.2.2.2
                      AS path: I, validation-state: unverified
                    > to 172.26.7.0 via ge-0/0/0.0, label-switched-path to-PE2
2.2.2.2:5001:10.20.18.0/30                
                   *[BGP/170] 15:49:54, localpref 100, from 2.2.2.2
                      AS path: I, validation-state: unverified
                    > to 172.26.7.0 via ge-0/0/0.0, label-switched-path to-PE2
2.2.2.2:5001:172.27.7.0/31                
                   *[BGP/170] 15:49:54, localpref 100, from 2.2.2.2
                      AS path: I, validation-state: unverified
                    > to 172.26.7.0 via ge-0/0/0.0, label-switched-path to-PE2
2.2.2.2:5001:172.16.255.7/32                
                   *[BGP/170] 15:49:54, localpref 100, from 2.2.2.2
                      AS path: I, validation-state: unverified
                    > to 172.26.7.0 via ge-0/0/0.0, label-switched-path to-PE2

1.1.1.1:5001:10.10.18.0/30                
                   *[BGP/170] 15:49:59, localpref 100, from 1.1.1.1
                      AS path: I, validation-state: unverified
                    > to 172.26.7.0 via ge-0/0/0.0, label-switched-path to-PE1
1.1.1.1:5001:172.16.255.12/32                
                   *[BGP/170] 15:49:59, localpref 100, from 1.1.1.1
                      AS path: I, validation-state: unverified
                    > to 172.26.7.0 via ge-0/0/0.0, label-switched-path to-PE1

show route table bgp.rtarget.0  

bgp.rtarget.0: 1 destinations, 2 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

65019:65019:5001/96                
                   *[BGP/170] 15:50:05, localpref 100, from 2.2.2.2
                      AS path: I, validation-state: unverified
                    > to 172.26.7.0 via ge-0/0/0.0, label-switched-path to-PE2
                    [BGP/170] 15:50:10, localpref 100, from 1.1.1.1
                      AS path: I, validation-state: unverified
                    > to 172.26.7.0 via ge-0/0/0.0, label-switched-path to-PE1

show route 10/8          

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

10.20.18.0/30      *[BGP/170] 15:23:31, localpref 100
                      AS path: I, validation-state: unverified
                    > to 172.27.7.1 via ge-0/0/7.100

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

2.2.2.2:5001:10.20.18.0/30                
                   *[BGP/170] 15:55:01, localpref 100, from 2.2.2.2
                      AS path: I, validation-state: unverified
                    > to 172.26.7.0 via ge-0/0/0.0, label-switched-path to-PE2
1.1.1.1:5001:10.10.18.0/30                
                   *[BGP/170] 15:55:06, localpref 100, from 1.1.1.1
                      AS path: I, validation-state: unverified
                    > to 172.26.7.0 via ge-0/0/0.0, label-switched-path to-PE1

 

Capture.PNG

 

8 REPLIES 8
Highlighted
Routing

Re: Route Reflector Design concerns

[ Edited ]
‎05-06-2020 10:22 AM

Hello,

 

Please share the following printout from PE2:

 

show route advertising-protocol bgp 172.27.7.0 extensive | no-more

 

This will give a clue what's wrong.

HTH

Thx

Alex

_____________________________________________________________________

Please ask Your Juniper account team about Juniper Professional Services offerings.
Juniper PS can design, test & build the network/part of the network as per Your requirements

+++++++++++++++++++++++++++++++++++++++++++++

Accept as Solution = cool !
Accept as Solution+Kudo = You are a Star !
Highlighted
Routing

Re: Route Reflector Design concerns

‎05-06-2020 10:58 AM

Alex, thank you for your time. please see below.

NOTE: please note I have changed or ommited some of the output to remain anonymous and to simplify the problem. thats why you might see some inconsistancy as far how many routes are active or what not or maybe an inconsistent AS#. 

 

 

from PE2:

show route advertising-protocol bgp 172.27.7.0 extensive
TEST-INET.inet.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden)

* 10.10.18.0/30 (1 entry, 1 announced)
 BGP group RR-PE-MPBGP type Internal
     Nexthop: Self
     Flags: Nexthop Change
     Localpref: 100                     
     AS path: [65019] I (Originator)
     Cluster list:  19.0.0.9
     Originator ID: 1.1.1.1
     Communities: target:65019:5001

* 10.20.18.0/30 (1 entry, 1 announced)
 BGP group RR-PE-MPBGP type Internal
     Nexthop: Self
     Localpref: 100
     AS path: [65019] I

* 172.27.7.0/31 (1 entry, 1 announced)
 BGP group RR-PE-MPBGP type Internal
     Nexthop: Self
     Localpref: 100
     AS path: [65019] I


* 172.16.255.7/32 (1 entry, 1 announced)
 BGP group RR-PE-MPBGP type Internal
     Nexthop: Self
     Localpref: 100
     AS path: [65019] I

* 172.16.255.12/32 (1 entry, 1 announced)
 BGP group RR-PE-MPBGP type Internal
     Nexthop: Self
     Flags: Nexthop Change
     Localpref: 100
     AS path: [65019] I (Originator)
     Cluster list:  19.0.0.9
     Originator ID: 1.1.1.1
     Communities: target:65019:5001

and here is what RR receives/accepts:

show route receive-protocol bgp 172.27.7.1

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

* 10.20.18.0/30 (1 entry, 1 announced)
     Accepted
     Nexthop: 172.27.7.1
     Localpref: 100
     AS path: I

  172.27.7.0/31 (2 entries, 1 announced)
     Accepted
     Nexthop: 172.27.7.1
     Localpref: 100
     AS path: I

* 172.16.255.7/32 (1 entry, 1 announced)
     Accepted
     Nexthop: 172.27.7.1
     Localpref: 100
     AS path: I

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

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

bgp.l3vpn.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)

bgp.rtarget.0: 1 destinations, 2 routes (1 active, 0 holddown, 0 hidden)

one more thing I notices while I was troubleshooting, on PE2, if I change the export policy from:

set policy-options policy-statement EXPORT-TEST-INET term accept-temp then accept

to:

set policy-options policy-statement EXPORT-TEST-INET term accept-temp from instance TEST-INET
set policy-options policy-statement EXPORT-TEST-INET term accept-temp then accept

then PE2 will no longer advertise PE1's routes to RR. it simply only advertises all local routes from that instance:

TEST-INET.inet.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden)

* 10.20.18.0/30 (1 entry, 1 announced)
 BGP group RR-PE-MPBGP type Internal
     Nexthop: Self
     Localpref: 100
     AS path: [65019] I

* 172.27.7.0/31 (1 entry, 1 announced)
 BGP group RR-PE-MPBGP type Internal
     Nexthop: Self
     Localpref: 100
     AS path: [65019] I

* 172.16.255.7/32 (1 entry, 1 announced)
 BGP group RR-PE-MPBGP type Internal
     Nexthop: Self
     Localpref: 100
     AS path: [65019] I

is the reason obvious to you? 

Highlighted
Routing
Solution
Accepted by topic author ali.taheri
‎05-07-2020 05:12 AM

Re: Route Reflector Design concerns

[ Edited ]
‎05-06-2020 11:43 AM

Hello,

 


@ali.taheri wrote:

 

 

from PE2:

show route advertising-protocol bgp 172.27.7.0 extensive
TEST-INET.inet.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden)

* 10.10.18.0/30 (1 entry, 1 announced)
 BGP group RR-PE-MPBGP type Internal
     Nexthop: Self
     Flags: Nexthop Change
     Localpref: 100                     
     AS path: [65019] I (Originator)
     Cluster list:  19.0.0.9
     Originator ID: 1.1.1.1
     Communities: target:65019:5001


 

Here is Your answer - this route has cluster-list that includes RR "cluster-id" 19.0.0.9

By default, JUNOS checks cluster-lists of all incoming routes for cluster-ids configured in all own routing-instances and GRT.

Then such route is dropped and does not even show as hidden.

Please enable "independent-domain" inside VRF TEST-INET on PE1 and PE2 and then share the fresh printout "show route advertising-protocol bgp 172.27.7.0 extensive" from PE2

https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/independe...

HTH

Thx

Alex

 

 

 

 

 

_____________________________________________________________________

Please ask Your Juniper account team about Juniper Professional Services offerings.
Juniper PS can design, test & build the network/part of the network as per Your requirements

+++++++++++++++++++++++++++++++++++++++++++++

Accept as Solution = cool !
Accept as Solution+Kudo = You are a Star !
Highlighted
Routing

Re: Route Reflector Design concerns

[ Edited ]
‎05-06-2020 12:04 PM

Alex, Yeah I was sure it is being dropped because of the cluster-list/id but wasnt sure how to get around it.

 

I made below change on both PE1 and PE2 vrf:

 show configuration | compare rollback 1    
[edit routing-instances TEST-INET routing-options]
+     autonomous-system 65019 independent-domain;

and routes are visible now on RR! Kudos to you right there.

RR:
show route 10/8                                     
inet.0: 75 destinations, 76 routes (75 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.10.18.0/30      *[BGP/170] 00:06:03, localpref 100
                      AS path: I, validation-state: unverified
                    > to 172.27.7.1 via ge-0/0/7.100
10.20.18.0/30      *[BGP/170] 17:32:46, localpref 100
                      AS path: I, validation-state: unverified
                    > to 172.27.7.1 via ge-0/0/7.100

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

2.2.2.2:5001:10.20.18.0/30                
                   *[BGP/170] 00:07:30, localpref 100, from 2.2.2.2
                      AS path: I, validation-state: unverified
                    > to 172.26.7.0 via ge-0/0/0.0, label-switched-path to-PE2
1.1.1.1:5001:10.10.18.0/30                
                   *[BGP/170] 00:08:00, localpref 100, from 1.1.1.1
                      AS path: I, validation-state: unverified
                    > to 172.26.7.0 via ge-0/0/0.0, label-switched-path to-PE1

and here is my advertising routes from PE2 incase needed:

sorry forgot to share the advertising route from PE2:

show route advertising-protocol bgp 172.27.7.0 extensive
TEST-INET.inet.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden)
* 10.10.18.0/30 (1 entry, 1 announced)
 BGP group RR-PE-MPBGP type Internal
     Nexthop: Self
     Flags: Nexthop Change
     Localpref: 100
     AS path: [65019] I

* 10.20.18.0/30 (1 entry, 1 announced)  
 BGP group RR-PE-MPBGP type Internal
     Nexthop: Self
     Localpref: 100
     AS path: [65019] I

* 172.27.7.0/31 (1 entry, 1 announced)
 BGP group RR-PE-MPBGP type Internal
     Nexthop: Self
     Localpref: 100
     AS path: [65019] I

* 172.16.255.7/32 (1 entry, 1 announced)
 BGP group RR-PE-MPBGP type Internal
     Nexthop: Self
     Localpref: 100
     AS path: [65019] I
                                        
* 172.16.255.12/32 (1 entry, 1 announced)
 BGP group RR-PE-MPBGP type Internal
     Nexthop: Self
     Flags: Nexthop Change
     Localpref: 100
     AS path: [65019] I


I read https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/independe... but its still not clear to me what this knob does. whats actually happening under the hood, can you clarify this abit? 

 

Also, any idea why my export policy (including "from instance TEST-INET" under from) behaves that way? I explained this in detail at the end of my last reply. 

Highlighted
Routing

Re: Route Reflector Design concerns

‎05-06-2020 06:25 PM

Alex,

To further develop the project, there are 2 Border routers between my RR and providers. 

RR AS65019

BR1: 65019

BR2: 65020

 

My goal is to have RR advertise these routes it has learned from PE2 (per above scenarios) to both BRs. one over iBGP and another over eBGP for redundancy upstream from my core. 

 

RR advertises the routes I want to BR2 over eBGP but not to BR1 over iBGP. I have a policy that I specified a simple Route-Filter to include the subnets RR should advertise, with a next-hop self and accept. this is the same for both subnets coming from the L3VPN: 10.10.18.0/30 from PE1 and 10.20.18.0/30 form PE2. 

 

Both routes are available on RR, but it wont advertise it to its upstream iBGP peer. eBGP upstream peer receives and accepts the route and I can ping rmeote hosts. does this ring a bell? 

 

I added another /30 directly on the RR for testing  purposes, this route makes it to both BRs unline 10.10.18/30 and 10.20.18/30. 

 

I also noticed 

Highlighted
Routing

Re: Route Reflector Design concerns

[ Edited ]
‎05-06-2020 10:57 PM

Hello,

 


@ali.taheri wrote:


I read https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/independe... but its still not clear to me what this knob does. whats actually happening under the hood, can you clarify this abit? 

 

 

On route-originating PE, "independent-domain" knob encapsulates and tunnels original route attributes in BGP attribute-set 128.

On route-receiving PE, the original route attributes get decapsulated & reattached to the route.

The additional attributes that were added during MPLS core transition such as cluster-list and originator-id get discarded.

Please see   https://tools.ietf.org/html/draft-marques-ppvpn-ibgp-00 for more info.

 

HTH

Thx

Alex

_____________________________________________________________________

Please ask Your Juniper account team about Juniper Professional Services offerings.
Juniper PS can design, test & build the network/part of the network as per Your requirements

+++++++++++++++++++++++++++++++++++++++++++++

Accept as Solution = cool !
Accept as Solution+Kudo = You are a Star !
Highlighted
Routing

Re: Route Reflector Design concerns

‎05-06-2020 11:05 PM

Hello,

 


@ali.taheri wrote:

 

 

RR advertises the routes I want to BR2 over eBGP but not to BR1 over iBGP. I have a policy that I specified a simple Route-Filter to include the subnets RR should advertise, with a next-hop self and accept. this is the same for both subnets coming from the L3VPN: 10.10.18.0/30 from PE1 and 10.20.18.0/30 form PE2. 

 

Both routes are available on RR, but it wont advertise it to its upstream iBGP peer. eBGP upstream peer receives and accepts the route and I can ping rmeote hosts. does this ring a bell? 

 

I do not see this happening in my lab.

But then hairpinning traffic thru inline RR does not make any sense to me, together with using iBGP as PE-CE protocol.

This is probably good for learning but I won't do such design ever if You ask me. 

There are too many iBGP limitations to drive one crazy after countless sleepless nights spent on debugging this stuff in production (if it gets into production).

Use PE-CE eBGP with offpath RR and You are golden, trust me Smiley Happy

HTH

Thx

Alex

_____________________________________________________________________

Please ask Your Juniper account team about Juniper Professional Services offerings.
Juniper PS can design, test & build the network/part of the network as per Your requirements

+++++++++++++++++++++++++++++++++++++++++++++

Accept as Solution = cool !
Accept as Solution+Kudo = You are a Star !
Highlighted
Routing

Re: Route Reflector Design concerns

‎05-07-2020 05:11 AM

Alex,

the RFC draft did the trick, thanks for sharing!

I agree with you that iBGPs limitation can drive you mad, been there done that. all these issues go away the minute I move the RR (MPBGP for PEs) functionality to some other router. thanks again for your continues help! 

Feedback