Category Archives: BGP

Circuit Cross Connect (RSVP-based CCC)

Posted on by
Reply

Configuration

PE1#

/* If logical systems are used for the lab, then 
 * The physical interface encapsulation (ethernet-ccc) is configured 
 * at the global level - NOT at logical system level
 */
 interface {
    ge-1/1/0 {
        encapsulation ethernet-ccc;
        unit 0 {
            description "PE1->CE1 | Physical interface";
        }    
    }
}

protocols {
    rsvp {
        /* PE1->P1 */
        interface lt-0/0/10.1101;
    }
    mpls {
        label-switched-path PE1-to-PE2 {
            to 12.12.12.12;
            no-cspf;
        }
        /* PE1->P1 */
        interface lt-0/0/10.1101;
    }
    ospf {
        area 0.0.0.0 {
            /* PE1 Loopback */
            interface lo0.11;
            /* PE1->P1 */
            interface lt-0/0/10.1101;
        }
    }
    connections {
        remote-interface-switch CE1-to-CE2 {
            interface ge-1/1/0.0;
            transmit-lsp PE1-to-PE2;
            receive-lsp PE2-to-PE1;
        }
    }
}



PE2#

interface {
    ge-1/1/1 {
        encapsulation ethernet-ccc;
        unit 0 {
            description "PE2->CE2 | Physical interface";
        }    
    }
}

protocols {
    rsvp {
        /* PE2->P3 */
        interface lt-0/0/10.123;
    }
    mpls {
        label-switched-path PE2-to-PE1 {
            to 11.11.11.11;             
            no-cspf;
        }
        /* PE2->P3 */
        interface lt-0/0/10.123;
    }
    ospf {
        area 0.0.0.0 {
            /* PE2->P3 */
            interface lt-0/0/10.123;
            /* PE2 Loopback */
            interface lo0.12;
        }
    }
    connections {
        remote-interface-switch CE2-to-CE1 {
            interface ge-1/1/1.0;
            transmit-lsp PE2-to-PE1;
            receive-lsp PE1-to-PE2;
        }
    }
}

Verification

pe1@MX:PE1> show connections | find Connection/Circuit 
Connection/Circuit                Type        St      Time last up     # Up trans
CE1-to-CE2                        rmt-if      Up      Jul 20 07:08:43           1
  ge-1/1/0.0                        intf  Up
  PE1-to-PE2                        tlsp  Up
  PE2-to-PE1                        rlsp  Up
  
pe1@MX:PE1> show connections labels 
Connection/Circuit                Type        St      Time last up     # Up trans
CE1-to-CE2                        rmt-if      Up      Jul 20 07:08:43           1
  Incoming labels: 300512
  Outgoing labels: Push 300144

The above labels (incoming of 300512, and outgoing of 300144) are exchanged via RSVP

pe1@MX:PE1> show rsvp session 
Ingress RSVP: 1 sessions
To              From            State   Rt Style Labelin Labelout LSPname 
12.12.12.12     11.11.11.11     Up       0  1 FF       -   300144 PE1-to-PE2
Total 1 displayed, Up 1, Down 0

Egress RSVP: 1 sessions
To              From            State   Rt Style Labelin Labelout LSPname 
11.11.11.11     12.12.12.12     Up       0  1 FF  300512        - PE2-to-PE1
Total 1 displayed, Up 1, Down 0

Transit RSVP: 0 sessions
Total 0 displayed, Up 0, Down 0


pe1@MX:PE1> show route table mpls.0  

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

0                  *[MPLS/0] 01:38:01, metric 1
                      Receive
1                  *[MPLS/0] 01:38:01, metric 1
                      Receive
2                  *[MPLS/0] 01:38:01, metric 1
                      Receive
300512             *[CCC/7] 01:28:45
                    > via ge-1/1/0.0, Pop      
ge-1/1/0.0         *[CCC/7/1] 01:28:45, metric 4
                    > to 100.1.11.1 via lt-0/0/10.1101, label-switched-path PE1-to-PE2

Note one big difference of CCC compared to BGP/LDP based VPLS, BGP based L2VPN, LDP based L2CKT is that CCC does not support tunnel stacking. There is only one label used to encapsulate CCC traffic. For the other L2 technologies, there are two labels in use: one transport label (outer), and another inner one, which is VPN or CKT label.

BGP based L2VPN

Posted on by
Reply

Configuration

PE1#

/* If logical systems are used for the lab, then 
 * The physical interface encapsulation (ethernet-ccc) is configured 
 * at the global level - NOT at logical system level
 */
interface {
    ge-1/1/0 {
        encapsulation ethernet-ccc;
        unit 0 {
            description "PE1->CE1 | Physical interface";
        }    
    }
}

protocols {
    mpls {
        /* PE1->P1 */
        interface lt-0/0/10.1101;
    }
    bgp {
        group PE2 {                     
            type internal;
            local-address 11.11.11.11;
            family l2vpn {
                signaling;
            }
            neighbor 12.12.12.12;
        }
    }
    ospf {
        area 0.0.0.0 {
            /* PE1->P1 */
            interface lt-0/0/10.1101;
            /* PE1 Loopback */
            interface lo0.11;
        }
    }
    ldp {
        /* PE1->P1 */
        interface lt-0/0/10.1101;
        /* PE1 Loopback */
        interface lo0.11;
    }
}
routing-instances {
    L2VPN_1 {
        instance-type l2vpn;            
        interface ge-1/1/0.0;
        route-distinguisher 11.11.11.11:1001;
        vrf-target target:100:1001;
        protocols {
            l2vpn {
                encapsulation-type ethernet;
                interface ge-1/1/0.0;
                site CE1 {
                    site-identifier 1;
                    interface ge-1/1/0.0;
                }
            }
        }
    }
}



PE2#

/* If logical systems are used for the lab, then 
 * The physical interface encapsulation (ethernet-ccc) is configured 
 * at the global level - NOT at logical system level
 */
interface {
    ge-1/1/1 {
        encapsulation ethernet-ccc;
        unit 0 {
            description "PE2->CE2 | Physical interface";
        }    
    }
}


protocols {
    mpls {
        /* PE2->P3 */
        interface lt-0/0/10.123;
    }
    bgp {
        group PE1 {
            type internal;              
            local-address 12.12.12.12;
            family l2vpn {
                signaling;
            }
            neighbor 11.11.11.11;
        }
    }
    ospf {
        area 0.0.0.0 {
            /* PE2->P3 */
            interface lt-0/0/10.123;
            /* PE2 Loopback */
            interface lo0.12;
        }
    }
    ldp {
        /* PE2->P3 */
        interface lt-0/0/10.123;
        /* PE2 Loopback */
        interface lo0.12;
    }
}
routing-instances {
    L2VPN_1 {
        instance-type l2vpn;
        interface ge-1/1/1.0;           
        route-distinguisher 12.12.12.12:1001;
        vrf-target target:100:1001;
        protocols {
            l2vpn {
                encapsulation-type ethernet;
                site CE2 {
                    site-identifier 2;
                    interface ge-1/1/1.0 {
                        remote-site-id 1;
                    }
                }
            }
        }
    }
}

Verification

pe1@MX:PE1> show bgp summary          
Groups: 1 Peers: 1 Down peers: 0
Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
bgp.l2vpn.0          
                       1          1          0          0          0          0
Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
12.12.12.12             100         63         64       0       0       26:27 Establ
  bgp.l2vpn.0: 1/1/1/0
  L2VPN_1.l2vpn.0: 1/1/1/0

pe1@MX:PE1> show route receive-protocol bgp 12.12.12.12 detail 

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

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

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

bgp.l2vpn.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
*  12.12.12.12:1001:2:1/96 (1 entry, 0 announced)
     Import Accepted
     Route Distinguisher: 12.12.12.12:1001
     Label-base: 800000, range: 2, status-vector: 0x0 
     Nexthop: 12.12.12.12
     Localpref: 100
     AS path: I
     Communities: target:100:1001 Layer2-info: encaps:ETHERNET, control flags:Control-Word, mtu: 0, site preference: 100

