Routing

 View Only
last person joined: 3 days ago 

Ask questions and share experiences about ACX Series, CTP Series, MX Series, PTX Series, SSR Series, JRR Series, and all things routing, including portfolios and protocols.
  • 1.  Route Reflector Design concerns

    Posted 05-06-2020 10:05

    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

     


    #cluster-id
    #rr
    #BGP
    #routereflector


  • 2.  RE: Route Reflector Design concerns

    Posted 05-06-2020 10:23

    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



  • 3.  RE: Route Reflector Design concerns

    Posted 05-06-2020 10:58

    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? 



  • 4.  RE: Route Reflector Design concerns
    Best Answer

    Posted 05-06-2020 11:43

    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/independent-domain-edit-routing-options.html

    HTH

    Thx

    Alex

     

     

     

     

     



  • 5.  RE: Route Reflector Design concerns

    Posted 05-06-2020 12:05

    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/independent-domain-edit-routing-options.html 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. 



  • 6.  RE: Route Reflector Design concerns

    Posted 05-06-2020 22:57

    Hello,

     


    @ali.taheri wrote:


    I read https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/independent-domain-edit-routing-options.html 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



  • 7.  RE: Route Reflector Design concerns

    Posted 05-06-2020 18:26

    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 



  • 8.  RE: Route Reflector Design concerns

    Posted 05-06-2020 23:06

    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 

    HTH

    Thx

    Alex



  • 9.  RE: Route Reflector Design concerns

    Posted 05-07-2020 05:12

    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!