Link-State Distribution Using BGP
Link-State Distribution Using BGP Overview
- Role of an Interior Gateway Protocol
- Limitations of an Interior Gateway Protocol
- Need for Spanning Link-State Distribution
- Using BGP as a Solution
- Supported and Unsupported Features
- BGP Link-State Extensions for Source Packet Routing in Networking (SPRING)
- Verifying NLRI Node Learned Through BGP with OSPF as IGP
- Verifying the Prefix NLRI Learned Through BGP with OSPF as IGP
Role of an Interior Gateway Protocol
An interior gateway protocol (IGP) is a type of protocol used for exchanging routing information between devices within an autonomous system (AS). Based on the method of computing the best path to a destination, the IGPs are divided into two categories:
Link-state protocols—Advertise information about the network topology (directly connected links and the state of those links) to all routers using multicast addresses and triggered routing updates until all the routers running the link-state protocol have identical information about the internetwork. The best path to a destination is calculated based on constraints such as maximum delay, minimum available bandwidth, and resource class affinity.
OSPF and IS-IS are examples of link-state protocols.
Distance vector protocols—Advertise complete routing table information to directly connected neighbors using a broadcast address. The best path is calculated based on the number of hops to the destination network.
RIP is an example of a distance vector protocol.
As the name implies, the role of an IGP is to provide routing connectivity within or internal to a given routing domain. A routing domain is a set of routers under common administrative control that share a common routing protocol. An AS can consist of multiple routing domains, where IGP functions to advertise and learn network prefixes (routes) from neighboring routers to build a route table that ultimately contains entries for all sources advertising reachability for a given prefix. IGP executes a route selection algorithm to select the best path between the local router and each destination, and provides full connectivity among the routers making up a routing domain.
In addition to advertising internal network reachability, IGPs are often used to advertise routing information that is external to that IGP's routing domain through a process known as route redistribution. Route redistribution is the process of exchanging routing information among distinct routing protocols to tie multiple routing domains together when intra-AS connectivity is desired.
Limitations of an Interior Gateway Protocol
While each individual IGP has its own advantages and limitations, the biggest limitations of IGP in general are performance and scalability.
IGPs are designed to handle the task of acquiring and distributing network topology information for traffic engineering purposes. While this model has served well, IGPs have inherent scaling limitations when it comes to distributing large databases. IGPs can autodetect neighbors, with which they acquire intra-area network topology information. However, the link-state database or a traffic engineering database has the scope of a single area or AS, thereby limiting applications, such as end-to-end traffic engineering, the benefit of having external visibility to make better decisions.
For label-switched networks, such as MPLS and Generalized MPLS (GMPLS), most existing traffic engineering solutions work in a single routing domain. These solutions do not work when a route from the ingress node to the egress node leaves the routing area or AS of the ingress node. In such cases, the path computation problem becomes complicated because of the unavailability of the complete routing information throughout the network. This is because service providers usually choose not to leak routing information beyond the routing area or AS for scalability constraints and confidentiality concerns.
Need for Spanning Link-State Distribution
One of the limitations of IGP is its inability to span link-state distribution outside a single area or AS. However, spanning link-state information acquired by an IGP across multiple areas or ASs has the following needs:
LSP path computation—This information is used to compute the path for MPLS LSPs across multiple routing domains, for example an inter-area TE LSP.
External path computing entities—External path computing entities, such as Application Layer Traffic Optimization (ALTO) and Path Computation Elements (PCE), perform path computations based on the network topology and current state of connections within the network, including traffic engineering information. This information is typically distributed by IGPs within the network.
However, because the external path computing entities cannot extract this information from the IGPs, they perform network monitoring to optimize network services.
Using BGP as a Solution
Overview
To meet the needs for spanning link-state distribution across multiple domains, an exterior gateway protocol (EGP) is required to collect link-state and traffic engineering information from an IGP area, share it with external component, and use it for computing paths for interdomain MPLS LSPs.
BGP is a standardized EGP designed to exchange routing and reachability information between autonomous systems (ASs). BGP is a proven protocol that has better scaling properties because it can distribute millions of entries (for example, VPN prefixes) in a scalable fashion. BGP is the only routing protocol in use today that is suited to carry all of the routes in the Internet. This is largely because BGP runs on top of TCP and can make use of TCP flow control. In contrast, the internal gateway protocols (IGPs) do not have flow control. When IGPs have too much route information, they begin to churn. When BGP has a neighboring speaker that is sending information too quickly, BGP can throttle down the neighbor by delaying TCP acknowledgments.
Another benefit of BGP is that it uses type, length, value (TLV) tuples and network layer reachability information (NLRI) that provide seemingly endless extensibility without the need for the underlying protocol to be altered.
The distribution of link-state information across domains is regulated using policies to protect the interests of the service provider. This requires a control over the topology distribution using policies. BGP with its implemented policy framework serves well in the interdomain route distribution. In Junos OS, BGP is completely policy driven. The operator must explicitly configure neighbors to peer with and explicitly accept routes into BGP. Furthermore, routing policy is used to filter and modify routing information. Thus, routing policies provide complete administrative control over the routing tables.
Although, within an AS, both IGP-TE and BGP-TE provide the same set of information, BGP-TE has better scaling characteristics that are inherited from the standard BGP protocol. This makes BGP-TE a more scalable choice for acquiring multi-area/multi-AS topology information.
By using BGP as a solution, the IGP-acquired information is used for distribution into BGP. The ISPs can selectively expose this information with other ISPs, service providers, and content distribution networks (CDNs) through normal BGP peering. This allows for aggregation of the IGP-acquired information across multiple areas and ASs, such that an external path computing entity can access the information by passively listening to a route reflector.
Implementation
In Junos OS, the IGPs install topology information into a
database called the traffic engineering database. The
traffic engineering database contains the aggregated
topology information. To install IGP topology information
into traffic engineering database, use the set
igp-topology configuration statement at the
[edit protocols isis
traffic-engineering] and [edit
protocols ospf traffic-engineering]
hierarchy levels. The mechanism to distribute link-state
information using BGP includes the process of advertising
the traffic engineering database into BGP-TE (import), and
installing entries from BGP-TE into the traffic engineering
database (export).
Starting in Junos OS Release 20.4R1, you can configure IS-IS traffic engineering to store IPv6 information in the traffic engineering database (TED) in addition to IPv4 addresses. BGP-LS distributes this information as routes from the traffic engineering database to the lsdist.0 routing table using the traffic engineering database import policies. These routes are advertised to BGP-TE peers as network layer reachability information (NLRI) with IPv6 router ID type, length, and value (TLV). With addition of IPv6 information, you can benefit from obtaining the complete network topology into the traffic engineering database.
BGP-LS NLRI and Confederation ID
Starting in Junos OS Release 23.1R1, Junos OS enables BGP Link State (BGP-LS) network layer reachability information (NLRI) to carry the confederation ID in TLV 512 when BGP confederation is enabled. The NLRI carries the confederation ID along with the member autonomous system number (AS number) in TLV 517 as defined in RFC 9086. The Junos OS traffic engineering database module makes necessary changes to encode confederation ID and member AS number in TLV 512 and TLV 517 respectively, while originating the BGP-LS NLRI (which is injected into lsdist.0 routing table). In releases before Junos OS Release 23.1R1, BGP-LS NLRI carries only the member AS number in TLV 512 and the confederation ID is not encoded in the lsdist.0 routing table.
Traffic Engineering Database Import
To advertise the traffic engineering database
into BGP-TE, the link and node entries in the
traffic engineering database are converted in the
form of routes. These converted routes are then
installed by the traffic engineering database on
behalf of the corresponding IGP, into a
user-visible routing table called
lsdist.0, on conditions subject
to route policies. The procedure of leaking
entries from the traffic engineering database into
lsdist.0 is called traffic
engineering database import as illustrated in
Figure 1.
There are polices to govern the traffic
engineering database import process. By default,
no entries are leaked from the traffic engineering
database into the lsdist.0
table.
Starting in Junos OS Release 17.4R1, the traffic
engineering database installs interior gateway
protocol (IGP) topology information in addition to
RSVP-TE topology information in the lsdist.0
routing table as illustrated in Figure 1. Prior to Junos OS Release 17.4R1, the traffic
engineering database only exported RSVP-TE
topology information. Now you can monitor both IGP
and traffic engineering topology information. The
BGP-LS reads IGP entries from lsdist.0 and
advertises these entries to the BGP peers. To
import IGP topology information into BGP-LS from
lsdist.0, use the set bgp-ls
configuration statement at the [edit
protocols mpls traffic-engineering database import
igp-topology] hierarchy level.
Traffic Engineering Database Export
BGP can be configured to export or advertise
routes from the lsdist.0 table,
subject to policy. This is common for any kind of
route origination in BGP. In order to advertise
BGP-TE into the traffic engineering database, BGP
needs to be configured with the BGP-TE address
family, and an export policy that selects routes
for redistribution into BGP.
BGP then propagates these routes like any other
NLRI. BGP peers that have the BGP-TE family
configured and negotiated receive BGP-TE NLRIs.
BGP stores the received BGP-TE NLRIs in the form
of routes in the lsdist.0 table,
which is the same table that stores locally
originated BGP-TE routes. The BGP-installed routes
in lsdist.0 are then distributed
to other peers like any other route. Thus, the
standard route selection procedure applies to
BGP-TE NLRIs received from multiple speakers.
To achieve interdomain TE, the routes in
lsdist.0 are leaked into the
traffic engineering database through a policy.
This process is called traffic engineering
database export as illustrated in Figure 1.
There are polices to govern the traffic
engineering database export process. By default,
no entries are leaked from the
lsdist.0 table into the traffic
engineering database.
Starting in Junos OS Release 22.4R1, you can distribute the traffic engineering (TE) policies that originate from the segment routing protocol to the traffic engineering database (TED) and into the BGP link-state as routes. BGP link-state collects the information related to the TE policies, so that the external controllers can perform actions such as path-computation, re-optimization, and network visualization within and across domains.
Configure set protocols
source-packet-routing traffic-engineering
database to allow the segment routing
(SR) policies to be stored in TED.
For SDN applications, such as PCE and ALTO, the BGP-TE advertised information cannot leak into the traffic engineering database of a router. In such cases, an external server that peers with the routers using BGP-TE is used to move topology information up into the sky/orchestration system that spans the network. These external servers can be deemed as BGP-TE consumers, where they receive BGP-TE routes, but do not advertise them.
Assigning Credibility Values
Once the entries are installed in the traffic engineering database, the BGP-TE learned information is made available for CSPF path computation. The traffic engineering database uses a protocol preference scheme that is based on credibility values. A protocol with a higher credibility value is preferred over a protocol with a lower credibility value. BGP-TE has the capability to advertise information learned from multiple protocols at the same time, and so in addition to the IGP-installed entries in the traffic engineering database, there can be BGP-TE installed entries that correspond to more than one protocol. The traffic engineering database export component creates a traffic engineering database protocol and credibility level for each protocol that BGP-TE supports. These credibility values are configurable in the CLI.
The credibility order for the BGP-TE protocols is as follows:
-
Unknown—80
-
OSPF—81
-
ISIS Level 1—82
-
ISIS Level 2—83
-
Static—84
-
Direct—85
Cross-Credibility Path Computation
After you assign credibility values, each credibility level is treated as an individual plane. The Constrained Shorted Path First algorithm starts with the highest assigned credibility to the lowest, finding a path within that credibility level.
With BGP-TE, it is essential to compute paths across credibility levels to compute inter-AS paths. For example, different credibility settings are seen on a device from area 0 that computes the path through area 1, because area 0 entries are installed by OSPF, and area 1 entries are installed by BGP-TE.
To enable path computation across credibility
levels, include the
cross-credibility-cspf statement
at the edit protocols mpls,
[edit protocols mpls label-switched-path
lsp-name], and
[edit protocols rsvp] hierarchy
levels. At the [edit protocols
rsvp] hierarchy level, enabling
cross-credibility-cspf impacts
bypass LSPs and loose hop expansion in
transit.
Configuring
cross-credibility-cspf enables
path computation across credibility levels using
the Constrained Shortest Path First algorithm,
wherein the constraint is not performed on a
credibility-by-credibility basis, but as a single
constraint ignoring the assigned credibility
values.
BGP-TE NLRIs and TLVs
Like other BGP routes, BGP-TE NLRIs can also be distributed through a route reflector that speaks BGP-TE NLRI. Junos OS implements the route reflection support for the BGP-TE family.
The following is a list of supported NLRIs:
-
Link NLRI
-
Node NLRI
-
IPv4 Prefix NLRI (receive and propagate)
-
IPv6 Prefix NLRI (receive and propagate)
-
TE policy NLRI
Junos OS does not provide support for the route-distinguisher form of the above NRLIs.
The following is a list of supported fields in link and node NLRIs:
-
Protocol-ID—NLRI originates with the following protocol values:
-
ISIS-L1
-
ISIS-L2
-
OSPF
-
SPRING-TE
-
-
Identifier—This value is configurable. By default, the identifier value is set to
0. -
Local/Remote node descriptor—These include:
-
Autonomous system
-
BGP-LS Identifier—This value is configurable. By default, the BGP-LS identifier value is set to
0 -
Area-ID
-
IGP router-ID
-
-
Link descriptors (Only for link NLRI)—This includes:
-
Link Local/Remote Identifiers
-
IPv4 interface address
-
IPv4 neighbor address
-
IPv6 neighbor/interface address—The IPv6 neighbor and interface addresses are not originated, but only stored and propagated when received.
-
Multi-topology ID—This value is not originated, but stored and propagated when received.
-
The following is a list of supported LINK_STATE attribute TLVs:
-
Link attributes:
-
Administrative group
-
Max link bandwidth
-
Max reservable bandwidth
-
Unreserved bandwidth
-
TE default metric
-
SRLG
-
The following TLVs, which are not originated, but only stored and propagated when received:
-
Opaque link attributes
-
MPLS protocol mask
-
Metric
-
Link protection type
-
Link name attribute
-
-
-
Node attributes:
-
IPv4 Router-ID
-
Node flag bits—Only the overload bit is set.
-
The following TLVs, which are not originated, but only stored and propagated when received:
-
Multi-topology
-
OSPF-specific node properties
-
Opaque node properties
-
Node name
-
IS-IS area identifier
-
IPv6 Router-ID
-
-
Prefix attributes—These TLVs are stored and propagated like any other unknown TLVs.
-
Supported and Unsupported Features
Junos OS supports the following features with link-state distribution using BGP:
Advertisement of multiprotocol assured forwarding capability
Transmission and reception of node and link-state BGP and BGP-TE NLRIs
Nonstop active routing for BGP-TE NLRIs
Policies
Junos OS does not support the following functionality for link-state distribution using BGP:
Aggregated topologies, links, or nodes
Route distinguisher support for BGP-TE NLRIs
Multi-topology identifiers
Multi-instance identifiers (excluding the default instance ID 0)
Advertisement of the link and node area TLV
Advertisement of MPLS signaling protocols
Importing node and link information with overlapping address
BGP Link-State Extensions for Source Packet Routing in Networking (SPRING)
Starting in Junos OS Release 17.2R1, the BGP link-state address family is extended to distribute the source packet routing in networking (SPRING) topology information to software-defined networking (SDN) controllers. BGP typically learns the link-state information from IGP and distributes it to BGP peers. Besides BGP, the SDN controller can get link-state information directly from IGP if the controller is a part of an IGP domain. However, BGP link-state distribution provides a scalable mechanism to export the topology information. BGP link-state extensions for SPRING is supported on interdomain networks.
- Source Packet Routing in Networking (SPRING)
- Flow of BGP Link-State SPRING Data
- Supported BGP Link-State Attributes and TLVs, and Unsupported Features for BGP Link-State with SPRING
Source Packet Routing in Networking (SPRING)
SPRING is a control-plane architecture that enables an ingress router to steer a packet through a specific set of nodes and links in the network without relying on the intermediate nodes in the network to decide the actual path it must take. SPRING engages IGPs, such as IS-IS and OSPF, for advertising network segments. Network segments can represent any instruction, topological or service-based. Within IGP topologies, IGP segments are advertised by the link-state routing protocols. There are two types of IGP segments:
| Adjacency segment |
A one-hop path over a specific adjacency between two nodes in the IGP |
| Prefix segment |
A multi-hop, equal-cost, multipath-aware shortest-path to a prefix, as per the state of the IGP topology |
When SPRING in enabled in a BGP network, BGP link-state address family learns the SPRING information from the IGP link-state routing protocols and advertises segments in the form of segment identifiers (SIDs). BGP link-state address family has been extended to carry SIDs and other SPRING-related information to BGP peers. The route reflector can steer a packet through a desired set of nodes and links by prepending the packet with an appropriate combination of tunnels. This feature allows BGP link-state address family to also advertise the SPRING information to BGP peers.
Flow of BGP Link-State SPRING Data
Figure 2 depicts the data flow of BGP link-state SPRING data that IS-IS pushes to the traffic engineering database.
-
IGP pushes the SPRING attributes to the traffic engineering database.
-
SPRING capabilities and algorithm information are carried forward as node attributes into the traffic engineering database.
-
Adjacent SID and LAN adjacent SID information are carried as link attributes.
-
Prefix SID or node-SID information is carried as prefix attributes.
-
A new set or a change to existing attributes triggers IGP updates to the traffic engineering database with new data.
CAUTION:If traffic engineering is disabled at the IGP level, none of the attributes are pushed to the traffic engineering database.
-
All parameters in the BGP traffic engineering NLRI, including the link, node, and prefix descriptors are derived from entries in the traffic engineering database.
-
The traffic engineering database imports route entries into the
lsdist.0routing table from IGP subject to policy. -
The default policy of BGP is to export routes, which are known to BGP only. You configure an export policy for non-BGP routes in the
lsdis.0routing table. This policy advertises an entry learned from the traffic engineering database.
Supported BGP Link-State Attributes and TLVs, and Unsupported Features for BGP Link-State with SPRING
BGP link-state with SPRING supports the following attributes and type, length, and values (TLVs) that are originated, received, and propagated in the network:
Node attributes
-
Segment routing Capabilities
-
Segment routing Algorithm
Link attributes
-
Adjacent-SID
-
LAN Adjacent-SID
Prefix descriptors
-
IP reachability information
Prefix attributes
-
Prefix SID
The following list supports TLVs that are not originated, but only received and propagated in the network:
Prefix descriptors
-
Multitopology ID
-
OSPF route type
Prefix attributes
-
Range
-
Binding SID
Junos OS does not support the following features with BGP link-state with SPRING extensions:
-
IPv6 prefix origination
-
Multitopology identifiers
-
Traffic engineering database export for SPRING parameters
-
New TLVs with tcpdump (existing TLVs are also not supported).
-
SPRING over IPv6
Verifying NLRI Node Learned Through BGP with OSPF as IGP
The following is a sample output to verify the NLRI node learned through BGP with OSPF as the IGP:
Purpose
Verify the lsdist.0 routing table entries.
Action
From operational mode, run the show route
table lsdist.0 command.
user@host> show route table lsdist.0 te-node-ip 10.7.7.7 extensive
lsdist.0: 216 destinations, 216 routes (216 active, 0 holddown, 0 hidden)
NODE { AS:65100 Area:0.0.0.1 IPv4:10.7.7.7 OSPF:0 }/1536 (1 entry, 1 announced)
TSI:
LINK-STATE attribute handle 0x61d5da0
*BGP Preference: 170/-101
Next hop type: Indirect, Next hop index: 0
Address: 0x61b07cc
Next-hop reference count: 216
Source: 10.2.2.2
Protocol next hop: 10.2.2.2
Indirect next hop: 0x2 no-forward INH Session ID: 0x0
State:<Active Int Ext>
Local AS: 65100 Peer AS: 65100
Age: 30:22 Metric2: 2
Validation State: unverified
Task: BGP_65100.10.2.2.2
Announcement bits (1): 0-TED Export
AS path: I
Accepted
Area border router: No
External router: No
Attached: No
Overload: No
SPRING-Capabilities:
- SRGB block [Start: 900000, Range: 90000, Flags: 0x00]
SPRING-Algorithms:
- Algo: 0
Localpref: 100
Router ID: 10.2.2.2
Indirect next hops: 1
Protocol next hop: 10.2.2.2 Metric: 2
Indirect next hop: 0x2 no-forward INH Session ID: 0x0
Indirect path forwarding next hops: 1
Next hop type: Router
Next hop: 10.11.1.2 via et-0/0/0.1 weight 0x1
Session Id: 0x143
10.2.2.2/32 Originating RIB: inet.0
Metric: 2 Node path count: 1
Forwarding nexthops: 1
Nexthop: 10.11.1.2 via et-0/0/0.1
Session Id: 143Meaning
The routes are appearing in the lsdist.0 routing table.
Verifying the Prefix NLRI Learned Through BGP with OSPF as IGP
The following is a sample output to verify the prefix NLRI learned through BGP with OSPF as the IGP:
Purpose
Verify the lsdist.0 routing table entries.
Action
From operational mode, run the show route table lsdist.0 command.
user@host> show route table lsdist.0 te-ipv4-prefix-node-ip 10.7.7.7 extensive
lsdist.0: 216 destinations, 216 routes (216 active, 0 holddown, 0 hidden)
PREFIX { Node { AS:65100 Area:0.0.0.1 IPv4:10.7.7.7 } { IPv4:10.7.7.7/32 } OSPF:0 }/1536 (1 entry, 0 announced)
*BGP Preference: 170/-101
Next hop type: Indirect, Next hop index: 0
Address: 0x61b07cc
Next-hop reference count: 216
Source: 10.2.2.2
Protocol next hop: 10.2.2.2
Indirect next hop: 0x2 no-forward INH Session ID: 0x0
State: <Active Int Ext>
Local AS: 65100 Peer AS: 65100
Age: 30:51 Metric2: 2
Validation State: unverified
Task: BGP_65100.10.2.2.2
AS path: I
Accepted
Prefix Flags: 0x00, Prefix SID: 1007, Flags: 0x50, Algo: 0
Localpref: 65100
Router ID: 10.2.2.2
Indirect next hops: 1
Protocol next hop: 10.2.2.2 Metric: 2
Indirect next hop: 0x2 no-forward INH Session ID: 0x0
Indirect path forwarding next hops: 1
Next hop type: Router
Next hop: 10.11.1.2 via et-0/0/0.1 weight 0x1
Session Id: 0x143
10.2.2.2/32 Originating RIB: inet.0
Metric: 2 Node path count: 1
Forwarding nexthops: 1
Nexthop: 10.11.1.2 via et-0/0/0.1
Session Id: 143Meaning
The routes are appearing in the lsdist.0 routing table.
Example: Configuring Link State Distribution Using BGP
This example shows how to configure BGP to carry link-state information across multiple domains, which is used for computing paths for MPLS LSPs spanning multiple domains, such as inter-area TE LSP, and providing a scalable and policy-controlled means for external path computing entities, such as ALTO and PCE, to acquire network topology.
Requirements
This example uses the following hardware and software components:
-
Four routers that can be a combination of M Series, MX Series, or T Series routers
-
Junos OS Release 14.2 or later running on all the routers
Before you begin:
-
Configure the device interfaces.
-
Configure the autonomous system numbers and router IDs for the devices.
-
Configure the following protocols:
-
RSVP
-
MPLS
-
BGP
-
IS-IS
-
OSPF
-
Overview
Starting with Junos OS Release 14.2, a new mechanism to distribute topology information across multiple areas and autonomous systems (ASs) is introduced by extending the BGP protocol to carry link -state information, which was initially acquired using IGP. The IGP protocols have scaling limitations when it comes to distributing large databases. BGP is not only a more scalable vehicle for carrying multi-area and multi-AS topology information, but also provides the policy controls that can be useful for multi-AS topology distribution. The BGP link-state topology information is used for computing paths for MPLS label-switched paths (LSPs) spanning multiple domains, such as inter-area TE LSP, and providing a scalable and policy-controlled means for external path computing entities, such as ALTO and PCE, to acquire network topology.
Starting with Junos OS Release 17.1R1, link state distribution using BGP is supported on QFX10000 switches.
Topology
In Figure 3, Routers R0 and R1 and Routers R2 and R3 belong to different autonomous systems. Routers R0 and R1 run OSPF, and Routers R2 and R3 run IS-IS.
Configuration
CLI Quick Configuration
To quickly configure this example, copy the following commands, paste them into a
text file, remove any line breaks, change any details necessary to match your
network configuration, copy and paste the commands into the CLI at the
[edit] hierarchy level, and then enter
commit from configuration mode.
R0
set interfaces ge-0/0/0 unit 0 family inet address 10.8.31.101/24 set interfaces ge-0/0/0 unit 0 family iso set interfaces ge-0/0/0 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.105.137/32 set routing-options router-id 10.255.105.137 set routing-options autonomous-system 65533 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls traffic-engineering database export policy accept-all set protocols mpls cross-credibility-cspf set protocols mpls label-switched-path to-R3-inter-as to 10.255.105.135 set protocols mpls label-switched-path to-R3-inter-as bandwidth 40m set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols bgp group ibgp type internal set protocols bgp group ibgp local-address 10.255.105.137 set protocols bgp group ibgp family traffic-engineering unicast set protocols bgp group ibgp neighbor 10.255.105.141 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface lo0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set policy-options policy-statement accept-all from family traffic-engineering set policy-options policy-statement accept-all then accept
R1
set interfaces ge-0/0/0 unit 0 family inet address 10.8.31.103/24 set interfaces ge-0/0/0 unit 0 family iso set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 family inet address 10.8.42.102/24 set interfaces ge-0/0/1 unit 0 family iso set interfaces ge-0/0/1 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.105.141/32 set interfaces lo0 unit 0 family iso address 47.0005.0102.5501.8181 set routing-options router-id 10.255.105.141 set routing-options autonomous-system 65533 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols bgp group ibgp type internal set protocols bgp group ibgp local-address 10.255.105.141 set protocols bgp group ibgp family traffic-engineering unicast set protocols bgp group ibgp export nlri2bgp set protocols bgp group ibgp neighbor 10.255.105.137 set protocols bgp group ebgp type external set protocols bgp group ebgp family traffic-engineering unicast set protocols bgp group ebgp neighbor 10.8.42.104 local-address 10.8.42.102 set protocols bgp group ebgp neighbor 10.8.42.104 peer-as 65534 set protocols isis interface ge-0/0/1.0 passive remote-node-iso 0102.5502.4211 set protocols isis interface ge-0/0/1.0 passive remote-node-id 10.8.42.104 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface lo0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 passive traffic-engineering remote-node-id 10.8.42.104 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 passive traffic-engineering remote-node-router-id 10.255.105.139 set policy-options policy-statement accept-all from family traffic-engineering set policy-options policy-statement accept-all then accept set policy-options policy-statement nlri2bgp term 1 from family traffic-engineering set policy-options policy-statement nlri2bgp term 1 then accept
R2
set interfaces ge-0/0/0 unit 0 family inet address 10.8.64.104/24 set interfaces ge-0/0/0 unit 0 family iso set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 family inet address 10.8.42.104/24 set interfaces ge-0/0/1 unit 0 family iso set interfaces ge-0/0/1 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.105.139/32 set interfaces lo0 unit 0 family iso address 47.0005.0102.5502.4211.00 set routing-options router-id 10.255.105.139 set routing-options autonomous-system 65534 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls traffic-engineering database import policy ted2nlri set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols bgp group ibgp type internal set protocols bgp group ibgp local-address 10.255.105.139 set protocols bgp group ibgp family traffic-engineering unicast set protocols bgp group ibgp export nlri2bgp set protocols bgp group ibgp neighbor 10.255.105.135 set protocols bgp group ebgp type external set protocols bgp group ebgp family traffic-engineering unicast set protocols bgp group ebgp export nlri2bgp set protocols bgp group ebgp peer-as 65533 set protocols bgp group ebgp neighbor 10.8.42.102 set protocols isis level 1 disable set protocols isis interface ge-0/0/0.0 set protocols isis interface ge-0/0/1.0 passive remote-node-iso 0102.5501.8181 set protocols isis interface ge-0/0/1.0 passive remote-node-id 10.8.42.102 set protocols isis interface lo0.0 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 passive traffic-engineering remote-node-id 10.8.42.102 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 passive traffic-engineering remote-node-router-id 10.255.105.141 set policy-options policy-statement accept-all from family traffic-engineering set policy-options policy-statement accept-all then accept set policy-options policy-statement nlri2bgp term 1 from family traffic-engineering set policy-options policy-statement nlri2bgp term 1 then accept set policy-options policy-statement ted2nlri term 1 from protocol isis set policy-options policy-statement ted2nlri term 1 from protocol ospf set policy-options policy-statement ted2nlri term 1 then accept set policy-options policy-statement ted2nlri term 2 then reject
R3
set interfaces ge-0/0/0 unit 0 family inet address 10.8.64.106/24 set interfaces ge-0/0/0 unit 0 family iso set interfaces ge-0/0/0 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.255.105.135/32 set interfaces lo0 unit 0 family iso address 47.0005.0102.5502.4250 set routing-options router-id 10.255.105.135 set routing-options autonomous-system 65534 set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable set protocols mpls traffic-engineering database export policy accept-all set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols bgp group ibgp type internal set protocols bgp group ibgp local-address 10.255.105.135 set protocols bgp group ibgp family traffic-engineering unicast set protocols bgp group ibgp neighbor 10.255.105.139 set protocols isis interface ge-0/0/0.0 level 1 disable set protocols isis interface lo0.0 set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface lo0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set policy-options policy-statement accept-all from family traffic-engineering set policy-options policy-statement accept-all then accept
Procedure
Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode.
To configure Router R1:
-
Configure the Router R1 interfaces.
[edit interfaces] user@R1# set ge-0/0/0 unit 0 family inet address 10.8.31.103/24 user@R1# set ge-0/0/0 unit 0 family iso user@R1# set ge-0/0/0 unit 0 family mpls user@R1# set ge-0/0/1 unit 0 family inet address 10.8.42.102/24 user@R1# set ge-0/0/1 unit 0 family iso user@R1# set ge-0/0/1 unit 0 family mpls user@R1# set lo0 unit 0 family inet address 10.255.105.141/32 user@R1# set lo0 unit 0 family iso address 47.0005.0102.5501.8181
-
Configure the router ID and autonomous system of Router R1.
[edit routing-options]user@R1# set router-id 10.255.105.141 user@R1# set autonomous-system 65533 -
Enable RSVP on all the interfaces of Router R1 (excluding the management interface).
[edit protocols]user@R1# set rsvp interface all user@R1# set rsvp interface fxp0.0 disable -
Enable MPLS on all the interfaces of Router R1 (excluding the management interface).
[edit protocols]user@R1# set mpls interface all user@R1# set mpls interface fxp0.0 disable -
Configure the BGP group for Router R1 to peer with Router R0, and assign the local address and neighbor address.
[edit protocols]user@R1# set bgp group ibgp type internal user@R1# set bgp group ibgp local-address 10.255.105.141 user@R1# set bgp group ibgp neighbor 10.255.105.137 -
Include the BGP-TE signaling network layer reachability information (NLRI) to the ibgp BGP group.
[edit protocols]user@R1# set bgp group ibgp family traffic-engineering unicast -
Enable export of policy nlri2bgp on Router R1.
[edit protocols]user@R1# set bgp group ibgp export nlri2bgp -
Configure the BGP group for Router R1 to peer with Router R2, and assign the local address and neighbor autonomous system to the ebgp BGP group.
[edit protocols]user@R1# set bgp group ebgp type external user@R1# set bgp group ebgp neighbor 10.8.42.104 local-address 10.8.42.102 user@R1# set bgp group ebgp neighbor 10.8.42.104 peer-as 65534 -
Include the BGP-TE signaling NLRI to the ebgp BGP group.
[edit protocols]user@R1# set bgp group ebgp family traffic-engineering unicast -
Enable passive traffic-engineering on the inter-AS link.
[edit protocols]user@R1# set isis interface ge-0/0/1.0 passive remote-node-iso 0102.5502.4211 user@R1# set isis interface ge-0/0/1.0 passive remote-node-id 10.8.42.104 -
Enable OSPF on the interface connecting Router R1 to Router R0 and on the loopback interface of Router R1, and enable traffic engineering capabilities.
[edit protocols]user@R1# set ospf traffic-engineering user@R1# set ospf area 0.0.0.0 interface lo0.0 user@R1# set ospf area 0.0.0.0 interface ge-0/0/0.0 -
Enable passive traffic-engineering on the inter-AS link.
[edit protocols]user@R1# set ospf area 0.0.0.0 interface ge-0/0/1.0 passive traffic-engineering remote-node-id 10.8.42.104 user@R1# set ospf area 0.0.0.0 interface ge-0/0/1.0 passive traffic-engineering remote-node-router-id 10.255.105.139 -
Configure policies to accept traffic from BGP-TE NLRI.
[edit policy-options]user@R1# set policy-statement accept-all from family traffic-engineering user@R1# set policy-statement accept-all then accept user@R1# set policy-statement nlri2bgp term 1 from family traffic-engineering user@R1# set policy-statement nlri2bgp term 1 then accept
Results
From configuration mode, confirm your configuration by entering the
show interfaces, show routing-options,
show protocols, and show
policy-options commands. If the output does not display the
intended configuration, repeat the instructions in this example to correct
the configuration.
user@R1# show interfaces
ge-0/0/0 {
unit 0 {
family inet {
address 10.8.31.103/24;
}
family iso;
family mpls;
}
}
ge-0/0/1 {
unit 0 {
family inet {
address 10.8.42.102/24;
}
family iso;
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 10.255.105.141/32;
family iso {
address 47.0005.0102.5501.8181:00;
}
}
}
user@R1# show routing-options router-id 10.255.105.141; autonomous-system 65533;
user@R1# show protocols
rsvp {
interface all;
interface fxp0.0 {
disable;
}
}
mpls {
interface all;
interface fxp0.0 {
disable;
}
}
bgp {
group ibgp {
type internal;
local-address 10.255.105.141;
family traffic-engineering {
unicast;
}
export nlri2bgp;
neighbor 10.255.105.137;
}
group ebgp {
type external;
family traffic-engineering {
unicast;
}
neighbor 10.8.42.104 {
local-address 10.8.42.102;
peer-as 65534;
}
}
}
isis {
interface ge-0/0/1.0 {
passive {
remote-node-iso 0102.5502.4211;
remote-node-id 10.8.42.104;
}
}
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface lo0.0;
interface ge-0/0/0.0;
interface ge-0/0/1.0 {
passive {
traffic-engineering {
remote-node-id 10.8.42.104;
remote-node-router-id 10.255.105.139;
}
}
}
}
}
user@R1# show policy-options
policy-statement accept-all {
from family traffic-engineering;
then accept;
}
policy-statement nlri2bgp {
term 1 {
from family traffic-engineering;
then {
accept;
}
}
}
Procedure
Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode.
To configure Router R2:
-
Configure the Router R2 interfaces.
[edit interfaces] user@R2# set ge-0/0/0 unit 0 family inet address 10.8.64.104/24 user@R2# set ge-0/0/0 unit 0 family iso user@R2# set ge-0/0/0 unit 0 family mpls user@R2# set ge-0/0/1 unit 0 family inet address 10.8.42.104/24 user@R2# set ge-0/0/1 unit 0 family iso user@R2# set ge-0/0/1 unit 0 family mpls user@R2# set lo0 unit 0 family inet address 10.255.105.139/32 user@R2# set lo0 unit 0 family iso address 47.0005.0102.5502.4211.00
-
Configure the router ID and autonomous system of Router R2.
[edit routing-options]user@R2# set router-id 10.255.105.139 user@R2# set autonomous-system 65534 -
Enable RSVP on all the interfaces of Router R2 (excluding the management interface).
[edit routing-options]user@R2# set rsvp interface all user@R2# set rsvp interface fxp0.0 disable -
Enable MPLS on all the interfaces of Router R2 (excluding the management interface).
[edit routing-options]user@R2# set mpls interface all user@R2# set mpls interface fxp0.0 disable -
Enable import of traffic engineering database parameters using the ted2nlri policy.
[edit protocols]user@R2# set mpls traffic-engineering database import policy ted2nlri -
Configure the BGP group for Router R2 to peer with Router R3, and assign the local address and neighbor address.
[edit protocols]user@R2# set bgp group ibgp type internal user@R2# set bgp group ibgp local-address 10.255.105.139 user@R2# set bgp group ibgp neighbor 10.255.105.135 -
Include the BGP-TE signaling network layer reachability information (NLRI) to the ibgp BGP group.
[edit protocols]user@R2# set bgp group ibgp family traffic-engineering unicast -
Enable export of policy nlri2bgp on Router R2.
[edit protocols]user@R2# set bgp group ibgp export nlri2bgp -
Configure the BGP group for Router R2 to peer with Router R1.
[edit protocols]user@R2# set bgp group ebgp type external -
Include the BGP-TE signaling NLRI to the ebgp BGP group.
[edit protocols]user@R2# set bgp group ebgp family traffic-engineering unicast -
Assign the local address and neighbor autonomous system to the ebgp BGP group.
[edit protocols]user@R2# set bgp group ebgp peer-as 65533 user@R2# set bgp group ebgp neighbor 10.8.42.102 -
Enable export of policy nlri2bgp on Router R2.
[edit protocols]user@R2# set bgp group ebgp export nlri2bgp -
Enable IS-IS on the interface connecting Router R2 with Router R3 and the loopback interface of Router R2.
[edit protocols]user@R2# set isis level 1 disable user@R2# set isis interface ge-0/0/0.0 user@R2# set isis interface lo0.0 -
Enable only IS-IS advertising on the interface connecting Router R2 with Router R1.
[edit protocols]user@R2# set isis interface ge-0/0/1.0 passive remote-node-iso 0102.5501.8181 user@R2# set isis interface ge-0/0/1.0 passive remote-node-id 10.8.42.102 -
Configure traffic engineering capability on Router R2.
[edit protocols]user@R2# set ospf traffic-engineering -
Enable only OSPF advertisements on the interface connecting Router R2 with Router R1.
[edit protocols]user@R2# set ospf area 0.0.0.0 interface ge-0/0/1.0 passive traffic-engineering remote-node-id 10.8.42.102 user@R2# set ospf area 0.0.0.0 interface ge-0/0/1.0 passive traffic-engineering remote-node-router-id 10.255.105.141 -
Configure policies to accept traffic from the BGP-TE NLRI.
[edit policy-options]user@R2# set policy-statement accept-all from family traffic-engineering user@R2# set policy-statement accept-all then accept user@R2# set policy-statement nlri2bgp term 1 from family traffic-engineering user@R2# set policy-statement nlri2bgp term 1 then accept user@R2# set policy-statement ted2nlri term 1 from protocol isis user@R2# set policy-statement ted2nlri term 1 from protocol ospf user@R2# set policy-statement ted2nlri term 1 then accept user@R2# set policy-statement ted2nlri term 2 then reject
Results
From configuration mode, confirm your configuration by entering the
show interfaces, show routing-options,
show protocols, and show
policy-options commands. If the output does not display the
intended configuration, repeat the instructions in this example to correct
the configuration.
user@R2# show interfaces
ge-0/0/0 {
unit 0 {
family inet {
address 10.8.64.104/24;
}
family iso;
family mpls;
}
}
ge-0/0/1 {
unit 0 {
family inet {
address 10.8.42.104/24;
}
family iso;
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 10.255.105.139/32;
family iso {
address 47.0005.0102.5502.4211.00;
}
family iso;
}
}
user@R2# show routing-options router-id 10.255.105.139; autonomous-system 65534;
user@R2# show protocols
rsvp {
interface all;
interface fxp0.0 {
disable;
}
}
mpls {
traffic-engineering {
database {
import {
policy ted2nlri;
}
}
}
interface all;
interface fxp0.0 {
disable;
}
}
bgp {
group ibgp {
type internal;
local-address 10.255.105.139;
family traffic-engineering {
unicast;
}
export nlri2bgp;
neighbor 10.255.105.135;
}
group ebgp {
type external;
family traffic-engineering {
unicast;
}
export nlri2bgp;
peer-as 65533;
neighbor 10.8.42.102;
}
}
isis {
level 1 disable;
interface ge-0/0/0.0;
interface ge-0/0/1.0 {
passive {
remote-node-iso 0102.5501.8181;
remote-node-id 10.8.42.102;
}
}
interface lo0.0;
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface ge-0/0/1.0 {
passive {
traffic-engineering {
remote-node-id 10.8.42.102;
remote-node-router-id 10.255.105.141;
}
}
}
}
}
user@R2# show policy-options
policy-statement accept-all {
from family traffic-engineering;
then accept;
}
policy-statement nlri2bgp {
term 1 {
from family traffic-engineering;
then {
accept;
}
}
}
policy-statement ted2nlri {
term 1 {
from protocol [ isis ospf ];
then accept;
}
term 2 {
then reject;
}
}
Verification
Verify that the configuration is working properly.
- Verifying the BGP Summary Status
- Verifying the MPLS LSP Status
- Verifying the lsdist.0 Routing Table Entries
- Verifying the Traffic Engineering Database Entries
Verifying the BGP Summary Status
Purpose
Verify that BGP is up and running on Routers R0 and R1.
Action
From operational mode, run the show bgp summary command.
user@R0> show bgp summary
Groups: 1 Peers: 1 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
lsdist.0
10 10 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
10.255.105.141 65533 20 14 0 79 5:18 Establ
lsdist.0: 10/10/10/0From operational mode, run the show bgp summary command.
user@R1> show bgp summary
Groups: 2 Peers: 2 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
lsdist.0
10 10 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
10.8.42.104 65534 24 17 0 70 6:43 Establ
lsdist.0: 10/10/10/0
10.255.105.137 65533 15 23 0 79 6:19 Establ
lsdist.0: 0/0/0/0Meaning
Router R0 is peered with Router R1.
Verifying the MPLS LSP Status
Purpose
Verify the status of the MPLS LSP on Router R0.
Action
From operational mode, run the show mpls lsp command.
user@R0> show mpls lsp Ingress LSP: 1 sessions To From State Rt P ActivePath LSPname 10.255.105.135 10.255.105.137 Up 0 * to-R3-inter-as Total 1 displayed, Up 1, Down 0 Egress LSP: 0 sessions Total 0 displayed, Up 0, Down 0 Transit LSP: 0 sessions Total 0 displayed, Up 0, Down 0
Meaning
The MPLS LSP from Router R0 to Router R3 is established.
Verifying the lsdist.0 Routing Table Entries
Purpose
Verify the lsdist.0 routing table entries on Routers R0, R1, and R2.
Action
From operational mode, run the show route table lsdist.0
command.
user@R0> show route table lsdist.0
lsdist.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
NODE { AS:65534 ISO:0102.5502.4211.00 ISIS-L2:0 }/1152
*[BGP/170] 00:17:32, localpref 100, from 10.255.105.141
AS path: 65534 I, validation-state: unverified
> to 10.8.31.103 via ge-0/0/0.0
NODE { AS:65534 ISO:0102.5502.4250.00 ISIS-L2:0 }/1152
*[BGP/170] 00:17:32, localpref 100, from 10.255.105.141
AS path: 65534 I, validation-state: unverified
> to 10.8.31.103 via ge-0/0/0.0
NODE { AS:65534 ISO:0102.5502.4250.02 ISIS-L2:0 }/1152
*[BGP/170] 00:17:32, localpref 100, from 10.255.105.141
AS path: 65534 I, validation-state: unverified
> to 10.8.31.103 via ge-0/0/0.0
NODE { AS:65534 Area:0.0.0.0 IPv4:10.255.105.139 OSPF:0 }/1152
*[BGP/170] 00:17:32, localpref 100, from 10.255.105.141
AS path: 65534 I, validation-state: unverified
> to 10.8.31.103 via ge-0/0/0.0
LINK { Local { AS:65534 ISO:0102.5502.4211.00 }.{ IPv4:8.42.1.104 } Remote { AS:65534 ISO:0102.5501.8181.00 }.{ IPv4:10.8.42.102 } ISIS-L2:0 }/1152
*[BGP/170] 00:17:32, localpref 100, from 10.255.105.141
AS path: 65534 I, validation-state: unverified
> to 10.8.31.103 via ge-0/0/0.0
LINK { Local { AS:65534 ISO:0102.5502.4211.00 }.{ IPv4:10.8.64.104 } Remote { AS:65534 ISO:0102.5502.4250.02 }.{ } ISIS-L2:0 }/1152
*[BGP/170] 00:02:03, localpref 100, from 10.255.105.141
AS path: 65534 I, validation-state: unverified
> to 10.8.31.103 via ge-0/0/0.0
LINK { Local { AS:65534 ISO:0102.5502.4250.00 }.{ IPv4:10.8.64.106 } Remote { AS:65534 ISO:0102.5502.4250.02 }.{ } ISIS-L2:0 }/1152
*[BGP/170] 00:17:32, localpref 100, from 10.255.105.141
AS path: 65534 I, validation-state: unverified
> to 10.8.31.103 via ge-0/0/0.0
LINK { Local { AS:65534 ISO:0102.5502.4250.02 }.{ } Remote { AS:65534 ISO:0102.5502.4211.00 }.{ } ISIS-L2:0 }/1152
*[BGP/170] 00:17:32, localpref 100, from 10.255.105.141
AS path: 65534 I, validation-state: unverified
> to 10.8.31.103 via ge-0/0/0.0
LINK { Local { AS:65534 ISO:0102.5502.4250.02 }.{ } Remote { AS:65534 ISO:0102.5502.4250.00 }.{ } ISIS-L2:0 }/1152
*[BGP/170] 00:17:32, localpref 100, from 10.255.105.141
AS path: 65534 I, validation-state: unverified
> to 10.8.31.103 via ge-0/0/0.0
LINK { Local { AS:65534 Area:0.0.0.0 IPv4:10.255.105.139 }.{ IPv4:10. 8.42.104 } Remote { AS:65534 Area:0.0.0.0 IPv4:10.255.105.141 }.{ IPv4:10.8.42.102 } OSPF:0 }/1152
*[BGP/170] 00:17:32, localpref 100, from 10.255.105.141
AS path: 65534 I, validation-state: unverified
> to 10.8.31.103 via ge-0/0/0.0From operational mode, run the show route table lsdist.0
command.
user@R1> show route table lsdist.0
lsdist.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
NODE { AS:65534 ISO:0102.5502.4211.00 ISIS-L2:0 }/1152
*[BGP/170] 00:18:00, localpref 100
AS path: 65534 I, validation-state: unverified
> to 10.8.42.104 via ge-0/0/1.0
NODE { AS:65534 ISO:0102.5502.4250.00 ISIS-L2:0 }/1152
*[BGP/170] 00:18:00, localpref 100
AS path: 65534 I, validation-state: unverified
> to 10.8.42.104 via ge-0/0/1.0
NODE { AS:65534 ISO:0102.5502.4250.02 ISIS-L2:0 }/1152
*[BGP/170] 00:18:00, localpref 100
AS path: 65534 I, validation-state: unverified
> to 10.8.42.104 via ge-0/0/1.0
NODE { AS:65534 Area:0.0.0.0 IPv4:10.255.105.139 OSPF:0 }/1152
*[BGP/170] 00:18:00, localpref 100
AS path: 65534 I, validation-state: unverified
> to 10.8.42.104 via ge-0/0/1.0
LINK { Local { AS:65534 ISO:0102.5502.4211.00 }.{ IPv4:10.8.42.104 } Remote { AS:65534 ISO:0102.5501.8181.00 }.{ IPv4:10.8.42.102 } ISIS-L2:0 }/1152
*[BGP/170] 00:18:00, localpref 100
AS path: 65534 I, validation-state: unverified
> to 10.8.42.104 via ge-0/0/1.0
LINK { Local { AS:65534 ISO:0102.5502.4211.00 }.{ IPv4:10.8.64.104 } Remote { AS:65534 ISO:0102.5502.4250.02 }.{ } ISIS-L2:0 }/1152
*[BGP/170] 00:02:19, localpref 100
AS path: 65534 I, validation-state: unverified
> to 10.8.42.104 via ge-0/0/1.0
LINK { Local { AS:65534 ISO:0102.5502.4250.00 }.{ IPv4:10.8.64.106 } Remote { AS:65534 ISO:0102.5502.4250.02 }.{ } ISIS-L2:0 }/1152
*[BGP/170] 00:18:00, localpref 100
AS path: 65534 I, validation-state: unverified
> to 10.8.42.104 via ge-0/0/1.0
LINK { Local { AS:65534 ISO:0102.5502.4250.02 }.{ } Remote { AS:65534 ISO:0102.5502.4211.00 }.{ } ISIS-L2:0 }/1152
*[BGP/170] 00:18:00, localpref 100
AS path: 65534 I, validation-state: unverified
> to 10.8.42.104 via ge-0/0/1.0
LINK { Local { AS:65534 ISO:0102.5502.4250.02 }.{ } Remote { AS:65534 ISO:0102.5502.4250.00 }.{ } ISIS-L2:0 }/1152
*[BGP/170] 00:18:00, localpref 100
AS path: 65534 I, validation-state: unverified
> to 10.8.42.104 via ge-0/0/1.0
LINK { Local { AS:65534 Area:0.0.0.0 IPv4:10.255.105.139 }.{ IPv4:10.8.42.104 } Remote { AS:65534 Area:0.0.0.0 IPv4:10.255.105.141 }.{ IPv4:10.8.42.102 } OSPF:0 }/1152
*[BGP/170] 00:18:00, localpref 100
AS path: 65534 I, validation-state: unverified
> to 10.8.42.104 via ge-0/0/1.0From operational mode, run the show route table lsdist.0
command.
user@R2> show route table lsdist.0
lsdist.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
NODE { AS:65534 ISO:0102.5502.4211.00 ISIS-L2:0 }/1152
*[IS-IS/18] 1d 00:24:39
Fictitious
NODE { AS:65534 ISO:0102.5502.4250.00 ISIS-L2:0 }/1152
*[IS-IS/18] 00:20:45
Fictitious
NODE { AS:65534 ISO:0102.5502.4250.02 ISIS-L2:0 }/1152
*[IS-IS/18] 00:20:45
Fictitious
NODE { AS:65534 Area:0.0.0.0 IPv4:10.255.105.139 OSPF:0 }/1152
*[OSPF/10] 1d 00:24:39
Fictitious
LINK { Local { AS:65534 ISO:0102.5502.4211.00 }.{ IPv4:10.8.42.104 } Remote { AS:65534 ISO:0102.5501.8181.00 }.{ IPv4:10.8.42.102 } ISIS-L2:0 }/1152
*[IS-IS/18] 00:20:58
Fictitious
LINK { Local { AS:65534 ISO:0102.5502.4211.00 }.{ IPv4:10.8.64.104 } Remote { AS:65534 ISO:0102.5502.4250.02 }.{ } ISIS-L2:0 }/1152
*[IS-IS/18] 00:02:34
Fictitious
LINK { Local { AS:65534 ISO:0102.5502.4250.00 }.{ IPv4:10.8.64.106 } Remote { AS:65534 ISO:0102.5502.4250.02 }.{ } ISIS-L2:0 }/1152
*[IS-IS/18] 00:20:45
Fictitious
LINK { Local { AS:65534 ISO:0102.5502.4250.02 }.{ } Remote { AS:65534 ISO:0102.5502.4211.00 }.{ } ISIS-L2:0 }/1152
*[IS-IS/18] 00:20:45
Fictitious
LINK { Local { AS:65534 ISO:0102.5502.4250.02 }.{ } Remote { AS:65534 ISO:0102.5502.4250.00 }.{ } ISIS-L2:0 }/1152
*[IS-IS/18] 00:20:45
Fictitious
LINK { Local { AS:65534 Area:0.0.0.0 IPv4:10.255.105.139 }.{ IPv4:10.8.42.104 } Remote { AS:65534 Area:0.0.0.0 IPv4:10.255.105.141 }.{ IPv4:10.8.42.102 } OSPF:0 }/1152
*[OSPF/10] 00:20:57
FictitiousMeaning
The routes are appearing in the lsdist.0 routing table.
Verifying the Traffic Engineering Database Entries
Purpose
Verify the traffic engineering database entries on Router R0.
Action
From operational mode, run the show ted database
command.
user@R0> show ted database
TED database: 5 ISIS nodes 5 INET nodes
ID Type Age(s) LnkIn LnkOut Protocol
0102.5501.8168.00(10.255.105.137) Rtr 1046 1 1 OSPF(0.0.0.0)
To: 10.8.31.101-1, Local: 10.8.31.101, Remote: 0.0.0.0
Local interface index: 0, Remote interface index: 0
ID Type Age(s) LnkIn LnkOut Protocol
0102.5501.8181.00 --- 1033 1 0
0102.5502.4211.00(10.255.105.139) Rtr 3519 2 3 Exported ISIS-L2(1)
To: 0102.5502.4250.02, Local: 10.8.64.104, Remote: 0.0.0.0
Local interface index: 0, Remote interface index: 0
To: 0102.5501.8181.00, Local: 10.8.42.104, Remote: 10.8.42.102
Local interface index: 0, Remote interface index: 0
ID Type Age(s) LnkIn LnkOut Protocol
Exported OSPF(2)
To: 10.255.105.141, Local: 10.8.42.104, Remote: 10.8.42.102
Local interface index: 0, Remote interface index: 0
ID Type Age(s) LnkIn LnkOut Protocol
0102.5502.4250.00(10.255.105.135) Rtr 1033 1 1 Exported ISIS-L2(1)
To: 0102.5502.4250.02, Local: 10.8.64.106, Remote: 0.0.0.0
Local interface index: 0, Remote interface index: 0
ID Type Age(s) LnkIn LnkOut Protocol
0102.5502.4250.02 Net 1033 2 2 Exported ISIS-L2(1)
To: 0102.5502.4211.00(10.255.105.139), Local: 0.0.0.0, Remote: 0.0.0.0
Local interface index: 0, Remote interface index: 0
To: 0102.5502.4250.00(10.255.105.135), Local: 0.0.0.0, Remote: 0.0.0.0
Local interface index: 0, Remote interface index: 0
ID Type Age(s) LnkIn LnkOut Protocol
10.8.31.101-1 Net 1046 2 2 OSPF(0.0.0.0)
To: 0102.5501.8168.00(10.255.105.137), Local: 0.0.0.0, Remote: 0.0.0.0
Local interface index: 0, Remote interface index: 0
To: 10.255.105.141, Local: 0.0.0.0, Remote: 0.0.0.0
Local interface index: 0, Remote interface index: 0
ID Type Age(s) LnkIn LnkOut Protocol
10.255.105.141 Rtr 1045 2 2 OSPF(0.0.0.0)
To: 0102.5502.4211.00(10.255.105.139), Local: 10.8.42.102, Remote: 10.8.42.104
Local interface index: 0, Remote interface index: 0
To: 10.8.31.101-1, Local: 10.8.31.103, Remote: 0.0.0.0
Local interface index: 0, Remote interface index: 0Meaning
The routes are appearing in the traffic engineering database.
Configuring Link State Distribution Using BGP
You can enable distribution of topology information across multiple areas and autonomous systems (ASs) by extending the BGP protocol to carry link-state information, which was initially acquired using IGP. The IGP protocols have scaling limitations when it comes to distributing large databases. BGP is not only a more scalable vehicle for carrying multi-area and multi-AS topology information, but also provides the policy controls that can be useful for multi-AS topology distribution. The BGP link-state topology information is used for computing paths for MPLS LSPs spanning multiple domains, such as inter-area TE LSP, and providing a scalable and policy-controlled means for external path computing entities, such as ALTO and PCE, to acquire network topology.
Before you begin:
Configure the device interfaces.
Configure the router ID and autonomous system number for the device.
Configure the following protocols:
RSVP
MPLS
IS-IS
OSPF
To enable link-state distribution using BGP:
Link-State Distribution using SRv6
BGP Link-State Extensions for SRv6
Starting in Junos OS Release 21.3R1, we support SRv6 in BGP-LS and Traffic Engineering Database (TED). BGP-LS extensions export the SRv6 topology information to the SDN controllers. Controllers receive the topology information by being part of an IGP domain or through BGP-LS. BGP LS provides a scalable mechanism to export the topology information. It can also be used for the Inter-domain networks. Also, you can now filter NLRI based on IPv6 prefix (SRv6 Locator) and SRv6 SID NLRI.
Flow of BGP Link-State SRv6 Data
BGP LS retrieves the Traffic Engineering (TE) data from the TE Database (TED) and distributes it to the peer BGP Speakers. For this, TED converts its links, nodes and prefixes (IPv4 and IPv6) entries in the form of routes. The following figure shows the data flow in BGP-LS.
-
SRv6 attributes exchanged via ISIS IGP are now supported in Junos as described in IETF standard [3].
-
SRv6 attributes are added into the Traffic Engineering Database (TED).
-
SRv6 attributes learned via ISIS IGP are stored in TED as nodes and links are converted to routes. These routes are then subjected to TED import policy and if the policy permits, these are installed in a routing table called lsdist.0.
-
BGP can be configured to “export” or advertise routes from lsdist.0 table subject to policy. BGP then propagates these routes like any other NLRI. That is, peers that have BGP-LS family configured and negotiated receives BGP-LS NLRI’s. BGP stores the received BGP-LS NLRIs in the form of routes in “lsdist.0” table, which is the same table that stores locally originated BGP-LS routes. The newly added SRv6 information gets propagated into BGP as attributes of already existing NLRIs (Node, Link and Prefix) and a new SRv6 Locator NLRI.
-
The received BGP-LS NLRIs which are installed in the form of routes in “lsdist.0” table can be subjected to TED export policy and if the policy permits, SRv6 attributes from these routes are added into the local instance of TE Database.
IPv6 Prefixes and IPv6 Adjacency SIDs MPLS Support in Traffic Engineering Database and BGP Link-State
We have made the following IPv6 enhancements.
- Support for adding the IPv6 attributes and information to traffic engineering database (TED) from Intermediate System to Intermediate System (IS-IS).
- Support for IPv6 attributes import from traffic engineering database to lsdist.0 routing table.
- Support for IPv6 attributes export to BGP Link-State (BGP-LS).
- Support for BGP-LS IPv6 Network Layer Reachability Information (NLRIs) and attributes export from lsdist.0 routing table to traffic engineering database.
We support only the IS-IS interior gateway protocol (IGP).
- Benefits of IPv6 Prefixes and IPv6 Adjacency SID MPLS Support in Traffic Engineering Database and BGP-LS
- Implementation
- Support for Adding the IPv6 Attributes and Information to Traffic Engineering Database from IS-IS
- Support for IPv6 Attributes Import from Traffic Engineering Database to lsdist.0 Routing Table
- Support for IPv6 Attributes Export to BGP-LS
- Support for BGP-LS IPv6 NLRIs and Attributes Export from lsdist.0 Routing Table to Traffic Engineering Database
- Configuration Command
Benefits of IPv6 Prefixes and IPv6 Adjacency SID MPLS Support in Traffic Engineering Database and BGP-LS
We've enhanced the outputs of the existing operational commands and added the show commands to display the list of IPv6 and IPv4 prefixes, respectively, in the traffic engineering database.
show ted database extensive—Enhanced the output to include the IPv6 segment routing (SR)-MPLS attributes.show ted link detail—Enhanced the output to include the IPv6 SR-MPLS attributes corresponding to the traffic engineering database links.show route table lsdist.0 [extensive | detail]—Enhanced the output to include IPv6 NLRIs and IPv6 SR-MPLS attributes.show route—Included additional parameters to filter entries for viewing in the lsdist.0 table. We've added additional options to include IPv6 prefixes. The options arete-ipv6-prefix-ipv6-addrandte-ipv6-prefix-node-iso.show ted ipv6-prefix—Added the show command to display the list of IPv6 prefixes in traffic engineering database.show ted ipv4-prefix—Added the show command to display the list of IPv4 prefixes in traffic engineering database.
Implementation
BGP-LS retrieves the Traffic Engineering (TE) data from the traffic engineering database and distributes the data to its BGP peers. To achieve this, traffic engineering database converts its links, nodes, and prefix (IPv4 and IPv6) entries in the form of routes. The following figure depicts the flow of information from BGP-LS and towards BGP-LS.
Support for Adding the IPv6 Attributes and Information to Traffic Engineering Database from IS-IS
Junos OS supports SR-MPLS attributes for IPv6 data plane, exchanged through IS-IS IGP. As a result of this enhancement, IPv6 attributes and information can be added to the Traffic Engineering Database (TED).
Support for IPv6 Attributes Import from Traffic Engineering Database to lsdist.0 Routing Table
IPv6 attributes received from IS-IS IGP and stored in traffic engineering database as nodes, links, and prefixes are converted to routes. These routes are then subjected to the traffic engineering database import policy. If the policy permits, the routes are installed in a routing table called lsdist.0.
Support for IPv6 Attributes Export to BGP-LS
BGP is configured to export or advertise routes from lsdist.0 table, subject to the policy. It is a routine scenario for any route origination in BGP. BGP then propagates these routes like any other NLRI to the peers with BGP-LS configured and established BGP neighborship. BGP stores the received BGP-LS NLRIs in the form of routes in the lsdist.0 table, which is the same table that stores locally originated BGP-LS routes. As a result of this functionality, newly added IPv6 information is propagated to BGP as attributes of already existing Link NLRI, and as a new IPv6 Prefix NLRI.
Support for BGP-LS IPv6 NLRIs and Attributes Export from lsdist.0 Routing Table to Traffic Engineering Database
In Junos OS, the received BGP-LS NLRIs installed in the form of routes in the lsdist.0 table are subjected to the traffic engineering database export policy. If the policy permits, IPv6 attributes, and information from these routes are then added to the local instance of the traffic engineering database.
Configuration Command
BGP-TE policy command is enhanced to allow filtering of NLRIs based on IPv6 prefix NLRI. See ipv6-prefix.
See Also
Change History Table
Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.