what is the meaning of this command

hi,expert

here is the question:

1:I know reslove-vpn is copy prefix from nei in inet.0  to inet.3 ,but why we need to set traffic-engineering bgp-igp at the ned to move inet.3 to inet.0,they are confilct

2:why we need to configure traffic-engineering bgp-igp; 

I red some articles it says by default bgp will use inet.0 and inet.3,in this case,4.4.4.4 is in inet.0 ,why still need to move inet.3 to inet.0

I think I am also confused by this

Using RSVP and LDP Routes for Traffic Forwarding

Configure the bgp-igp option of the traffic-engineering statement to cause BGP and the interior gateway protocols (IGPs) to use LSPs for forwarding traffic destined for egress routers. The bgp-igp option causes all inet.3 routes to be moved to the inet.0 routing table.

On the ingress router, include the traffic-engineering bgp-igp statement:

You can include this statement at the following hierarchy levels:

• [edit protocols mpls]
• [edit logical-systems logical-system-name protocols mpls]

   

  Note: The bgp-igp option of the traffic-engineering statement cannot be configured for VPNs. VPN routing instances require that routes be in the inet.3 routing table.

Using RSVP and LDP Routes for Forwarding in VPNs

VPNs rely on the routes in the inet.3 routing table to function properly. For VPNs, configure the bgp-igp-both-ribs option of the traffic-engineering statement to cause BGP and the IGPs to use LSPs for forwarding traffic destined for egress routers. The bgp-igp-both-ribs option installs the ingress routes in both the inet.0 routing table (for IPv4 unicast routes) and the inet.3 routing table (for MPLS path information).

On the ingress router, include the traffic-engineering bgp-igp-both-ribs statement:

You can include this statement at the following hierarchy levels:

• [edit protocols mpls]

MPLS and Routing Tables

The IGPs and BGP store their routing information in the inet.0 routing table, the main IP routing table. If traffic-engineering bgp is configured, thereby allowing only BGP to use MPLS paths for forwarding traffic, MPLS path information is stored in a separate routing table, inet.3. Only BGP accesses the inet.3 routing table. BGP uses both inet.0 and inet.3 to resolve next-hop addresses. If traffic-engineering bgp-igp is configured, thereby allowing the IGPs to use MPLS paths for forwarding traffic, MPLS path information is stored in the inet.0 routing table. (Figure 13 and Figure 14 illustrate the routing tables in the two traffic engineering configurations.)

1:what is the difference between these BGP and vpn

2:if I doesn't configure any te,it is equals to traffic-engineering bgp,right?

3:it seems if there is no entry in inet.3,vpn traffic will fail ,but since bgp can use inet.0 to reslove its next hop,why it failed?

Hi Rob,
    Let me explain with an example as below:

PE is bgp neighbor with 1.1.1.1 for inet-vpn-unicast and inet-unicast.
PE is receiving bgp routes as well as vpn routes as seen below.
However inet.0 bgp routes are ACTIVE while bgp.l3vpn.0 routes are inactive/hidden.

suryak@PE# run show bgp summary                       
Groups: 1 Peers: 1 Down peers: 0
Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
inet.0               
                       1          1          0          0          0          0
bgp.l3vpn.0          
                       4          0          0          0          0          0
Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
1.1.1.1                 100         12          6       0       0        1:03 Establ
  inet.0: 1/1/1/0
  bgp.l3vpn.0: 0/4/4/0
  VPNA.inet.0: 0/4/4/0

