Most common IGP protocols, OSPF and ISIS, are so-called link state protocols.
Link state protocols are designed so that all the nodes have the complete view of the network. In other words, each node sees the whole topology and, on that topology, builds shortest paths to different destinations.
Historically, we were told to be careful with link state protocols. Knowing the whole topology on every node is a coll thing but, at the same time, gives us scalability issues. The bigger the network, the bigger the link state database on the device. This was a real issue, let’s say, 20 years ago were boxes were not as powerful as today. For that reason, solutions like areas (NSSA, stub) and levels were invented. The golden rule was something like “do not make your IGP grow too much”.
Anyhow, that strict requirement is no longer true. Boxes are more powerful and can handle bigger link state databases.
Moreover, new trends and needs emerged. One of them is the possibility to provide advanced traffic engineering in order to build services able to guarantee certain SLAs.
As networks are interconnected, it is not out of mind to think of SLAs that span over multiple domains (Inter-AS). This means being able to have inter-as TE capabilities.
We have already seen something like this when we had a look at BGP-CT.
Here, we are going to see another solution.
Let’s think of RSVP. We want to create a LSP starting in AS200 with the egress node in AS100. Our router in AS200 needs to know about routes and topology coming from AS100. We need to extend the link state database to include info from other AS. We no longer want to “limit” the link state; we want to expand it with data from another domain.
This is accomplished, once again, via BGP, through its flavor called BGP-LS (Link State).
What we want to build is the following:
Through BGP-LS we are going to exchange link state routing info between ASs. Our ultimate goal is to create a RSVP LSP from 200.1.1.1 (r1b) to 100.1.1.1 (r1a).
We said we are going to extend the link state database. This might sound like importing remote routes into the local IGP. That is not true. Data from the other AS will be imported and installed within the TED: Traffic Engineering Database. TED is the entity used by default (unless no-cspf is configured) by RSVP to build LSPs.
In this solution, IGP, TED and BGP-LS will all work together to make things work.
This image shows the different interactions:
Let’s understand how this works:
- IGP has its own routing table and routes typically end up in inet.0
- if TE is enabled, IG topology is “downloaded” into the TED
- as said, TED is a special database used to build TE-oriented paths
- inside TED we have all the nodes and links connecting them, along with additional TE attributes like bandwidth or admin-groups
- TED data can be exported towards BGP by configuring an import policy on the TED db
- this might sound confusing but we have to think of TED import/export policies from the BGP perspective
- BGP-LS introduces a new routing table called lsdist.0
- TED db export policy means “export data from lsdist.0 to TED”
- at the same time, TED db import policy means “import data from TED to lsdist.0”
- IGP data is downloaded to TED and, from there, via a TED import policy is copied into lsdist.0 and made available to BGP-LS
- similarly, remote LS data is received over BGP-LS and stored into lsdist.0
- from there, through a TED export policy, is downloaded to TED
- as a result, TED includes both local data and remote data
- RSVP could now build a LSP from one AS to another
Now things should be a bit more clear. We can jump into building our BGP-LS network.
AS 100 uses ISIS L2 only. Configuration is standard. I’m going to provide r4a (border router) config only:
set protocols isis interface ge-0/0/0.0 level 1 disable
set protocols isis interface ge-0/0/0.0 point-to-point
set protocols isis interface ge-0/0/1.0 level 1 disable
set protocols isis interface ge-0/0/1.0 point-to-point
set protocols isis interface ge-0/0/2.0 level 1 disable
set protocols isis interface ge-0/0/2.0 point-to-point
set protocols isis interface ge-0/0/2.0 passive remote-node-iso 0000.0000.0024
set protocols isis interface ge-0/0/2.0 passive remote-node-id 192.168.45.1
set protocols isis interface lo0.0No OSPF runs in AS 100.
AS 200, instead, uses OSPF area 0. Here is config for r4b (border router) only:
set protocols ospf traffic-engineering
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 interface-type p2p
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 interface-type p2p
set protocols ospf area 0.0.0.0 interface lo0.0 passive
set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 interface-type p2p
set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 passive traffic-engineering remote-node-id 192.168.45.0
set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 passive traffic-engineering remote-node-router-id 100.4.4.4Unlike ISIS, we need to explicitly enable TE, otherwise IGP will not be downloaded into TED.
No ISIS runs in AS 200.
Now we deal with TED db.
On both ASs we configure:
set protocols mpls traffic-engineering database import policy ted-to-bgp
set protocols mpls traffic-engineering database import bgp-ls-identifier <N>
set protocols mpls traffic-engineering database export policy bgp-to-tedWhere N is just an identifier. We choose 100 for AS 100 and 200 for AS 200.
Import policy differs as the two ASs use different IGPs:
r4b (AS200)
set policy-options policy-statement ted-to-bgp term ok from protocol ospf
set policy-options policy-statement ted-to-bgp term ok then accept
set policy-options policy-statement ted-to-bgp then reject
r4a (AS100)
set policy-options policy-statement ted-to-bgp term ok from protocol isis
set policy-options policy-statement ted-to-bgp term ok then accept
set policy-options policy-statement ted-to-bgp then rejectExport policy, instead, is identical on both border routers:
set policy-options policy-statement bgp-to-ted term ok from family traffic-engineering
set policy-options policy-statement bgp-to-ted term ok then acceptFamily traffic-engineering is a new BGP family we are seeing for the first time. It is the family associated with BGP-LS.
Let’s configure BGP-LS:
set protocols bgp group bgp-ls type external
set protocols bgp group bgp-ls family traffic-engineering unicast
set protocols bgp group bgp-ls export exp-bg-te
set protocols bgp group bgp-ls peer-as 100
set protocols bgp group bgp-ls neighbor 192.168.45.0That was r4b. Router r4a is identical, apart from neighbor IP.
Export policy look like this:
set policy-options policy-statement exp-bgp-ls term ok from family traffic-engineering
set policy-options policy-statement exp-bgp-ls term ok then accept
set policy-options policy-statement exp-bgp-ls then rejectRoutes are exported from lsdist.0 routing table.
We also have iBGP inside each AS. This is on r4b towards r1b:
set protocols bgp group ibgp-ls type internal
set protocols bgp group ibgp-ls local-address 200.4.4.4
set protocols bgp group ibgp-ls family traffic-engineering unicast
set protocols bgp group ibgp-ls neighbor 200.1.1.1iBGP is needed so that
- r4b (AS 200) learns LS data from r4a (AS100)
- that data is advertised via iBGP to r1b
- this way r1a has both local and remote data
Notice, there is nothing to do about local data at r1b. As both r4b and r1b are part of the same IGP domain, they share the same local data being OSPF/ISIS link state protocols. The only purpose of iBGP is to bring LS routes from border routers (r4b and r4a) to other PE nodes within their AS.
For this reason, on r1a and r1b there is no need to have a BGP-LS export policy. Having it would mean exporting local TED dta (like we do at border routers) but it is useless to create such NLRIs as all the other routers within the AS already have that info. It is enough to have just one router to export local TED data to BGP-LS and it makes sense that router to be the border router, the one responsible for advertising local AS LS routes to remote ASs.
On r4b, we check lsdist.0 gets populated by both AS100 and AS200 routes:
root@r4b# run show route table lsdist.0 brief | match AS:100
NODE { AS:100 BGP-LS ID:100 ISO:0000.0000.0014.00 ISIS-L1:0 }/1216
NODE { AS:100 BGP-LS ID:100 ISO:0000.0000.0011.00 ISIS-L2:0 }/1216
NODE { AS:100 BGP-LS ID:100 ISO:0000.0000.0012.00 ISIS-L2:0 }/1216
NODE { AS:100 BGP-LS ID:100 ISO:0000.0000.0013.00 ISIS-L2:0 }/1216
NODE { AS:100 BGP-LS ID:100 ISO:0000.0000.0014.00 ISIS-L2:0 }/1216
LINK { Local { AS:100 BGP-LS ID:100 ISO:0000.0000.0011.00 }.{ IPv4:192.168.12.0 } Remote { AS:100 BGP-LS ID:100 ISO:0000.0000.0012.00 }.{ IPv4:192.168.12.1 } ISIS-L2:0 }/1216
LINK { Local { AS:100 BGP-LS ID:100 ISO:0000.0000.0011.00 }.{ IPv4:192.168.13.0 } Remote { AS:100 BGP-LS ID:100 ISO:0000.0000.0013.00 }.{ IPv4:192.168.13.1 } ISIS-L2:0 }/1216
LINK { Local { AS:100 BGP-LS ID:100 ISO:0000.0000.0012.00 }.{ IPv4:192.168.12.1 } Remote { AS:100 BGP-LS ID:100 ISO:0000.0000.0011.00 }.{ IPv4:192.168.12.0 } ISIS-L2:0 }/1216
LINK { Local { AS:100 BGP-LS ID:100 ISO:0000.0000.0012.00 }.{ IPv4:192.168.23.0 } Remote { AS:100 BGP-LS ID:100 ISO:0000.0000.0013.00 }.{ IPv4:192.168.23.1 } ISIS-L2:0 }/1216
LINK { Local { AS:100 BGP-LS ID:100 ISO:0000.0000.0012.00 }.{ IPv4:192.168.24.0 } Remote { AS:100 BGP-LS ID:100 ISO:0000.0000.0014.00 }.{ IPv4:192.168.24.1 } ISIS-L2:0 }/1216
LINK { Local { AS:100 BGP-LS ID:100 ISO:0000.0000.0013.00 }.{ IPv4:192.168.13.1 } Remote { AS:100 BGP-LS ID:100 ISO:0000.0000.0011.00 }.{ IPv4:192.168.13.0 } ISIS-L2:0 }/1216
LINK { Local { AS:100 BGP-LS ID:100 ISO:0000.0000.0013.00 }.{ IPv4:192.168.23.1 } Remote { AS:100 BGP-LS ID:100 ISO:0000.0000.0012.00 }.{ IPv4:192.168.23.0 } ISIS-L2:0 }/1216
LINK { Local { AS:100 BGP-LS ID:100 ISO:0000.0000.0013.00 }.{ IPv4:192.168.34.0 } Remote { AS:100 BGP-LS ID:100 ISO:0000.0000.0014.00 }.{ IPv4:192.168.34.1 } ISIS-L2:0 }/1216
LINK { Local { AS:100 BGP-LS ID:100 ISO:0000.0000.0014.00 }.{ IPv4:192.168.24.1 } Remote { AS:100 BGP-LS ID:100 ISO:0000.0000.0012.00 }.{ IPv4:192.168.24.0 } ISIS-L2:0 }/1216
LINK { Local { AS:100 BGP-LS ID:100 ISO:0000.0000.0014.00 }.{ IPv4:192.168.34.1 } Remote { AS:100 BGP-LS ID:100 ISO:0000.0000.0013.00 }.{ IPv4:192.168.34.0 } ISIS-L2:0 }/1216
LINK { Local { AS:100 BGP-LS ID:100 ISO:0000.0000.0014.00 }.{ IPv4:192.168.45.0 } Remote { AS:100 BGP-LS ID:100 ISO:0000.0000.0024.00 }.{ IPv4:192.168.45.1 } ISIS-L2:0 }/1216
PREFIX { Node { AS:100 BGP-LS ID:100 ISO:0000.0000.0014.00 } { IPv4:100.4.4.4/32 } ISIS-L1:0 }/1216
PREFIX { Node { AS:100 BGP-LS ID:100 ISO:0000.0000.0011.00 } { IPv4:100.1.1.1/32 } ISIS-L2:0 }/1216
PREFIX { Node { AS:100 BGP-LS ID:100 ISO:0000.0000.0012.00 } { IPv4:100.2.2.2/32 } ISIS-L2:0 }/1216
PREFIX { Node { AS:100 BGP-LS ID:100 ISO:0000.0000.0013.00 } { IPv4:100.3.3.3/32 } ISIS-L2:0 }/1216
PREFIX { Node { AS:100 BGP-LS ID:100 ISO:0000.0000.0014.00 } { IPv4:100.4.4.4/32 } ISIS-L2:0 }/1216
[edit]
root@r4b# run show route table lsdist.0 brief | match AS:200
NODE { AS:200 BGP-LS ID:200 Area:0.0.0.0 IPv4:200.1.1.1 OSPF:0 }/1216
NODE { AS:200 BGP-LS ID:200 Area:0.0.0.0 IPv4:200.2.2.2 OSPF:0 }/1216
NODE { AS:200 BGP-LS ID:200 Area:0.0.0.0 IPv4:200.3.3.3 OSPF:0 }/1216
NODE { AS:200 BGP-LS ID:200 Area:0.0.0.0 IPv4:200.4.4.4 OSPF:0 }/1216
LINK { Local { AS:200 BGP-LS ID:200 Area:0.0.0.0 IPv4:200.1.1.1 }.{ IPv4:192.168.112.0 } Remote { AS:200 BGP-LS ID:200 Area:0.0.0.0 IPv4:200.2.2.2 }.{ IPv4:192.168.112.1 } OSPF:0 }/1216
LINK { Local { AS:200 BGP-LS ID:200 Area:0.0.0.0 IPv4:200.1.1.1 }.{ IPv4:192.168.113.0 } Remote { AS:200 BGP-LS ID:200 Area:0.0.0.0 IPv4:200.3.3.3 }.{ IPv4:192.168.113.1 } OSPF:0 }/1216
LINK { Local { AS:200 BGP-LS ID:200 Area:0.0.0.0 IPv4:200.2.2.2 }.{ IPv4:192.168.112.1 } Remote { AS:200 BGP-LS ID:200 Area:0.0.0.0 IPv4:200.1.1.1 }.{ IPv4:192.168.112.0 } OSPF:0 }/1216
LINK { Local { AS:200 BGP-LS ID:200 Area:0.0.0.0 IPv4:200.2.2.2 }.{ IPv4:192.168.123.0 } Remote { AS:200 BGP-LS ID:200 Area:0.0.0.0 IPv4:200.3.3.3 }.{ IPv4:192.168.123.1 } OSPF:0 }/1216
LINK { Local { AS:200 BGP-LS ID:200 Area:0.0.0.0 IPv4:200.2.2.2 }.{ IPv4:192.168.124.0 } Remote { AS:200 BGP-LS ID:200 Area:0.0.0.0 IPv4:200.4.4.4 }.{ IPv4:192.168.124.1 } OSPF:0 }/1216
LINK { Local { AS:200 BGP-LS ID:200 Area:0.0.0.0 IPv4:200.3.3.3 }.{ IPv4:192.168.113.1 } Remote { AS:200 BGP-LS ID:200 Area:0.0.0.0 IPv4:200.1.1.1 }.{ IPv4:192.168.113.0 } OSPF:0 }/1216
LINK { Local { AS:200 BGP-LS ID:200 Area:0.0.0.0 IPv4:200.3.3.3 }.{ IPv4:192.168.123.1 } Remote { AS:200 BGP-LS ID:200 Area:0.0.0.0 IPv4:200.2.2.2 }.{ IPv4:192.168.123.0 } OSPF:0 }/1216
LINK { Local { AS:200 BGP-LS ID:200 Area:0.0.0.0 IPv4:200.3.3.3 }.{ IPv4:192.168.134.0 } Remote { AS:200 BGP-LS ID:200 Area:0.0.0.0 IPv4:200.4.4.4 }.{ IPv4:192.168.134.1 } OSPF:0 }/1216
LINK { Local { AS:200 BGP-LS ID:200 Area:0.0.0.0 IPv4:200.4.4.4 }.{ IPv4:192.168.45.1 } Remote { AS:200 BGP-LS ID:200 Area:0.0.0.0 IPv4:100.4.4.4 }.{ IPv4:192.168.45.0 } OSPF:0 }/1216
LINK { Local { AS:200 BGP-LS ID:200 Area:0.0.0.0 IPv4:200.4.4.4 }.{ IPv4:192.168.124.1 } Remote { AS:200 BGP-LS ID:200 Area:0.0.0.0 IPv4:200.2.2.2 }.{ IPv4:192.168.124.0 } OSPF:0 }/1216
LINK { Local { AS:200 BGP-LS ID:200 Area:0.0.0.0 IPv4:200.4.4.4 }.{ IPv4:192.168.134.1 } Remote { AS:200 BGP-LS ID:200 Area:0.0.0.0 IPv4:200.3.3.3 }.{ IPv4:192.168.134.0 } OSPF:0 }/1216Now, let’s have a closer look to TED. For simplicity we are going to look at links.
We are going to check this from r4b perspective.
When BGP-LS is up we see this:
root@r4b# run show ted link
ID ->ID LocalPath LocalBW
0000.0000.0011.00(100.1.1.1) 0000.0000.0012.00(100.2.2.2) 0 0bps
0000.0000.0011.00(100.1.1.1) 0000.0000.0013.00(100.3.3.3) 0 0bps
0000.0000.0012.00(100.2.2.2) 0000.0000.0014.00(100.4.4.4) 0 0bps
0000.0000.0012.00(100.2.2.2) 0000.0000.0011.00(100.1.1.1) 0 0bps
0000.0000.0012.00(100.2.2.2) 0000.0000.0013.00(100.3.3.3) 0 0bps
0000.0000.0013.00(100.3.3.3) 0000.0000.0014.00(100.4.4.4) 0 0bps
0000.0000.0013.00(100.3.3.3) 0000.0000.0011.00(100.1.1.1) 0 0bps
0000.0000.0013.00(100.3.3.3) 0000.0000.0012.00(100.2.2.2) 0 0bps
0000.0000.0014.00(100.4.4.4) 0000.0000.0024.00(200.4.4.4) 0 0bps
0000.0000.0014.00(100.4.4.4) 0000.0000.0012.00(100.2.2.2) 0 0bps
0000.0000.0014.00(100.4.4.4) 0000.0000.0013.00(100.3.3.3) 0 0bps
0000.0000.0024.00(200.4.4.4) 200.2.2.2 0 0bps
0000.0000.0024.00(200.4.4.4) 200.3.3.3 0 0bps
0000.0000.0024.00(200.4.4.4) 0000.0000.0014.00(100.4.4.4) 0 0bps
200.1.1.1 200.2.2.2 0 0bps
200.1.1.1 200.3.3.3 0 0bps
200.2.2.2 200.1.1.1 0 0bps
200.2.2.2 200.3.3.3 0 0bps
200.2.2.2 0000.0000.0024.00(200.4.4.4) 0 0bps
200.3.3.3 200.1.1.1 0 0bps
200.3.3.3 200.2.2.2 0 0bps
200.3.3.3 0000.0000.0024.00(200.4.4.4) 0 0bpsAll the links are there.
Now, we deactivate TED db export policy (from bgp to TED):
root@r4b# deactivate protocols mpls traffic-engineering database export
[edit]
root@r4b# commit
commit complete
root@r4b# run show ted link
ID ->ID LocalPath LocalBW
0000.0000.0024.00(200.4.4.4) 200.2.2.2 0 0bps
0000.0000.0024.00(200.4.4.4) 200.3.3.3 0 0bps
0000.0000.0024.00(200.4.4.4) 0000.0000.0014.00(100.4.4.4) 0 0bps
200.1.1.1 200.2.2.2 0 0bps
200.1.1.1 200.3.3.3 0 0bps
200.2.2.2 200.1.1.1 0 0bps
200.2.2.2 200.3.3.3 0 0bps
200.2.2.2 0000.0000.0024.00(200.4.4.4) 0 0bps
200.3.3.3 200.1.1.1 0 0bps
200.3.3.3 200.2.2.2 0 0bps
200.3.3.3 0000.0000.0024.00(200.4.4.4) 0 0bps
root@r4b# run show route table lsdist.0 | match AS:100 | match 100.1.1.1
PREFIX { Node { AS:100 BGP-LS ID:100 ISO:0000.0000.0011.00 } { IPv4:100.1.1.1/32 } ISIS-L2:0 }/1216As a result, only local links are present even if remote links are inside lsdist.0. This shows us what TED db export policy does.
We do the same with import policy:
root@r4b# deactivate protocols mpls traffic-engineering database import
[edit]
root@r4b# commit
commit complete
root@r4b# run show route table lsdist.0 | match AS:200
[edit]
root@r4b#This time, data is not copied from TED to lsdist.0, meaning I have no AS200 routes there, As a consequence, AS100 is receiving nothing via BGP-LS.
Now, we go to a PE, r1b. Again, we check TED links:
root@r1b# run show ted link
ID ->ID LocalPath LocalBW
0000.0000.0011.00(100.1.1.1) 0000.0000.0013.00(100.3.3.3) 0 0bps
0000.0000.0011.00(100.1.1.1) 0000.0000.0012.00(100.2.2.2) 0 0bps
0000.0000.0012.00(100.2.2.2) 0000.0000.0014.00(100.4.4.4) 0 0bps
0000.0000.0012.00(100.2.2.2) 0000.0000.0013.00(100.3.3.3) 0 0bps
0000.0000.0012.00(100.2.2.2) 0000.0000.0011.00(100.1.1.1) 0 0bps
0000.0000.0013.00(100.3.3.3) 0000.0000.0014.00(100.4.4.4) 0 0bps
0000.0000.0013.00(100.3.3.3) 0000.0000.0012.00(100.2.2.2) 0 0bps
0000.0000.0013.00(100.3.3.3) 0000.0000.0011.00(100.1.1.1) 0 0bps
0000.0000.0014.00(100.4.4.4) 0000.0000.0013.00(100.3.3.3) 0 0bps
0000.0000.0014.00(100.4.4.4) 0000.0000.0012.00(100.2.2.2) 0 0bps
0000.0000.0014.00(100.4.4.4) 0000.0000.0024.00 0 0bps
200.1.1.1 200.2.2.2 0 0bps
200.1.1.1 200.3.3.3 1 0bps
200.2.2.2 200.1.1.1 0 0bps
200.2.2.2 200.3.3.3 0 0bps
200.2.2.2 200.4.4.4 0 0bps
200.3.3.3 200.1.1.1 0 0bps
200.3.3.3 200.2.2.2 0 0bps
200.3.3.3 200.4.4.4 1 0bps
200.4.4.4 200.2.2.2 0 0bps
200.4.4.4 200.3.3.3 0 0bps
200.4.4.4 0000.0000.0014.00(100.4.4.4) 0 0bpsAll the links are there.
Remote links are received via iBGP-LS from r4b and copied into TED (TED db export policy).
This is iBGP relevant config on r1b:
set policy-options policy-statement bgp-to-ted term ok from family traffic-engineering
set policy-options policy-statement bgp-to-ted term ok then accept
set policy-options policy-statement bgp-to-ted then reject
set policy-options policy-statement lb then load-balance per-packet
set protocols bgp group ibgp-ls type internal
set protocols bgp group ibgp-ls local-address 200.1.1.1
set protocols bgp group ibgp-ls family traffic-engineering unicast
set protocols bgp group ibgp-ls neighbor 200.4.4.4
set protocols mpls traffic-engineering database export policy bgp-to-tedAs you can see there is no BGP export policy for the resons we exaplained before.
At the same time, we have no TED db import policy. That is a sort of consequence of not needing the BGP export policy; if i have nothing to export via BGP, there is no need to copy routs from TED to lsdist.0.
Everything seems ready but it is not.
TED now includes both local OSPF entries and remote (exported) ISIS ones.
root@r1b# run show ted protocol
Protocol name Credibility Self node
Exported ISIS-L2(1) 347
Exported ISIS-L1(2) 346
OSPF(0) 0 200.1.1.1By default, RSVP prefers local entries to build LSPS. This is imposed via credibility values. Simply put, a local protocol is “more credible” than an external one.
This prevents RSVP to build inter-as lsps. To overcome this we add:
set protocols mpls cross-credibility-cspfNext, we configure 2 lsps: one to r4b (intra-as) and one to r1a (inter-as):
set protocols mpls label-switched-path r1a to 100.1.1.1
set protocols mpls label-switched-path r4b to 200.4.4.4
root@r1b# run show mpls lsp
Ingress LSP: 2 sessions
To From State Rt P ActivePath LSPname
100.1.1.1 0.0.0.0 Dn 0 - r1a
200.4.4.4 200.1.1.1 Up 0 * r4b
Total 2 displayed, Up 1, Down 1The intra-AS one failed to come up, even if we configured cross credibility. The issue must be somewhere else.
Let’s find out more:
100.1.1.1
From: 0.0.0.0, State: Dn, ActiveRoute: 0, LSPname: r1a, LSPid: 11
ActivePath: (none)
LSPtype: Static Configured, Penultimate hop popping
LoadBalance: Random
Follow destination IGP metric
Encoding type: Packet, Switching type: Packet, GPID: IPv4
LSP Self-ping Status : Enabled
Primary State: Dn
Priorities: 7 0
SmartOptimizeTimer: 180
Flap Count: 1
MBB Count: 2
Will be enqueued for recomputation in 24 second(s).
48 Jun 27 13:40:34.027 CSPF failed: no route toward 100.1.1.1[6 times, first Jun 27 12:43:28.749]
root@r1b# run show ted database 100.1.1.1
TED database: 5 ISIS nodes 8 INET nodes 0 INET6 nodes
ID Type Age(s) LnkIn LnkOut Protocol
0000.0000.0011.00(100.1.1.1) Rtr 2974 2 2 Exported ISIS-L2(1)
To: 0000.0000.0013.00(100.3.3.3), Local: 192.168.13.0, Remote: 192.168.13.1
Local interface index: 0, Remote interface index: 0
To: 0000.0000.0012.00(100.2.2.2), Local: 192.168.12.0, Remote: 192.168.12.1
Local interface index: 0, Remote interface index: 0It complains about not finding a route towards 100.1.1.1 (r1a) even if 100.1.1.1 is present within the TED db.
I enable traceoptions to find out this:
Jun 27 13:40:34.027798 Reverse Link for 192.168.45.1(200.4.4.4:335)->192.168.45.0(100.4.4.4:0) not foundThe link between ASs seems to be the problem.
More checking:
root@r1b# run show ted link detail | match 45
0000.0000.0014.00(100.4.4.4)->0000.0000.0024.00, Local: 192.168.45.0, Remote: 192.168.45.1
200.4.4.4->0000.0000.0014.00(100.4.4.4), Local: 192.168.45.1, Remote: 192.168.45.0
root@r4b# run show route table lsdist.0 | match 45 | match AS
LINK { Local { AS:100 BGP-LS ID:100 ISO:0000.0000.0014.00 }.{ IPv4:192.168.45.0 } Remote { AS:100 BGP-LS ID:100 ISO:0000.0000.0024.00 }.{ IPv4:192.168.45.1 } ISIS-L2:0 }/1216
LINK { Local { AS:200 BGP-LS ID:200 Area:0.0.0.0 IPv4:200.4.4.4 }.{ IPv4:192.168.45.1 } Remote { AS:200 BGP-LS ID:200 Area:0.0.0.0 IPv4:100.4.4.4 }.{ IPv4:192.168.45.0 } OSPF:0 }/1216Junos complains about not finding a reverse link. However, we can see both links are there. Anyhow, one is from OSPF and the other from ISIS. Currently, Junos requires both links to come from the same protocol so even if TED has an entry for both r4a->r4b and r4b->r4a, it is not able to match them.
As a result, we have to enable a second IGP on one of the ASs.
Here, we chose to enable OSPF in AS100:
set protocols ospf traffic-engineering
set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 interface-type p2p
set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 passive traffic-engineering remote-node-id 192.168.45.1
set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 passive traffic-engineering remote-node-router-id 200.4.4.4
set policy-options policy-statement ted-to-bgp term ok from protocol ospfAs you may notice, we also need to update the ted-to-bgp policy so to copy the new ospf route inot lsdist.0 as well.
Now, I have one more link:
root@r1b# run show ted link detail | match 45
0000.0000.0014.00(100.4.4.4)->200.4.4.4, Local: 192.168.45.0, Remote: 192.168.45.1
0000.0000.0014.00(100.4.4.4)->0000.0000.0024.00, Local: 192.168.45.0, Remote: 192.168.45.1
200.4.4.4->0000.0000.0014.00(100.4.4.4), Local: 192.168.45.1, Remote: 192.168.45.0
root@r4b# run show route table lsdist.0 | match 45 | match AS
LINK { Local { AS:100 BGP-LS ID:100 ISO:0000.0000.0014.00 }.{ IPv4:192.168.45.0 } Remote { AS:100 BGP-LS ID:100 ISO:0000.0000.0024.00 }.{ IPv4:192.168.45.1 } ISIS-L2:0 }/1216
LINK { Local { AS:100 BGP-LS ID:100 Area:0.0.0.0 IPv4:100.4.4.4 }.{ IPv4:192.168.45.0 } Remote { AS:100 BGP-LS ID:100 Area:0.0.0.0 IPv4:200.4.4.4 }.{ IPv4:192.168.45.1 } OSPF:0 }/1216
LINK { Local { AS:200 BGP-LS ID:200 Area:0.0.0.0 IPv4:200.4.4.4 }.{ IPv4:192.168.45.1 } Remote { AS:200 BGP-LS ID:200 Area:0.0.0.0 IPv4:100.4.4.4 }.{ IPv4:192.168.45.0 } OSPF:0 }/1216Two of them are ospf and that is enough to have our lsp up:
root@r1b# run show mpls lsp ingress
Ingress LSP: 2 sessions
To From State Rt P ActivePath LSPname
100.1.1.1 200.1.1.1 Up 0 * r1a
200.4.4.4 200.1.1.1 Up 0 * r4b
Total 2 displayed, Up 2, Down 0
100.1.1.1
From: 200.1.1.1, State: Up, ActiveRoute: 0, LSPname: r1a, LSPid: 11
ActivePath: (primary)
LSPtype: Static Configured, Penultimate hop popping
LoadBalance: Random
Follow destination IGP metric
Encoding type: Packet, Switching type: Packet, GPID: IPv4
LSP Self-ping Status : Enabled
*Primary State: Up
Priorities: 7 0
SmartOptimizeTimer: 180
Flap Count: 2
MBB Count: 2
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 23)
192.168.113.1 S 192.168.134.1 S 192.168.45.0 S 192.168.34.0 S 192.168.13.0 S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
192.168.113.1(Label=26) 192.168.134.1(Label=34) 192.168.45.0(Label=33) 192.168.34.0(Label=26) 192.168.13.0(Label=3)That’s it! We managed to create our inter-as rsvp AS!
Is it enough? It might be but while we are here let’s do one more thing.
BGP-LS is designed to support TE use-cases. It means it is designed to bring all those TE attributes we are familiar with.
On r1a (AS100) i configure admin groups:
root@r1a# set protocols mpls admin-groups premium 1
root@r1a# set protocols mpls interface ge-0/0/0 admin-group premium
root@r1a# set protocols isis traffic-engineering advertisement alwaysAdvertisement always is needed with ISIS to have colors advertised into TED.
On a AS200 router I see this:
0000.0000.0011.00(100.1.1.1)->0000.0000.0012.00(100.2.2.2), Local: 192.168.12.0, Remote: 192.168.12.1
Local interface index: 0, Remote interface index: 0
LocalPath: 0, Metric: 10, IGP metric: 10, StaticBW: 1000Mbps, AvailBW: 1000Mbps
Color: 0x2 1
localBW [0] 0bps [1] 0bps [2] 0bps [3] 0bps
localBW [4] 0bps [5] 0bps [6] 0bps [7] 0bps
AvailBW [0] 1000Mbps [1] 1000Mbps [2] 1000Mbps [3] 1000Mbps
AvailBW [4] 1000Mbps [5] 1000Mbps [6] 1000Mbps [7] 1000MbpsColor information si preserved via BGP-LS. This means we can use that data to build lsps.
I configure admin-group premium throughout the network:
I define another LSP:
root@r1b# set protocols mpls label-switched-path r1a-premium to 100.1.1.1 admin-group include-any premium
100.1.1.1
From: 200.1.1.1, State: Up, ActiveRoute: 0, LSPname: r1a-premium, LSPid: 13
ActivePath: (primary)
LSPtype: Static Configured, Penultimate hop popping
LoadBalance: Random
Follow destination IGP metric
Encoding type: Packet, Switching type: Packet, GPID: IPv4
LSP Self-ping Status : Enabled
*Primary State: Up
Priorities: 7 0
SmartOptimizeTimer: 180
Include Any: premium
Flap Count: 0
MBB Count: 0
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 23)
192.168.112.1 S 192.168.124.1 S 192.168.45.0 S 192.168.24.0 S 192.168.12.0 S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
192.168.112.1(Label=32) 192.168.124.1(Label=36) 192.168.45.0(Label=35) 192.168.24.0(Label=24) 192.168.12.0(Label=3)LSP is up and traverses routers r2a and r2b, the ones where group premium is configured.
Let’s compare the two RROs:
Non premium lsp
192.168.113.1(Label=26) 192.168.134.1(Label=34) 192.168.45.0(Label=33) 192.168.34.0(Label=26) 192.168.13.0(Label=3)
Premium lsp
192.168.112.1(Label=32) 192.168.124.1(Label=36) 192.168.45.0(Label=35) 192.168.24.0(Label=24) 192.168.12.0(Label=3)They take different routes based on the different user constraints.
We really have just extended TE and LS to multiple domains.
Ciao
IoSonoUmberto
IoSonoUnRouter 
3 thoughts on “Link State on steroids with BGP-LS for Inter-domain TE”