L2VPN_1.l2vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)

*  12.12.12.12:1001:2:1/96 (1 entry, 1 announced)
     Import Accepted
     Route Distinguisher: 12.12.12.12:1001
     Label-base: 800000, range: 2, status-vector: 0x0 
     Nexthop: 12.12.12.12
     Localpref: 100
     AS path: I                         
     Communities: target:100:1001 Layer2-info: encaps:ETHERNET, control flags:Control-Word, mtu: 0, site preference: 100

pe1@MX:PE1> show route table l2vpn    

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

11.11.11.11:1001:1:1/96                
                   *[L2VPN/170/-101] 00:08:09, metric2 1
                      Indirect
12.12.12.12:1001:2:1/96                
                   *[BGP/170] 00:08:09, localpref 100, from 12.12.12.12
                      AS path: I
                    > to 100.1.11.1 via lt-0/0/10.1101, Push 300016

pe1@MX:PE1> show l2vpn connections | find L2VPN_1     

Instance: L2VPN_1
  Local site: CE1 (1)
    connection-site           Type  St     Time last up          # Up trans
    2                         rmt   Up     Jul 20 06:13:15 2014           1
      Remote PE: 12.12.12.12, Negotiated control-word: Yes (Null)
      Incoming label: 800001, Outgoing label: 800000
      Local interface: ge-1/1/0.0, Status: Up, Encapsulation: ETHERNET

BGP based VPLS

Posted on by
Reply

Configuration

PE1#

/* If Logical Systems are used for the lab
 * Note that the physical interface encapsulation of ethernet-vpls
 * is configured at the global level - Not at logical system level
 */
interface {
    ge-1/1/0 {
        encapsulation ethernet-vpls;
        unit 0 {
            description "PE1->CE1 | Physical interface";
        }    
    }
}

protocols {
    mpls {
        /* PE1->P1 */
        interface lt-0/0/10.1101;
    }
    bgp {
        group PE2 {                     
            type internal;
            local-address 11.11.11.11;
            family l2vpn {
                signaling;
            }
            neighbor 12.12.12.12;
        }
    }
    ospf {
        area 0.0.0.0 {
            /* PE1->P1 */
            interface lt-0/0/10.1101;
            /* PE1 Loopback */
            interface lo0.11;
        }
    }
    ldp {
        /* PE1->P1 */
        interface lt-0/0/10.1101;
        /* PE1 Loopback */
        interface lo0.11;
    }
}
routing-instances {
    VPLS_1 {
        instance-type vpls;             
        interface ge-1/1/0.0;
        route-distinguisher 11.11.11.11:1001;
        vrf-target target:100:1001;
        protocols {
            vpls {
                site-range 10;
                site CE1 {
                    site-identifier 1;
                    interface ge-1/1/0.0;
                }
            }
        }
    }
}



PE2#

interface {
    ge-1/1/1 {
        encapsulation ethernet-vpls;
        unit 0 {
            description "PE2->CE2 | Physical interface";
        }    
    }
}
protocols {
    mpls {
        /* PE2->P3 */
        interface lt-0/0/10.123;
    }
    bgp {
        family l2vpn {
            signaling;                  
        }
        group PE1 {
            type internal;
            local-address 12.12.12.12;
            neighbor 11.11.11.11;
        }
    }
    ospf {
        area 0.0.0.0 {
            /* PE2->P3 */
            interface lt-0/0/10.123;
            /* PE2 Loopback */
            interface lo0.12;
        }
    }
    ldp {
        /* PE2->P3 */
        interface lt-0/0/10.123;
        /* PE2 Loopback */
        interface lo0.12;
    }
}
routing-instances {
    VPLS_1 {
        instance-type vpls;
        interface ge-1/1/1.0;           
        route-distinguisher 12.12.12.12:1001;
        vrf-target target:100:1001;
        protocols {
            vpls {
                site-range 10;
                site CE2 {
                    site-identifier 2;
                    interface ge-1/1/1.0;
                }
            }
        }
    }
}

Verification

Verify that BGP is up, and exchange routes.

pe1@MX:PE1> show route receive-protocol bgp 12.12.12.12 
...
bgp.l2vpn.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
  12.12.12.12:1001:2:1/96                    
*                         12.12.12.12                  100        I

VPLS_1.l2vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
  12.12.12.12:1001:2:1/96                    
*                         12.12.12.12                  100        I

pe1@MX:PE1> show route advertising-protocol bgp 12.12.12.12 

VPLS_1.l2vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
  11.11.11.11:1001:1:1/96                    
*                         Self                         100        I

pe1@MX:PE1> show route table VPLS_1 extensive 

VPLS_1.l2vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
 11.11.11.11:1001:1:1/96 (1 entry, 1 announced)
TSI:
Page 0 idx 0 Type 1 val 27912b4
    Flags: Nexthop Change
    Nexthop: Self
    Localpref: 100
    AS path: [100] I
    Communities: target:100:1001 Layer2-info: encaps:VPLS, control flags:, mtu: 0, site preference: 100
Path 11.11.11.11:1001:1:1 Vector len 4.  Val: 0
        *L2VPN  Preference: 170/-101
                Next hop type: Indirect
                Address: 0x28183ec
                Next-hop reference count: 2
                Protocol next hop: 11.11.11.11
                Indirect next hop: 0 -
                State: 
                Age: 14:33      Metric2: 1 
                Task: VPLS_1-l2vpn
                Announcement bits (1): 1-BGP_RT_Background 
                AS path: I
                Communities: Layer2-info: encaps:VPLS, control flags:, mtu: 0, site preference: 100
                Label-base: 800008, range: 8, status-vector: 0x3F 

 12.12.12.12:1001:2:1/96 (1 entry, 1 announced)
        *BGP    Preference: 170/-101    
                Route Distinguisher: 12.12.12.12:1001
                Next hop type: Indirect
                Address: 0x281935c
                Next-hop reference count: 5
                Source: 12.12.12.12
                Protocol next hop: 12.12.12.12
                Indirect next hop: 2 no-forward
                State: 
                Local AS:   100 Peer AS:   100
                Age: 14:10      Metric2: 1 
                Task: BGP_100.12.12.12.12+65086
                Announcement bits (1): 0-VPLS_1-l2vpn 
                AS path: I
                Communities: target:100:1001 Layer2-info: encaps:VPLS, control flags:, mtu: 0, site preference: 100
                Import Accepted
                Label-base: 800008, range: 8
                Localpref: 100
                Router ID: 12.12.12.12
                Primary Routing Table bgp.l2vpn.0
                Indirect next hops: 1
                        Protocol next hop: 12.12.12.12 Metric: 1
                        Indirect next hop: 2 no-forward
                        Indirect path forwarding next hops: 1
                                Next hop type: Router
                                Next hop: 100.1.11.1 via lt-0/0/10.1101
                        12.12.12.12/32 Originating RIB: inet.3
                          Metric: 1                       Node path count: 1
                          Forwarding nexthops: 1
                                Nexthop: 100.1.11.1 via lt-0/0/10.1101

Verify VPLS connections

pe1@MX:PE1> show vpls connections | find VPLS_1              

Instance: VPLS_1
  Local site: CE1 (1)
    connection-site           Type  St     Time last up          # Up trans
    2                         rmt   Up     Jul 20 03:06:23 2014           1
      Remote PE: 12.12.12.12, Negotiated control-word: No
      Incoming label: 800009, Outgoing label: 800008
      Local interface: vt-1/0/10.168821250, Status: Up, Encapsulation: VPLS
        Description: Intf - vpls VPLS_1 local site 1 remote site 2

pe1@MX:PE1> show vpls connections extensive | find VPLS_1    