suryak@PE# run show route receive-protocol bgp 1.1.1.1 table inet.0
inet.0: 52 destinations, 54 routes (51 active, 0 holddown, 1 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 66.1.0.0/24             1.1.1.1                      100        I

suryak@PE# run show route receive-protocol bgp 1.1.1.1 table bgp.l3vpn.0 hidden
bgp.l3vpn.0: 4 destinations, 4 routes (0 active, 0 holddown, 4 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
  100:1:0.0.0.0/0                     
                          1.1.1.1                      100        I
  100:1:90.0.0.0/24                    
                          1.1.1.1                      100        65111 I
  100:1:100.0.0.0/30                    
                          1.1.1.1                      100        I
  100:1:200.1.0.0/24                    
                          1.1.1.1                      100        65111 I


PE know how to reach 1.1.1.1 via inet.0 but doesn't have any path in inet.3 table.

suryak@PE# run show route 1.1.1.1
inet.0: 52 destinations, 54 routes (51 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both
1.1.1.1/32         *[OSPF/10] 10:20:13, metric 2
                    > to 20.0.2.1 via ge-3/1/2.0


By default, BGP routes are resolved for protocol nexthop (NH) using inet.3 routes first.
In case, protocol NH is not available in inet.3, then it is resolved using inet.0 table.
However for VPN routes, the protcol nexthop resolution is purely based on inet.3 routes.
If it is not available, then those are marked as hidden.

suryak@PE# run show route resolution table inet.0
Tree Index: 1, Nodes 51, Reference Count 1
Contributing routing tables: inet.0 inet.3

suryak@PE# run show route resolution table bgp.l3vpn.0
Tree Index: 2, Nodes 2, Reference Count 2
Contributing routing tables: inet.3


Having said that we see that bgp inet.0 route being resolved using route in inet.0 table.

suryak@PE# run show route 66.1/24 detail    

inet.0: 52 destinations, 54 routes (51 active, 0 holddown, 1 hidden)
66.1.0.0/24 (1 entry, 1 announced)
        *BGP    Preference: 170/-101
                Next hop type: Indirect
                Address: 0x944cac0
                Next-hop reference count: 3
                Source: 1.1.1.1
                Next hop type: Router, Next hop index: 571
                Next hop: 20.0.2.1 via ge-3/1/2.0, selected      <<<<< NOTE, THIS IS inet.0 PATH TO REACH 1.1.1.1
                Session Id: 0x1
                Protocol next hop: 1.1.1.1



Now if we check unreoslved routes, we indeed see VPN routes not be resolved as 1.1.1.1 is not available in inet.3 table

suryak@PE# run show route resolution unresolved
Tree Index 1
Tree Index 2
100:1:90.0.0.0/88
        Protocol Nexthop: 1.1.1.1 Push 16
        Indirect nexthop: 0 - INH Session ID: 0x0100:1:0.0.0.0/64
        Protocol Nexthop: 1.1.1.1 Push 16
        Indirect nexthop: 0 - INH Session ID: 0x0100:1:100.0.0.0/94
        Protocol Nexthop: 1.1.1.1 Push 16
        Indirect nexthop: 0 - INH Session ID: 0x0100:1:200.1.0.0/88
        Protocol Nexthop: 1.1.1.1 Push 16
        Indirect nexthop: 0 - INH Session ID: 0x0.


Once I enable LDP (RSVP can also be done), we see these routes being ACTIVE:

suryak@PE# run show route 1.1.1.1

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

1.1.1.1/32         *[OSPF/10] 10:21:29, metric 2
                    > to 20.0.2.1 via ge-3/1/2.0

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

1.1.1.1/32         *[LDP/9] 00:00:04, metric 1
                    > to 20.0.2.1 via ge-3/1/2.0, Push 299888


suryak@PE# run show route receive-protocol bgp 1.1.1.1 table bgp.l3vpn.0           

bgp.l3vpn.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
  100:1:0.0.0.0/0                     
*                         1.1.1.1                      100        I
  100:1:90.0.0.0/24                    
*                         1.1.1.1                      100        65111 I
  100:1:100.0.0.0/30                    
*                         1.1.1.1                      100        I
  100:1:200.1.0.0/24                    
*                         1.1.1.1                      100        65111 I



Now let's check back bgp inet.0 route.

suryak@PE# run show route 66.1/24 detail

inet.0: 52 destinations, 54 routes (51 active, 0 holddown, 1 hidden)
66.1.0.0/24 (1 entry, 1 announced)
        *BGP    Preference: 170/-101
                Next hop type: Indirect
                Address: 0x944cac0
                Next-hop reference count: 3
                Source: 1.1.1.1
                Next hop type: Router, Next hop index: 609
                Next hop: 20.0.2.1 via ge-3/1/2.0, selected    <<<<
                Label operation: Push 299888                   <<<< Now it takes inet.3 instead of inet.0 path as earlier.
                Label TTL action: prop-ttl
                Session Id: 0x1
                Protocol next hop: 1.1.1.1



As we see 1.1.1.1 is installed in inet.0 as well as in inet.3 table. But only BGP takes inet.3 path.
When you do traceroute to 1.1.1.1 from PE, you would see inet.0 path.

suryak@PE# run show route 1.1.1.1

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

1.1.1.1/32         *[OSPF/10] 10:25:33, metric 2
                    > to 20.0.2.1 via ge-3/1/2.0

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

1.1.1.1/32         *[LDP/9] 00:00:14, metric 1
                    > to 20.0.2.1 via ge-3/1/2.0, Push 299888


suryak@PE# run traceroute 1.1.1.1    
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 40 byte packets
 1  20.0.2.1 (20.0.2.1)  0.536 ms  0.445 ms  0.439 ms
 2  1.1.1.1 (1.1.1.1)  1.124 ms  0.743 ms  10.239 ms


Now, in case you want everything to take inet.3 labeled path instead of inet.0 IP path,
then you can enale bgp-igp (based on assumption is LDP is peferred over OSPF)

suryak@PE# show protocols mpls      
traffic-engineering bgp-igp;


suryak@PE# run show route 1.1.1.1                            

inet.0: 52 destinations, 56 routes (51 active, 2 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both

1.1.1.1/32         *[LDP/9] 00:00:03, metric 1
                    > to 20.0.2.1 via ge-3/1/2.0, Push 299888
                    [OSPF/10] 00:00:03, metric 2
                    > to 20.0.2.1 via ge-3/1/2.0



suryak@PE# run traceroute 1.1.1.1                            
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 40 byte packets
 1  20.0.2.1 (20.0.2.1)  0.762 ms  2.374 ms  0.575 ms
     MPLS Label=299888 CoS=0 TTL=1 S=1
 2  1.1.1.1 (1.1.1.1)  11.030 ms  22.403 ms  0.724 ms


However with this knob in place, we see l3vpn routes being hidden/inactive as you don't see 1.1.1.1 in inet.3 table.

suryak@PE# run show route receive-protocol bgp 1.1.1.1 table VPNA.inet.0

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


suryak@PE# run show route receive-protocol bgp 1.1.1.1 table VPNA.inet.0 hidden

VPNA.inet.0: 4 destinations, 4 routes (0 active, 0 holddown, 4 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
  0.0.0.0/0               1.1.1.1                      100        I
  90.0.0.0/24             1.1.1.1                      100        65111 I
  100.0.0.0/30            1.1.1.1                      100        I
  200.1.0.0/24            1.1.1.1                      100        65111 I



To overcome this, you make it bgp-igp-both-ribs.

suryak@PE# show protocols mpls                                         
traffic-engineering bgp-igp-both-ribs;


suryak@PE# run traceroute 1.1.1.1                                                  
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 40 byte packets
 1  20.0.2.1 (20.0.2.1)  0.718 ms  0.621 ms  0.574 ms
     MPLS Label=299888 CoS=0 TTL=1 S=1
 2  1.1.1.1 (1.1.1.1)  0.861 ms  0.642 ms  0.580 ms


suryak@PE# run show route receive-protocol bgp 1.1.1.1 table VPNA.inet.0           

VPNA.inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 0.0.0.0/0               1.1.1.1                      100        I
* 90.0.0.0/24             1.1.1.1                      100        65111 I
* 100.0.0.0/30            1.1.1.1                      100        I
* 200.1.0.0/24            1.1.1.1                      100        65111 I

Wasn't it a lengthy explanation. But I hope it answers your queries.

Regards
Surya

hi,Surya

so this "BGP"is the normal BGP,not MP-BGP,right?

since in my understanding ,vpn route is MP-BGP route

Hi Rob,

MP-BGP by definition is ability to advertise and negotiate the reachability capability between the peers.

In general if BGP session is able to advertise any routes other than IPv4 unicast, then these routes would be advertised using MP-reach NLRI.

VPN Route advertised by peer:

Oct 28 09:04:24.882495 BGP RECV 1.1.1.1+50677 -> 3.3.3.3+179
Oct 28 09:04:24.882502 BGP RECV message type 2 (Update) length 98
Oct 28 09:04:24.882508 BGP RECV Update PDU length 98
Oct 28 09:04:24.882514 BGP RECV flags 0x40 code Origin(1): IGP
Oct 28 09:04:24.882521 BGP RECV flags 0x40 code ASPath(2) length 6: 65111
Oct 28 09:04:24.882526 BGP RECV flags 0x40 code LocalPref(5): 100
Oct 28 09:04:24.882542 BGP RECV flags 0xc0 code Extended Communities(16): 2:100:50 2:100:100
Oct 28 09:04:24.882548 BGP RECV flags 0x90 code MP_reach(14): AFI/SAFI 1/128
Oct 28 09:04:24.882556 BGP RECV         nhop 1.1.1.1 len 12
Oct 28 09:04:24.882565 BGP RECV         100:1:90.0.0.0/24 (label 16)

Unicast route advertised by peer:

Oct 28 09:04:24.882825 BGP RECV 1.1.1.1+50677 -> 3.3.3.3+179
Oct 28 09:04:24.882833 BGP RECV message type 2 (Update) length 48
Oct 28 09:04:24.882837 BGP RECV Update PDU length 48
Oct 28 09:04:24.882846 BGP RECV flags 0x40 code Origin(1): IGP
Oct 28 09:04:24.882852 BGP RECV flags 0x40 code ASPath(2) length 0: <null>
Oct 28 09:04:24.882857 BGP RECV flags 0x40 code NextHop(3): 1.1.1.1
Oct 28 09:04:24.882862 BGP RECV flags 0x40 code LocalPref(5): 100
Oct 28 09:04:24.882868 BGP RECV         66.1.0.0/24


Regards

Surya

The other point to note would be to check the BGP OPEN message from neighbor:

09:08:46.423997  In
        Juniper PCAP Flags [Ext, no-L2, In], PCAP Extension(s) total length 16
          Device Media Type Extension TLV #3, length 1, value: Ethernet (1)
          Logical Interface Encapsulation Extension TLV #6, length 1, value: Ethernet (14)
          Device Interface Index Extension TLV #1, length 2, value: 164
          Logical Interface Index Extension TLV #4, length 4, value: 85
        -----original packet-----
        PFE proto 2 (ipv4): (tos 0xc0, ttl 254, id 11937, offset 0, flags [none], proto: TCP (6), length: 119) 1.1.1.1.bgp > 3.3.3.3.62244: P 1:68(67) ack 68 win 16384 <nop,nop,timestamp 414764499 414760409>: BGP, length: 67
        Open Message (1), length: 67
          Version 4, my AS 100, Holdtime 90s, ID 1.1.1.1
          Optional parameters, length: 38
            Option Capabilities Advertisement (2), length: 6
              Multiprotocol Extensions (1), length: 4
                AFI IPv4 (1), SAFI Unicast (1)
                0x0000: 0001 0001
            Option Capabilities Advertisement (2), length: 6
              Multiprotocol Extensions (1), length: 4
                AFI IPv4 (1), SAFI labeled VPN Unicast (128)
                0x0000: 0001 0080
            Option Capabilities Advertisement (2), length: 2
              Route Refresh (Cisco) (128), length: 0
            Option Capabilities Advertisement (2), length: 2
              Route Refresh (2), length: 0
            Option Capabilities Advertisement (2), length: 4
              Graceful Restart (64), length: 2
                Restart Flags: [none], Restart Time 120s
                0x0000: 0078
            Option Capabilities Advertisement (2), length: 6
              32-Bit AS Number (65), length: 4
                 4 Byte AS 100
                0x0000: 0000 0064

hi,Surya

thanks for your kind reply

I know there are MP-BGP and the normal one,so MP-BGP which for vpn route will not use inet.0 ,right?

besides this,I also have one quick question

in the preious example ,we move inet.3 to inet. 0,such as 1.1.1.1    lsp_r2-r1

since bgp can use this entry to reslove nexthop.what will igp do,such as isis or ospf

I don't want to go to 1.1.1.1,I want to go to prefix 192.168.1.1. behind 1.1.1.1

if I only can use 1.1.1.1 to go to 1.1.1.1 as destination,it seems it is not powerful

can u show me an example?

.......

Hi Rob,

---

Robbie wrote:

I saw they use this bgp-igp with labeled-unicast in some case

not sure why

would u like to show me an example

---

Unfortunately I had never come cross like this for labeled-unicast routes.

Having said that I have seen labeled-unicast been used for resolving VPN routes who rely on inet.3 routes.

By default, BGP labeled-unicast routes are installed in inet.0 table, in case you don't define rib.

In case if you want to make use of these labeled BGP routes to resolve VPN routes you can include "resolve vpn" knob,  which will copy BGP labeled route to inet.3 table as well.

suryak@PE# run show route 1.1.1.1

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

1.1.1.1/32         *[OSPF/10] 00:16:16, metric 2
                    > to 20.0.2.1 via ge-3/1/2.0
                    [BGP/170] 00:00:34, localpref 100, from 2.2.2.2
                      AS path: I, validation-state: unverified
                    > to 20.0.2.1 via ge-3/1/2.0, Push 300016

[edit]
regress@boxster# run show bgp summary    
Groups: 1 Peers: 2 Down peers: 0
Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
inet.0               
                       1          0          0          0          0          0
inet.3               
                       0          0          0          0          0          0
bgp.l3vpn.0          
                       4          0          0          0          0          0
Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
1.1.1.1                 100          7          5       0       0          57 Establ
  VPNA.inet.0: 0/4/4/0
  bgp.l3vpn.0: 0/4/4/0    <--- HIDDEN
2.2.2.2                 100          4          5       0       0        1:01 Establ
  inet.0: 0/1/1/0

suryak@PE# set protocols bgp group ibgp neighbor 2.2.2.2 family inet labeled-unicast resolve-vpn

suryak@PE# run show route 1.1.1.1                                                                   

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

1.1.1.1/32         *[OSPF/10] 00:17:15, metric 2
                    > to 20.0.2.1 via ge-3/1/2.0
                    [BGP/170] 00:01:33, localpref 100, from 2.2.2.2
                      AS path: I, validation-state: unverified
                    > to 20.0.2.1 via ge-3/1/2.0, Push 300016

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

1.1.1.1/32         *[BGP/170] 00:00:01, localpref 100, from 2.2.2.2
                      AS path: I, validation-state: unverified
                    > to 20.0.2.1 via ge-3/1/2.0, Push 300016

suryak@PE# run show bgp summary                                                                     
Groups: 1 Peers: 2 Down peers: 0
Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
inet.0               
                       1          0          0          0          0          0
inet.3               
                       0          0          0          0          0          0
bgp.l3vpn.0          
                       4          4          0          0          0          0
Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
1.1.1.1                 100          9          7       0       0        2:09 Establ
  VPNA.inet.0: 4/4/4/0
  bgp.l3vpn.0: 4/4/4/0
2.2.2.2                 100          6          7       0       0        2:13 Establ
  inet.0: 0/1/1/0

Regards

Surya

Hi Rob,

We move inet.3 to inet.0 to have non-bgp applications to also use labeled path.

By default, BGP will pefer to resolve protocol NH using inet.3, if it is no available, then it will resolve using inet.0 route.

However when you inet.3 to inet.0, you will still see both IGP(OSPF/ISIS) and MPLS(RSVP/LDP) in inet.0. But  RSVP/LDP are more preferrable than OSPF/ISIS.

Say for example 192.168.1.2 is on other side of 1.1.1.1, you can install this prefix on PE(ingress LSR) to take the LSP PATH which is defined for 1.1.1.1

suryak@PE# show protocols mpls
label-switched-path lsp-box-hun {
    to 1.1.1.1;
    install 192.168.1.2/32 active;
}

suryak@PE# run show rsvp session name lsp-box-hun ingress
Ingress RSVP: 1 sessions
To              From            State   Rt Style Labelin Labelout LSPname
1.1.1.1         3.3.3.3         Up       0  1 FF       -   299952 lsp-box-hun
Total 1 displayed, Up 1, Down 0

suryak@PE# run traceroute 192.168.1.2                        
traceroute to 192.168.1.2 (192.168.1.2), 30 hops max, 40 byte packets
 1  20.0.2.1 (20.0.2.1)  0.647 ms  0.583 ms  0.575 ms
     MPLS Label=299952 CoS=0 TTL=1 S=1
 2  11.0.1.1 (11.0.1.1)  3.352 ms  0.521 ms  0.433 ms
 3  192.168.1.2 (192.168.1.2)  0.725 ms  0.610 ms  0.579 ms

Regards

Surya

....................