Instance: VPLS_1
  Local site: CE1 (1)
    Number of local interfaces: 1
    Number of local interfaces up: 1
    IRB interface present: no
    ge-1/1/0.0         
    vt-1/0/10.168821250 2         Intf - vpls VPLS_1 local site 1 remote site 2
    Label-base        Offset     Size  Range     Preference
    800008            1          8      8         100   
    connection-site           Type  St     Time last up          # Up trans
    2                         rmt   Up     Jul 20 03:06:23 2014           1
      Remote PE: 12.12.12.12, Negotiated control-word: No
      Incoming label: 800009, Outgoing label: 800008
      Local interface: vt-1/0/10.168821250, Status: Up, Encapsulation: VPLS
        Description: Intf - vpls VPLS_1 local site 1 remote site 2
    Connection History:
        Jul 20 03:06:23 2014  status update timer  
        Jul 20 03:06:23 2014  loc intf up           vt-1/0/10.168821250
        Jul 20 03:06:23 2014  PE route changed     
        Jul 20 03:06:23 2014  Out lbl Update                    800008
        Jul 20 03:06:23 2014  In lbl Update                     800009
        Jul 20 03:06:23 2014  loc intf down

Check VPLS MAC table, and statistics

pe1@MX:PE1> show vpls mac-table    

MAC flags (S -static MAC, D -dynamic MAC, L -locally learned
           SE -Statistics enabled, NM -Non configured MAC, R -Remote PE MAC)

Logical system   : PE1
Routing instance : VPLS_1
 Bridging domain : __VPLS_1__, VLAN : NA
   MAC                 MAC      Logical
   address             flags    interface 
   a8:d0:e5:55:26:50   D        ge-1/1/0.0           
   a8:d0:e5:55:26:51   D        vt-1/0/10.168821250  

pe1@MX:PE1> show vpls statistics 
VPLS statistics:

Instance: VPLS_1
   Local interface: ge-1/1/0.0, Index: 330
     Broadcast packets:                     5
     Broadcast bytes  :                   300
     Multicast packets:                     0
     Multicast bytes  :                     0
     Flooded packets  :                     1
     Flooded bytes    :                    98
     Unicast packets  :                  1010
     Unicast bytes    :                 98942
     Current MAC count:                     1 (Limit 1024)
   Local interface: vt-1/0/10.168821250, Index: 334
   Remote PE: 12.12.12.12
     Broadcast packets:                     2
     Broadcast bytes  :                   120
     Multicast packets:                     0
     Multicast bytes  :                     0
     Flooded packets  :                     0
     Flooded bytes    :                     0
     Unicast packets  :                  1006
     Unicast bytes    :                 98588
     Current MAC count:                     1

BGP export policy, and next-hop self

Posted on by
Reply

Task

In this lab, we investigate the next hop attribute for routes learnt from an eBGP neighbour, and the behaviour of the export policy applied to an iBGP neighbour. In the following diagram, P1 & P2 are peer via an iBGP in AS 12. P2 peers with P3  (in AS 3) via an eBGP.

We will show that:

  • Unlike the “catch all” deny policy in a Cisco outbound route-map for a BGP neighbour, the Juniper export policy has default “accept” term for prefixes that are explicitly matched, and also for default “catch-all” prefixes, that are not matched by any term. Prefixes can be explicitly denied with a reject term.
  • As the standard BGP behaviour (no difference from Cisco behaviour), routes learnt from an eBGP neighbour advertised to another iBGP neighbour with the next hop unchanged (of the eBGP neighbour), and can be seen by the iBGP peer as invalid routes if it does not know the route to the next hop.
  • Note that the above default action are specific for BGP. The default action is protocol dependent. If the same policy is used for a different protocol, then the default action can be different. Check the following link for the actual behavior http://www.juniper.net/documentation/en_US/junos13.3/topics/concept/policy-routing-policies-actions-defaults.html

Configuration & Verification

The following config shows the default BGP behaviour

p2@vr:p2> show configuration protocols bgp 
group EBGP {
    type external;
    peer-as 3;
    neighbor 172.22.206.2;
}
group IBGP {
    type internal;
    neighbor 172.22.201.1;
}

p2@vr:p2> show route protocol bgp 

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

10.3.1.0/24        *[BGP/170] 00:01:40, localpref 100
                      AS path: 3 I
                    > to 172.22.206.2 via em3.23
10.3.2.0/24        *[BGP/170] 00:01:40, localpref 100
                      AS path: 3 I
                    > to 172.22.206.2 via em3.23
10.3.3.0/24        *[BGP/170] 00:01:40, localpref 100
                      AS path: 3 I
                    > to 172.22.206.2 via em3.23

p1@vr:p1> show route protocol bgp 

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

p1@vr:p1> show route protocol bgp hidden          

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

10.3.1.0/24         [BGP/170] 00:01:31, localpref 100, from 172.22.201.2
                      AS path: 3 I
                      Unusable
10.3.2.0/24         [BGP/170] 00:01:31, localpref 100, from 172.22.201.2
                      AS path: 3 I
                      Unusable
10.3.3.0/24         [BGP/170] 00:01:31, localpref 100, from 172.22.201.2
                      AS path: 3 I
                      Unusable

p1@vr:p1> show route 10.3.1.0/24 hidden detail    

inet.0: 10 destinations, 10 routes (7 active, 0 holddown, 3 hidden)
10.3.1.0/24 (1 entry, 0 announced)
         BGP    Preference: 170/-101
                Next hop type: Unusable
                Address: 0x8d2f184
                Next-hop reference count: 3
                State: 
                Local AS:    12 Peer AS:    12
                Age: 1:49 
                Task: BGP_12.172.22.201.2+179
                AS path: 3 I
                Accepted
                Localpref: 100
                Router ID: 192.168.5.2

The following policy will change the next hop for the first prefix, deny the second prefix, and let go unchanged the last prefix.

[edit policy-options]
p2@vr:p2# show 
policy-statement set-next-hop-self {
    term 10 {
        from {
            route-filter 10.3.1.0/24 exact;
        }
        then {
            next-hop self;
            accept;      ## NOT REQUIRED
        }
    }
    term 20 {
        from {
            route-filter 10.3.2.0/24 exact;
        }
        then reject;
    }
}

[edit protocols bgp group IBGP]
p2@vr:p2# set export set-next-hop-self 

[edit protocols bgp group IBGP]
p2@vr:p2#commit

p1@vr:p1> show route protocol bgp 

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

10.3.1.0/24        *[BGP/170] 00:01:25, localpref 100
                      AS path: 3 I
                    > to 172.22.201.2 via em3.12

p1@vr:p1> show route protocol bgp hidden 

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

10.3.3.0/24         [BGP/170] 00:01:32, localpref 100, from 172.22.201.2
                      AS path: 3 I
                      Unusable

Notes

By default, all eBGP routes are advertised to iBGP peers. In other words, they are already “accepted” in the default export policy. Any new policy applied to the peer(s) will have a default catch-all accept term at the end. We don’t need to have an explicit “then accept” term.

However, by default, routes learnt from eBGP peers are advertised to iBGP peers with next hop (of eBGP) unchanged. If iBGP neighbours do not have routes to the next hop, all routes learnt are hidden. We need a term “then next-hop self” for that purpose.

We can also explicitly deny prefix with an explicit reject term.

As on P2, we only match first route 10.3.1.0/24 and change its next hop to P2. This route gets advertised to P1 properly. The second route is denied due to term 20. The third route remain advertised to P1 with next hop unchanged (of P3), and therefore remains hidden on R1.

Policy to Control LSP Selection

Posted on by
Reply

Task

  • Create two LSPs from PE1 to PE2 via two different paths P1-P2-P3 and P4-P5-P6, name them as lsp-1 and lsp-2, and similarly two LSPs in the opposite direction. LSP names can be the same, although a different ones will be easier for identification.
  • Create two static routes for 10.1.1.0 and 10.1.2.0 on PE1, and two static routes for 10.1.3.0/24 and 10.1.4.0/24 on PE2. Advertise them into BGP.
  • Create a policy so that PE1 chooses lsp-1for 10.1.3.0/24 and lsp-2 for 10.1.4.0/24. Likewise, PE2 chooses lsp-1 for 10.1.1.0/24 and lsp-2 for 10.1.2.0/24

Configuration

Create two LSPs from PE1 to PE2

lab@PE1> show configuration protocols mpls 
label-switched-path lsp-1 {
    to 192.168.1.2;
    primary one;
}
label-switched-path lsp-2 {
    to 192.168.1.2;
    primary two;
}
path one {
    192.168.5.1 loose;
    192.168.5.2 loose;
    192.168.5.3 loose;
}
path two {
    192.168.5.4 loose;
    192.168.5.5 loose;
    192.168.5.6 loose;
}
interface all;
interface em0.0 {
    disable;
}

Create two static routes, and advertise into BGP

lab@PE1> show configuration routing-options 
static {
    route 10.1.1.0/24 receive;
    route 10.1.2.0/24 receive;
}

lab@PE1> show configuration protocols bgp 
group my-int-group {
    type internal;
    local-address 192.168.1.1;
    export export-static;
    neighbor 192.168.1.2;
}

Create a policy to choose different LSPs for different destinations

                                         
lab@PE1> show configuration policy-options 

policy-statement lsp-policy {
    term lsp-1 {
        from {
            protocol bgp;
            route-filter 10.1.3.0/24 exact;
        }
        then {
            install-nexthop lsp lsp-1;
            accept;
        }
    }
    term lsp-2 {
        from {
            protocol bgp;
            route-filter 10.1.4.0/24 exact;
        }
        then {
            install-nexthop lsp lsp-2;
            accept;                     
        }
    }
}

lab@PE1> show configuration routing-options 
forwarding-table {
    export lsp-policy;
}

Verification

Verify that LSPs are up via different paths

lab@PE1> show mpls lsp ingress              
Ingress LSP: 2 sessions
To              From            State Rt P     ActivePath       LSPname
192.168.1.2     192.168.1.1     Up     0 *     one              lsp-1
192.168.1.2     192.168.1.1     Up     0 *     two              lsp-2
Total 2 displayed, Up 2, Down 0

lab@PE1> show mpls lsp ingress extensive 
Ingress LSP: 2 sessions

192.168.1.2
  From: 192.168.1.1, State: Up, ActiveRoute: 0, LSPname: lsp-1
  ActivePath: one (primary)
  LSPtype: Static Configured
  LoadBalance: Random
  Encoding type: Packet, Switching type: Packet, GPID: IPv4
 *Primary   one              State: Up
    Priorities: 7 0
    SmartOptimizeTimer: 180
    Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 4)
 172.22.210.2 S 172.22.201.2 S 172.22.206.2 S 172.22.212.1 S 
    Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
          172.22.210.2 172.22.201.2 172.22.206.2 172.22.212.1
   19 Aug  8 00:52:05.153 Selected as active path
   18 Aug  8 00:52:05.151 Record Route:  172.22.210.2 172.22.201.2 172.22.206.2 172.22.212.1
   17 Aug  8 00:52:05.151 Up
   16 Aug  8 00:52:05.136 Originate Call
   15 Aug  8 00:52:05.136 CSPF: computation result accepted  172.22.210.2 172.22.201.2 172.22.206.2 172.22.212.1
   14 Aug  8 00:52:05.134 Clear Call
---(more)---

Verify that the static routes are learnt via BGP

lab@PE1> show route advertising-protocol bgp 192.168.1.2 

inet.0: 30 destinations, 30 routes (30 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 10.1.1.0/24             Self                         100        I
* 10.1.2.0/24             Self                         100        I

lab@PE1> show route receive-protocol bgp 192.168.1.2        

inet.0: 30 destinations, 30 routes (30 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 10.1.3.0/24             192.168.1.2                  100        I
* 10.1.4.0/24             192.168.1.2                  100        I

Verify the next hops are via different LSPs

lab@PE1> show route protocol bgp       

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

10.1.3.0/24        *[BGP/170] 00:39:09, localpref 100, from 192.168.1.2
                      AS path: I
                    > to 172.22.210.2 via em1.210, label-switched-path lsp-1
10.1.4.0/24        *[BGP/170] 00:39:09, localpref 100, from 192.168.1.2
                      AS path: I
                      to 172.22.211.2 via em2.211, label-switched-path lsp-2

lab@PE1> traceroute 10.1.3.1 
traceroute to 10.1.3.1 (10.1.3.1), 30 hops max, 40 byte packets
 1  172.22.210.2 (172.22.210.2)  0.492 ms  0.323 ms  0.272 ms
     MPLS Label=301488 CoS=0 TTL=1 S=1
 2  172.22.201.2 (172.22.201.2)  0.434 ms  0.435 ms  0.421 ms
     MPLS Label=301344 CoS=0 TTL=1 S=1
 3  172.22.206.2 (172.22.206.2)  0.634 ms  0.546 ms  0.613 ms
     MPLS Label=301312 CoS=0 TTL=1 S=1
 4  * * *
^C
lab@PE1> traceroute 10.1.4.1    
traceroute to 10.1.4.1 (10.1.4.1), 30 hops max, 40 byte packets
 1  172.22.211.2 (172.22.211.2)  1.015 ms  0.663 ms  0.264 ms
     MPLS Label=301248 CoS=0 TTL=1 S=1
 2  172.22.203.2 (172.22.203.2)  0.444 ms  0.409 ms  0.435 ms
     MPLS Label=301216 CoS=0 TTL=1 S=1
 3  172.22.204.2 (172.22.204.2)  0.632 ms  0.591 ms  1.039 ms
     MPLS Label=301104 CoS=0 TTL=1 S=1
 4  * * *

BGP Route Reflection

Posted on by
Reply

Task

Refer to the diagram, we need to design iBGP to meet the following requirements:

  • P2 and P5 routers work as Route-Reflectors, with different cluster ID of 2.2.2.2 and 5.5.5.5
  • Each RR will have all other routers, except the other RR, as its clients.
  • The two RR peer with each other via a normal iBGP session.

Configuration

Route Reflectors:

p2@vr-device:p2> show configuration protocols bgp 
group Cluster-2222 {
    type internal;
    local-address 192.168.5.2;
    export static-to-bgp;
    cluster 2.2.2.2;
    neighbor 192.168.5.1;
    neighbor 192.168.5.3;
    neighbor 192.168.5.4;
    neighbor 192.168.5.6;
}
group Core {
    type internal;
    local-address 192.168.5.2;
    export static-to-bgp;
    neighbor 192.168.5.5;
}

p5@vr-device:p5> show configuration protocols bgp 
group Cluster-5555 {
    type internal;
    local-address 192.168.5.5;
    export static-to-bgp;
    cluster 5.5.5.5;
    neighbor 192.168.5.1;
    neighbor 192.168.5.3;
    neighbor 192.168.5.4;
    neighbor 192.168.5.6;
}
group Core {
    type internal;
    local-address 192.168.5.5;
    export static-to-bgp;
    neighbor 192.168.5.2;
}

RR clients, with p1 router config as an example:

p1@vr-device:p1> show configuration protocols bgp 
group IBGP {
    type internal;
    local-address 192.168.5.1;
    export static-to-bgp;
    neighbor 192.168.5.2;
    neighbor 192.168.5.5;
}

Note that each RR client needs only to peer with the two RR. This solves the n^2 scalability problem associated with the total number of ibgp peers required (n x (n-1)/2 to be exact). In fact, for BGP to function, a client only need to peer with one RR, but two are recommended for redundancy. With redundant RR design, in case one RR fails, all clients can still maintain route exchange via the other RR.

Verification

Check BGP status summary

p1@vr-device:p1> show bgp summary    
Groups: 1 Peers: 2 Down peers: 0
Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
inet.0                10          5          0          0          0          0
Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
192.168.5.2           65000         70         61       0       3       25:55 4/5/5/0              0/0/0/0
192.168.5.5           65000         72         67       0       3       25:48 1/5/5/0              0/0/0/0

p2@vr-device:p2> show bgp summary 
Groups: 2 Peers: 5 Down peers: 0
Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
inet.0                 9          5          0          0          0          0
Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
192.168.5.1           65000         69         97       0       1       26:11 1/1/1/0              0/0/0/0
192.168.5.3           65000         69         96       0       1       26:09 1/1/1/0              0/0/0/0
192.168.5.4           65000         60         68       0       1       25:56 1/1/1/0              0/0/0/0
192.168.5.5           65000         61         61       0       1       24:18 1/5/5/0              0/0/0/0
192.168.5.6           65000         63         88       0       1       24:07 1/1/1/0              0/0/0/0

Check routing table

p1@vr-device:p1> show route protocol bgp 

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

10.123.2.0/24      *[BGP/170] 00:23:37, localpref 100, from 192.168.5.2
                      AS path: I
                    > to 172.22.201.2 via em3.12
                    [BGP/170] 00:21:44, localpref 100, from 192.168.5.5
                      AS path: I
                    > to 172.22.201.2 via em3.12
10.123.3.0/24      *[BGP/170] 00:22:33, localpref 100, from 192.168.5.2
                      AS path: I
                    > to 172.22.201.2 via em3.12
                    [BGP/170] 00:22:33, localpref 100, from 192.168.5.5
                      AS path: I
                    > to 172.22.201.2 via em3.12
10.123.4.0/24      *[BGP/170] 00:22:38, localpref 100, from 192.168.5.2
                      AS path: I
                    > to 172.22.202.2 via em3.14
                    [BGP/170] 00:22:38, localpref 100, from 192.168.5.5
                      AS path: I
                    > to 172.22.202.2 via em3.14
10.123.5.0/24      *[BGP/170] 00:23:30, localpref 100, from 192.168.5.5
                      AS path: I
                    > to 172.22.201.2 via em3.12
                      to 172.22.202.2 via em3.14
                    [BGP/170] 00:21:44, localpref 100, from 192.168.5.2
                      AS path: I
                    > to 172.22.201.2 via em3.12
                      to 172.22.202.2 via em3.14
10.123.6.0/24      *[BGP/170] 00:21:33, localpref 100, from 192.168.5.2
                      AS path: I
                    > to 172.22.201.2 via em3.12
                      to 172.22.202.2 via em3.14
                    [BGP/170] 00:21:48, localpref 100, from 192.168.5.5
                      AS path: I
                    > to 172.22.201.2 via em3.12
                      to 172.22.202.2 via em3.14

Tip: A quick way to check the number of routes using command pipe

p1@vr-device:p1> show route protocol bgp 10/8 | match 10.123 | count 
Count: 5 lines

Look closer to a specific route, we see that P1 router receives the prefix behind P6 router via the two cluster RRs (P2 and P5)

p1@vr-device:p1> show route protocol bgp 10.123.6.0 

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

10.123.6.0/24      *[BGP/170] 00:25:44, localpref 100, from 192.168.5.2
                      AS path: I
                    > to 172.22.201.2 via em3.12
                      to 172.22.202.2 via em3.14
                    [BGP/170] 00:25:59, localpref 100, from 192.168.5.5
                      AS path: I
                    > to 172.22.201.2 via em3.12
                      to 172.22.202.2 via em3.14

p1@vr-device:p1> show route protocol bgp 10.123.6.0 detail 

inet.0: 27 destinations, 32 routes (27 active, 0 holddown, 0 hidden)
10.123.6.0/24 (2 entries, 1 announced)
        *BGP    Preference: 170/-101
                Next hop type: Indirect
                Address: 0x8f939a0
                Next-hop reference count: 4
                Source: 192.168.5.2
                Next hop type: Router, Next hop index: 131092
                Next hop: 172.22.201.2 via em3.12, selected
                Next hop: 172.22.202.2 via em3.14
                Protocol next hop: 192.168.5.6
                Indirect next hop: 8fae000 131099
                State: 
                Local AS: 65000 Peer AS: 65000
                Age: 26:06      Metric2: 3 
                Task: BGP_65000.192.168.5.2+62938
                Announcement bits (2): 0-KRT 5-Resolve tree 1 
                AS path: I (Originator) Cluster list:  2.2.2.2
                AS path:  Originator ID: 192.168.5.6
                Accepted
                Localpref: 100
                Router ID: 192.168.5.2
         BGP    Preference: 170/-101
                Next hop type: Indirect
                Address: 0x8f939a0
                Next-hop reference count: 4
                Source: 192.168.5.5
                Next hop type: Router, Next hop index: 131092
                Next hop: 172.22.201.2 via em3.12, selected
                Next hop: 172.22.202.2 via em3.14
                Protocol next hop: 192.168.5.6
                Indirect next hop: 8fae000 131099
                State: 
                Inactive reason: Not Best in its group - Update source
                Local AS: 65000 Peer AS: 65000
                Age: 26:21      Metric2: 3 
                Task: BGP_65000.192.168.5.5+179
                AS path: I (Originator) Cluster list:  5.5.5.5
                AS path:  Originator ID: 192.168.5.6
                Accepted
                Localpref: 100
                Router ID: 192.168.5.5

Verify with tracing

p1@vr-device:p1> traceroute 10.123.6.1 
traceroute to 10.123.6.1 (10.123.6.1), 30 hops max, 40 byte packets
 1  172.22.201.2 (172.22.201.2)  0.281 ms  0.323 ms  0.292 ms
 2  172.22.206.2 (172.22.206.2)  0.455 ms  0.448 ms  0.424 ms
 3  172.22.207.2 (172.22.207.2)  0.535 ms  0.611 ms  0.599 ms
 4  172.22.207.2 (172.22.207.2)  0.561 ms !H  0.937 ms !H  0.567 ms !H

Cluster ID

What happen if P2 and P5 share the same Cluster ID?

Cluster ID is originally defined to identify and stop routing loops. A RR does not accept route tagged with its own cluster ID. In case that P5 also use a cluster ID of 2.2.2.2 for its own cluster, then routes learnt by P5 from its clients and advertised to P2 will not be accepted by P2. P2 think that there’s a loop and just simply ignore the route updates. On the other hand, those routes originated by P5 not tagged with a cluster ID of 2.2.2.2, such as 10.123.5.0/24, is accepted by P2.

See the log below when P2 and P5 shares Cluster ID of 2.2.2.2

p2@vr-device:p2> show configuration protocols bgp 
traceoptions {
    file trace-bgp-p2;
    flag route receive;
    flag update receive;
}

Aug  8 22:38:44.874564 
Aug  8 22:38:44.874564 BGP RECV 192.168.5.5+57694 -> 192.168.5.2+179
Aug  8 22:38:44.874599 BGP RECV message type 2 (Update) length 62
Aug  8 22:38:44.874618 bgp_read_v4_update: peer 192.168.5.5 (Internal AS 65000) UPDATE with local cluster-id (0.0.2.2) in clusterlist
Aug  8 22:38:44.874636 bgp_rcv_nlri: 10.123.3.0/24
Aug  8 22:38:44.874645 bgp_read_v4_message: done with 192.168.5.5 (Internal AS 65000) received 62 octets 1 update 1 route
Aug  8 22:38:48.876036 
Aug  8 22:38:48.876036 BGP RECV 192.168.5.5+57694 -> 192.168.5.2+179
Aug  8 22:38:48.876067 BGP RECV message type 2 (Update) length 62
Aug  8 22:38:48.876080 bgp_read_v4_update: peer 192.168.5.5 (Internal AS 65000) UPDATE with local cluster-id (0.0.2.2) in clusterlist
Aug  8 22:38:48.876104 bgp_rcv_nlri: 10.123.4.0/24
Aug  8 22:38:48.876113 bgp_read_v4_message: done with 192.168.5.5 (Internal AS 65000) received 62 octets 1 update 1 route
Aug  8 22:38:52.877937 
Aug  8 22:38:52.877937 BGP RECV 192.168.5.5+57694 -> 192.168.5.2+179
Aug  8 22:38:52.877961 BGP RECV message type 2 (Update) length 62
Aug  8 22:38:52.877976 bgp_read_v4_update: peer 192.168.5.5 (Internal AS 65000) UPDATE with local cluster-id (0.0.2.2) in clusterlist
Aug  8 22:38:52.877988 bgp_rcv_nlri: 10.123.6.0/24
Aug  8 22:38:52.877996 bgp_read_v4_message: done with 192.168.5.5 (Internal AS 65000) received 62 octets 1 update 1 route

p2@vr-device:p2> show route receive-protocol bgp 192.168.5.5    

inet.0: 26 destinations, 26 routes (26 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 10.123.5.0/24           192.168.5.5                  100        I

In this design, clients will maintain connectivity between them if either P2 or P5 failure, as well as one single link between a client and one of its RR. However, client will lose connectivity to the RR if the link between the two fails. Similarly, if P1 loses the link to P5 AND P6 loses the link to P2, then P1 will not have reachablity to P6 !

As a best practice, keep the Cluster ID unique to maximise the redundancy (although there may be redundant routing updates). The routing update loops does not exist, even if there is a group of RRs that form a fully or partly meshed peering.

Consider the following topologies:

In this topology, P1, P2, P5 form a RR fully meshed group. Each one is clients of other one. P4 form iBGP with P1 to inject a route (10.123.4.0/24) for demonstration purpose.

In the second topology, P2 and P5 are client of P1 (Cluster ID 1.1.1.1).
P1 is client of P2 (Cluster ID 2.2.2.2). P1 is client of P5 (Cluster ID 5.5.5.5). P2 and P5 peer via a normal iBGP, to form a mesh of mix RR and iBGP between P1, P2, P5. Finally P4 form a normal iBGP peering with P1 to inject 10.123.4.0/24 for the demonstration purpose.

In both cases, there is no loop, as both Originator ID, and Cluster List (of all Cluster ID) are included in ALL iBGP updates between RRs and RR clients, as well as between normal iBGP peers. They are used for routing (and routing updates) loop prevention. Cluster ID list is also used for path selection (similar to AS-path), where a shorter cluster list length is preferred.

Below is the debug messages on P1 for both cases. It receives updates for 10.123.4.0/24 from both P2 and P5, but reject the route, because it see its own Cluster ID in the updates.

Aug 11 13:36:13.865086 BGP RECV 192.168.5.2+179 -> 192.168.5.1+49556
Aug 11 13:36:13.865102 BGP RECV message type 2 (Update) length 70
Aug 11 13:36:13.865107 BGP RECV Update PDU length 70
Aug 11 13:36:13.865110 BGP RECV flags 0x40 code Origin(1): IGP
Aug 11 13:36:13.865113 BGP RECV flags 0x40 code ASPath(2) length 0: 
Aug 11 13:36:13.865116 BGP RECV flags 0x40 code NextHop(3): 192.168.5.4
Aug 11 13:36:13.865119 BGP RECV flags 0x40 code LocalPref(5): 100
Aug 11 13:36:13.865122 BGP RECV flags 0x80 code Originator_Id(9) 192.168.5.4
Aug 11 13:36:13.865125 BGP RECV flags 0x80 code Cluster_List(10): 2.2.2.2 5.5.5.5 1.1.1.1
Aug 11 13:36:13.865130 BGP RECV         10.123.4.0/24
Aug 11 13:36:13.865142 bgp_read_v4_update: peer 192.168.5.2 (Internal AS 65000) UPDATE with local cluster-id (0.0.1.1) in clusterlist
Aug 11 13:36:13.865151 bgp_rcv_nlri: 10.123.4.0/24

Aug 11 13:36:13.867383 BGP RECV 192.168.5.5+179 -> 192.168.5.1+62193
Aug 11 13:36:13.867392 BGP RECV message type 2 (Update) length 27
Aug 11 13:36:13.866815 BGP RECV Update PDU length 70
Aug 11 13:36:13.866818 BGP RECV flags 0x40 code Origin(1): IGP
Aug 11 13:36:13.866820 BGP RECV flags 0x40 code ASPath(2) length 0: 
Aug 11 13:36:13.866823 BGP RECV flags 0x40 code NextHop(3): 192.168.5.4
Aug 11 13:36:13.866826 BGP RECV flags 0x40 code LocalPref(5): 100
Aug 11 13:36:13.866829 BGP RECV flags 0x80 code Originator_Id(9) 192.168.5.4
Aug 11 13:36:13.866832 BGP RECV flags 0x80 code Cluster_List(10): 5.5.5.5 2.2.2.2 1.1.1.1
Aug 11 13:36:13.866836 BGP RECV         10.123.4.0/24
Aug 11 13:36:13.866843 bgp_read_v4_update: peer 192.168.5.5 (Internal AS 65000) UPDATE with local cluster-id (0.0.1.1) in clusterlist
Aug 11 13:36:13.866850 bgp_rcv_nlri: 10.123.4.0/24
Aug 11 13:36:13.866856 bgp_read_v4_message: done with 192.168.5.5 (Internal AS 65000) received 70 octets 1 update 1 route
Aug 11 13:36:13.867383

Below are the best BGP routes seen on P1, P2, P5 for 10.123.4/24

p1@vr-device:p1> show route protocol bgp 10.123.4.0/24 detail    

inet.0: 25 destinations, 27 routes (25 active, 0 holddown, 0 hidden)
10.123.4.0/24 (1 entry, 1 announced)
        *BGP    Preference: 170/-101
                Next hop type: Indirect
                Address: 0x8f93b98
                Next-hop reference count: 3
                Source: 192.168.5.4
                Next hop type: Router, Next hop index: 878
                Next hop: 172.22.202.2 via em3.14, selected
                Protocol next hop: 192.168.5.4
                Indirect next hop: 900b000 131079
                State: 
                Local AS: 65000 Peer AS: 65000
                Age: 5:54       Metric2: 1 
                Task: BGP_65000.192.168.5.4+179
                Announcement bits (3): 0-KRT 4-BGP RT Background 5-Resolve tree 1 
                AS path: I
                Accepted
                Localpref: 100
                Router ID: 192.168.5.4

p2@vr-device:p2> show route protocol bgp 10.123.4.0/24 detail    

inet.0: 25 destinations, 28 routes (25 active, 0 holddown, 0 hidden)
10.123.4.0/24 (2 entries, 1 announced)
        *BGP    Preference: 170/-101
                Next hop type: Indirect
                Address: 0x8f93838
                Next-hop reference count: 4
                Source: 192.168.5.1
                Next hop type: Router, Next hop index: 131084
                Next hop: 172.22.205.2 via em3.25, selected
                Next hop: 172.22.201.1 via em4.12
                Protocol next hop: 192.168.5.4
                Indirect next hop: 8faea50 131080
                State: 
                Local AS: 65000 Peer AS: 65000
                Age: 6:50       Metric2: 2 
                Task: BGP_65000.192.168.5.1+49556
                Announcement bits (3): 0-KRT 4-BGP RT Background 5-Resolve tree 1 
                AS path: I (Originator) Cluster list:  1.1.1.1
                AS path:  Originator ID: 192.168.5.4
                Accepted
                Localpref: 100
                Router ID: 192.168.5.1
         BGP    Preference: 170/-101
                Next hop type: Indirect
                Address: 0x8f93838
                Next-hop reference count: 4
                Source: 192.168.5.5
                Next hop type: Router, Next hop index: 131084
                Next hop: 172.22.205.2 via em3.25, selected
                Next hop: 172.22.201.1 via em4.12
                Protocol next hop: 192.168.5.4
                Indirect next hop: 8faea50 131080
                State: 
                Inactive reason: Not Best in its group - Cluster list length
                Local AS: 65000 Peer AS: 65000
                Age: 6:50       Metric2: 2 
                Task: BGP_65000.192.168.5.5+179
                AS path: I (Originator) Cluster list:  5.5.5.5 1.1.1.1
                AS path:  Originator ID: 192.168.5.4
                Accepted
                Localpref: 100
                Router ID: 192.168.5.5

p5@vr-device:p5> show route protocol bgp 10.123.4.0/24 detail    

inet.0: 25 destinations, 28 routes (25 active, 0 holddown, 0 hidden)
10.123.4.0/24 (2 entries, 1 announced)
        *BGP    Preference: 170/-101
                Next hop type: Indirect
                Address: 0x8f937a8
                Next-hop reference count: 4
                Source: 192.168.5.1
                Next hop type: Router, Next hop index: 875
                Next hop: 172.22.203.1 via em4.45, selected
                Protocol next hop: 192.168.5.4
                Indirect next hop: 8fafc30 131081
                State: 
                Local AS: 65000 Peer AS: 65000
                Age: 7:07       Metric2: 1 
                Task: BGP_65000.192.168.5.1+62193
                Announcement bits (3): 0-KRT 4-BGP RT Background 5-Resolve tree 1 
                AS path: I (Originator) Cluster list:  1.1.1.1
                AS path:  Originator ID: 192.168.5.4
                Accepted
                Localpref: 100
                Router ID: 192.168.5.1
         BGP    Preference: 170/-101
                Next hop type: Indirect
                Address: 0x8f937a8
                Next-hop reference count: 4
                Source: 192.168.5.2
                Next hop type: Router, Next hop index: 875
                Next hop: 172.22.203.1 via em4.45, selected
                Protocol next hop: 192.168.5.4
                Indirect next hop: 8fafc30 131081
                State: 
                Inactive reason: Not Best in its group - Cluster list length
                Local AS: 65000 Peer AS: 65000
                Age: 7:07       Metric2: 1 
                Task: BGP_65000.192.168.5.2+64180
                AS path: I (Originator) Cluster list:  2.2.2.2 1.1.1.1
                AS path:  Originator ID: 192.168.5.4
                Accepted
                Localpref: 100
                Router ID: 192.168.5.2

no-client-reflect

How we can stop routes learnt from a cluster client reflected to RR clients?

This unlikely scenario can be achieved with “no-client-reflect” command. Please note, however, that routes learnt from clients continue to be reflected to other normal iBGP peers and vice versa.

group Cluster-2222 {
    type internal;
    local-address 192.168.5.2;
    export static-to-bgp;
    cluster 2.2.2.2;
    no-client-reflect;
    neighbor 192.168.5.1;
    neighbor 192.168.5.3;
    neighbor 192.168.5.4;
    neighbor 192.168.5.6;
}

The result is that P1 no longer receives route update for 10.123.3, 4, 5 behind other clients, as they are no longer reflected by P2, nor P5. However RRs continue to reflect routes between their clients and their non-client iBGP peers, shown in the output below.

p1@vr-device:p1> show route protocol bgp    

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

10.123.2.0/24      *[BGP/170] 01:21:48, localpref 100, from 192.168.5.2
                      AS path: I
                    > to 172.22.201.2 via em3.12
                    [BGP/170] 00:00:10, localpref 100, from 192.168.5.5
                      AS path: I
                    > to 172.22.201.2 via em3.12
10.123.5.0/24      *[BGP/170] 00:30:54, localpref 100, from 192.168.5.5
                      AS path: I
                    > to 172.22.201.2 via em3.12
                      to 172.22.202.2 via em3.14
                    [BGP/170] 00:00:10, localpref 100, from 192.168.5.2
                      AS path: I
                    > to 172.22.201.2 via em3.12
                      to 172.22.202.2 via em3.14

p2@vr-device:p2> show route protocol bgp 10.123.1.0    

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

10.123.1.0/24      *[BGP/170] 01:27:06, localpref 100, from 192.168.5.1
                      AS path: I
                    > to 172.22.201.1 via em4.12
                    [BGP/170] 00:05:28, localpref 100, from 192.168.5.5
                      AS path: I
                    > to 172.22.201.1 via em4.12

iBGP peering and route injection

Posted on by
Reply

Task

  • Set up fully meshed iBGP peering between the 6 routers as shown in the diagram, using AS 65000
  • All routers must log IBGP session establishment and tear down actions to a file called pi-bgp-log where i equals the router number.
  • Configure a static route 10.123.i.0/24 next-hop reject on each router.
  • Advertise the 10.123.i/24 static route into iBGP.

Configuration

# BGP AS is defined under routing-options
routing-options {
    autonomous-system 65000;            
}

# Basic BGP config (iBGP full mesh)
protocols {
    bgp {
        group IBGP {
            type internal;
            local-address 192.168.5.1;
            neighbor 192.168.5.2;
            neighbor 192.168.5.3;
            neighbor 192.168.5.4;
            neighbor 192.168.5.5;
            neighbor 192.168.5.6;
        }
    }
}

# Static route to be advertised into BGP
routing-options {
    static {
        route 10.123.1.0/24 reject;
    }
    autonomous-system 65000;            
}
# Policy to inject static routes into BGP
policy-options {
    policy-statement static-to-bgp {
        from protocol static;
        then accept;
    }
}

# Apply the export policy to inject static route into BGP
protocols {
    bgp {
        group IBGP {
            export static-to-bgp;
        }
    }
}

# Set logging (in this case, it is a kind of turning on debugging) 
protocols {                             
    bgp {
        traceoptions {
            file p1-bgp-log;
            flag state detail;
        }

Verification

Quick summary of BGP neighbor status:

p1@vr-device:p1> show bgp summary    
Groups: 1 Peers: 5 Down peers: 0
Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
inet.0                 5          5          0          0          0          0
Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
192.168.5.2           65000        212        215       0       1        4:10 1/1/1/0              0/0/0/0
192.168.5.3           65000        117        127       0       2        4:26 1/1/1/0              0/0/0/0
192.168.5.4           65000        103        104       0       1        4:22 1/1/1/0              0/0/0/0
192.168.5.5           65000        100        102       0       1        4:18 1/1/1/0              0/0/0/0
192.168.5.6           65000        192        199       0       2        4:14 1/1/1/0              0/0/0/0

Check the BGP routes

p1@vr-device:p1> show route protocol bgp 

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

10.123.2.0/24      *[BGP/170] 00:05:16, localpref 100, from 192.168.5.2
                      AS path: I
                    > to 172.22.201.2 via em3.12
10.123.3.0/24      *[BGP/170] 00:05:32, localpref 100, from 192.168.5.3
                      AS path: I
                    > to 172.22.201.2 via em3.12
10.123.4.0/24      *[BGP/170] 00:05:28, localpref 100, from 192.168.5.4
                      AS path: I
                    > to 172.22.202.2 via em3.14
10.123.5.0/24      *[BGP/170] 00:05:24, localpref 100, from 192.168.5.5
                      AS path: I
                    > to 172.22.201.2 via em3.12
                      to 172.22.202.2 via em3.14
10.123.6.0/24      *[BGP/170] 00:05:20, localpref 100, from 192.168.5.6
                      AS path: I
                    > to 172.22.201.2 via em3.12
                      to 172.22.202.2 via em3.14

Check routes received or sent to a particular neighbor

p1@vr-device:p1> show route receive-protocol bgp 192.168.5.6    

inet.0: 27 destinations, 27 routes (27 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 10.123.6.0/24           192.168.5.6                  100        I

p1@vr-device:p1> show route advertising-protocol bgp 192.168.5.6 

inet.0: 27 destinations, 27 routes (27 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 10.123.1.0/24           Self                         100        I

p1@vr-device:p1> traceroute 10.123.6.1                              
traceroute to 10.123.6.1 (10.123.6.1), 30 hops max, 40 byte packets
 1  172.22.201.2 (172.22.201.2)  0.836 ms  0.462 ms  0.489 ms
 2  172.22.206.2 (172.22.206.2)  0.653 ms  0.675 ms  0.615 ms
 3  172.22.207.2 (172.22.207.2)  0.871 ms  0.851 ms  0.861 ms
 4  172.22.207.2 (172.22.207.2)  0.787 ms !H  0.676 ms !H  0.656 ms !H

Verify that BGP status change is logged:

p1@vr-device:p1> clear bgp neighbor 

p1@vr-device:p1> show log p1-bgp-log    
Aug  8 18:57:01 trace_on: Tracing to "/var/log/p1/p1-bgp-log" started
Aug  8 18:57:01.162296 bgp_handle_ifachange: interface 172.22.201.1(em3.12) went down, state , chng , instance master, checking who this bothers
Aug  8 18:57:01.170511 bgp_handle_ifachange: interface 172.22.202.1(em3.14) went down, state , chng , instance master, checking who this bothers
Aug  8 18:57:01.232736 bgp_handle_ifachange: interface 172.22.210.2(em1.210) came up, state , chng , instance master, checking who this bothers
Aug  8 18:57:01.251577 bgp_handle_ifachange: interface 172.22.201.1(em3.12) came up, state , chng , instance master, checking who this bothers
Aug  8 18:57:01.255825 bgp_handle_ifachange: interface 172.22.202.1(em3.14) came up, state , chng , instance master, checking who this bothers
Aug  8 18:57:18.898983 bgp_peer_mgmt_clear:6026: NOTIFICATION sent to 192.168.5.2 (Internal AS 65000): code 6 (Cease) subcode 4 (Administratively Reset), Reason: Management session cleared BGP neighbor
Aug  8 18:57:18.899987 bgp_peer_close: closing peer 192.168.5.2 (Internal AS 65000), state is 7 (Established)
---(more)---

Which BGP peer did initiate the TCP connection?

Posted on by
Reply

A quick BGP question: How to check which BGP peer did initiate the connection?

The answer is very simple! It is in the output of the command show bgp neighbor . We sometime overlook the info in the output of this command, because it contains so much information.

Here you go, lets have a close look at that output again. In Junos, this info shows up in the very first line!

Junos 

lab@PE1> show bgp neighbor 192.168.1.2 
Peer: 192.168.1.2+62512 AS 65512 Local: 192.168.1.1+179 AS 65512
  Type: Internal    State: Established    Flags: 
  Last State: OpenConfirm   Last Event: RecvKeepAlive
  Last Error: None
  Options: 
  Local Address: 192.168.1.1 Holdtime: 90 Preference: 170
  Number of flaps: 0
  Peer ID: 192.168.1.2     Local ID: 192.168.1.1       Active Holdtime: 90
  Keepalive Interval: 30         Peer index: 0   
  BFD: disabled, down
  NLRI for restart configured on peer: inet-unicast
  NLRI advertised by peer: inet-unicast
  NLRI for this session: inet-unicast
  Peer supports Refresh capability (2)
  Restart time configured on the peer: 120
  Stale routes from peer are kept for: 300
  Restart time requested by this peer: 120
  NLRI that peer supports restart for: inet-unicast
  NLRI that restart is negotiated for: inet-unicast
  NLRI of received end-of-rib markers: inet-unicast
  NLRI of all end-of-rib markers sent: inet-unicast
  Peer supports 4 byte AS extension (peer-as 65512)
  Peer does not support Addpath
  Table inet.0 Bit: 10001
    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
  Last traffic (seconds): Received 19   Sent 16   Checked 57  
  Input messages:  Total 11     Updates 1       Refreshes 0     Octets 253
  Output messages: Total 11     Updates 0       Refreshes 0     Octets 272
  Output Queue[0]: 0

The output shows that this router is a server (with the TCP port 179), and the other end is the one that initiated the TCP connection (source port 62512, which happens to be its AS number).

In Cisco IOS, this info shows in the middle:

Cisco IOS

R1#sh ip bgp neighbors 12.0.0.2
BGP neighbor is 12.0.0.2,  remote AS 200, external link
  BGP version 4, remote router ID 12.0.0.2
  BGP state = Established, up for 00:00:11
  Last read 00:00:11, last write 00:00:11, hold time is 180, keepalive interval is 60 seconds
  Neighbor sessions:
    1 active, is multisession capable
  Neighbor capabilities:
    Route refresh: advertised and received(new)
    Address family IPv4 Unicast: advertised and received
    Multisession Capability: advertised and received
  Message statistics, state Established:
    InQ depth is 0
    OutQ depth is 0
    
                         Sent       Rcvd
    Opens:                  1          1
    Notifications:          0          0
    Updates:                0          0
    Keepalives:             1          1
    Route Refresh:          0          0
    Total:                  2          2
  Default minimum time between advertisement runs is 30 seconds
          
 For address family: IPv4 Unicast
  Session: 12.0.0.2 session 1
  BGP table version 1, neighbor version 0/0
  Output queue size : 0
  Index 1, Offset 0, Mask 0x2
  1 update-group member
                                 Sent       Rcvd
  Prefix activity:               ----       ----
    Prefixes Current:               0          0
    Prefixes Total:                 0          0
    Implicit Withdraw:              0          0
    Explicit Withdraw:              0          0
    Used as bestpath:             n/a          0
    Used as multipath:            n/a          0

                                   Outbound    Inbound
  Local Policy Denied Prefixes:    --------    -------
    Total:                                0          0
  Number of NLRIs in the update sent: max 0, min 0

  Address tracking is enabled, the RIB does have a route to 12.0.0.2
  Connections established 1; dropped 0
  Last reset never
  Transport(tcp) path-mtu-discovery is enabled
  Graceful-Restart is disabled
Connection state is ESTAB, I/O status: 1, unread input bytes: 0        
Connection is ECN Disabled
Mininum incoming TTL 0, Outgoing TTL 1
Local host: 12.0.0.1, Local port: 179
Foreign host: 12.0.0.2, Foreign port: 54889
Connection tableid (VRF): 0

Enqueued packets for retransmit: 0, input: 0  mis-ordered: 0 (0 bytes)

Event Timers (current time is 0x63FB4):
Timer          Starts    Wakeups            Next
Retrans             2          0             0x0
TimeWait            0          0             0x0
AckHold             2          1             0x0
SendWnd             0          0             0x0
KeepAlive           0          0             0x0
GiveUp              0          0             0x0
PmtuAger            0          0             0x0
DeadWait            0          0             0x0
Linger              0          0             0x0

iss: 1400246787  snduna: 1400246857  sndnxt: 1400246857     sndwnd:  16315
irs: 2844375924  rcvnxt: 2844375994  rcvwnd:      16315  delrcvwnd:     69
          
SRTT: 70 ms, RTTO: 1683 ms, RTV: 1613 ms, KRTT: 0 ms
minRTT: 24 ms, maxRTT: 300 ms, ACK hold: 200 ms
Status Flags: passive open, gen tcbs
Option Flags: nagle, path mtu capable

Datagrams (max data segment is 1460 bytes):
Rcvd: 4 (out of order: 0), with data: 2, total data bytes: 69
Sent: 4 (retransmit: 0 fastretransmit: 0),with data: 2, total data bytes: 69

We can filter irrelevant info with the following “pipe” option:

R1#sh ip bgp neighbors 12.0.0.2 | in port:
Local host: 12.0.0.1, Local port: 179
Foreign host: 12.0.0.2, Foreign port: 54889

In this example, the Cisco router works as the server, listening to TCP port 179, while its peer initiated the connection from the source port 54889.