In previous posts, we have always explicitly configured transport classes.
Anyhow, this approach might not be ideal as we need to pre-provision all the TCs we might need in the future.
An alternative approach is to have transport classes on-demand.
This is our reference topology:
Router r1b (rightmost one) advertises IPv4 prefix 200.200.200.201 with community color:0:666.
Transport class for that color is not configured anywhere.
Now, on both ASs, we configure some lsps to use color 666 (what will use color 666 is not important here. It might be a flex algo, a rsvp lsp or a stre lsps. Choose what you want. What matters is that there are some 666-colored lsps within both ASs).
For example, in AS 100 (left one) I have on r1a (leftmost router):
set routing-options flex-algorithm 129 color 666
To better understand how this auto creation works, we temporarily disable algo 129:
root@r1a# set routing-options transport-class auto-create
Let’s check:
root@r1a# run show route receive-protocol bgp 100.0.0.100 table inet.0 hidden extensive
inet.0: 20 destinations, 20 routes (19 active, 0 holddown, 1 hidden)
200.200.200.201/32 (1 entry, 0 announced)
Accepted
Nexthop: 200.1.1.1
Localpref: 100
AS path: 200 I
Communities: color:0:666
root@r1a# run show routing transport-class all
Transport Class: junos-tc-555 Configured name: tc555
Color: 555, References: 4
Transport Endpoints: IPv4 4 IPv6 0
Mapping community: color:0:555
Route Target: transport-target:0:555
Routing instance: junos-rti-tc-555
root@r1a# run show route 200.1.1.1 table inet.0
[edit]
root@r1a#
Route is hidden. Why? Even if route has color community color:0:666 there is no TC 666 as we can see. At this point, Junos to try to solve it as a standard IPv4 route but there is no inet.0 route to remote PNH 200.1.1.1.
Now, we temporarily disable 200.200.200.201 advertisement on r1b.
We enable algo 129 on r1a:
root@r1a# set protocols isis source-packet-routing flex-algorithm 129
Now:
root@r1a# run show routing transport-class all
Transport Class: junos-tc-555 Configured name: tc555
Color: 555, References: 4
Transport Endpoints: IPv4 4 IPv6 0
Mapping community: color:0:555
Route Target: transport-target:0:555
Routing instance: junos-rti-tc-555
Transport Class: junos-tc-666
Color: 666, References: 2
Transport Endpoints: IPv4 4 IPv6 0
Mapping community: color:0:666
Route Target: transport-target:0:666
Routing instance: junos-rti-tc-666
[edit]
root@r1a# run show route table junos-rti-tc-666
junos-rti-tc-666.inet.3: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
100.3.3.3/32 *[L-ISIS/7] 00:01:51, metric 10
> to 192.168.13.1 via ge-0/0/1.0
100.4.4.4/32 *[L-ISIS/7] 00:01:51, metric 20
> to 192.168.13.1 via ge-0/0/1.0, Push 1124
200.1.1.1/32 *[BGP/167] 00:01:51, MED 20, localpref 100, from 100.4.4.4
AS path: 200 200 I, validation-state: unverified
> to 192.168.13.1 via ge-0/0/1.0, Push 38, Push 1124(top)
200.3.3.3/32 *[BGP/167] 00:01:51, MED 10, localpref 100, from 100.4.4.4
AS path: 200 200 I, validation-state: unverified
> to 192.168.13.1 via ge-0/0/1.0, Push 39, Push 1124(top)
Transport class was automatically created an already includes BGP-CT routes coming from other AS (where we have some lsps using same color 666).
This tells us one important thing: transport class is dynamically created as soon as we have some active lsps for a given color. It is not required to have a BGP route with a color community to trigger TC creation. This way, as soon as the BGP route arrives, everything is in place to resolve it.
Let’s re-enable 200.200.200.201 advertisement on r1b to verify it gets resolved:
root@r1a# run show route 200.200.200.201
inet.0: 20 destinations, 20 routes (20 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
200.200.200.201/32 *[BGP/170] 00:00:23, localpref 100, from 100.0.0.100
AS path: 200 I, validation-state: unverified
> to 192.168.13.1 via ge-0/0/1.0, Push 38, Push 1124(top)
[edit]
root@r1a# run show route 200.200.200.201 extensive | match "comm|orig|Protocol nex"
Protocol next hop: 200.1.1.1
Communities: color:0:666
Protocol next hop: 200.1.1.1 Metric: 20
200.1.1.1/32 Originating RIB: junos-rti-tc-666.inet.3
Protocol next hop: 100.4.4.4 Metric: 20
100.4.4.4/32 Originating RIB: junos-rti-tc-666.inet.3
That’s it, it works!
There is one thing worth looking at:
root@r1a# run show route table bgp.transport.3 match-prefix *200.1.1.1
bgp.transport.3: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
200.4.4.4:8:200.1.1.1/96
*[BGP/167] 00:28:46, MED 20, localpref 100, from 100.4.4.4
AS path: 200 I, validation-state: unverified
> to 192.168.12.1 via ge-0/0/0.0, Push 33, Push 1114(top)
200.4.4.4:9:200.1.1.1/96
*[BGP/167] 00:08:27, MED 20, localpref 100, from 100.4.4.4
AS path: 200 200 I, validation-state: unverified
> to 192.168.13.1 via ge-0/0/1.0, Push 38, Push 1124(top)
[edit]
root@r1a# run show route table bgp.transport.3 match-prefix *200.1.1.1 extensive | match comm
Communities: transport-target:0:555
Communities: transport-target:0:666
root@r1a# run show route receive-protocol bgp 100.4.4.4 table bgp.transport.3 extensive match-prefix *200.1.1.1
bgp.transport.3: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)
* 200.4.4.4:8:200.1.1.1/96 (1 entry, 0 announced)
Import Accepted
Route Distinguisher: 200.4.4.4:8
Route Label: 33
Nexthop: 100.4.4.4
MED: 20
Localpref: 100
AS path: 200 I
Communities: transport-target:0:555
* 200.4.4.4:9:200.1.1.1/96 (1 entry, 0 announced)
Import Accepted
Route Distinguisher: 200.4.4.4:9
Route Label: 38
Nexthop: 100.4.4.4
MED: 20
Localpref: 100
AS path: 200 200 I
Communities: transport-target:0:666
There are now two CT routes to remote PNH 200.1.1.1. Endpoint router is the same, physically, but logically they are two different entities: one reachable via a tc555 path while the other via a tc666 path. We need two different routes because each route uses a different label and it uses a different label as the border router needs to know to which lsp traffic must be sent.
After all, it is still good old Inter-AS option with BGP-LU. We only have to think about 200.1.1.1-tc-666 and 200.1.1.1-tc-555 as two loopbacks of two different remote PEs. This is not a totally abstract idea as we have to consider that with transport classes and SR we slice networks into multiple layers and each layer can be treated as an independent network.
In previous post we went through a basic BGP-CT Inter-AS scenario. There we saw the difference between service routes (color) and transport routes (transport-target) and how the interact with each other.
We have also mentioned that Junos provides, by default, a fallback mechanism if the primary route to PNH is not available.
Let’s see how it works.
We will use our Inter-AS topology and focus on end to end IP traffic.
root@r1a# run show route 123.4.4.41 extensive | match "Protocol nex|Comm|Orig"
Protocol next hop: 100.4.4.4
AS path: I (Originator)
Originator ID: 100.4.4.4
Communities: color:0:555
Protocol next hop: 100.4.4.4 Metric: 20
100.4.4.4/32 Originating RIB: inet.3
[edit]
root@r1a# run show route 200.200.200.200 extensive | match "Protocol nex|Comm|Orig"
[edit]
root@r1a# run show route 200.200.200.200 hidden
inet.0: 20 destinations, 20 routes (19 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both
200.200.200.200/32 [BGP/170] 00:00:38, localpref 100, from 100.0.0.100
AS path: 200 I, validation-state: unverified
Unusable
Intra-AS prefix (123.4.4.41) is still active but resolving PNH 100.4.4.4 into inet.3 while inter-AS prefix (200.200.200.200) is hidden due to unusable next-hop.
Let’s focus on the intra-AS route and go through the route hierarchy:
200.200.200.200 has PNH 200.1.1.1
200.1.1.1 is received as transport route via BGP-CT and stored into bgp.transport.3
transport route to 200.1.1.1 has PNH 100.4.4.4
PNH 100.4.4.4 should be resolved into tc 555 rib
but tc 555 rib no longer has a route to 100.4.4.4 (we disabled flex algo, rsvp and srte path):
root@r1a# run show route 100.4.4.4
inet.0: 20 destinations, 20 routes (19 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both
100.4.4.4/32 *[IS-IS/18] 1d 13:41:53, metric 20
> to 192.168.12.1 via ge-0/0/0.0
to 192.168.13.1 via ge-0/0/1.0
inet.3: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
100.4.4.4/32 *[L-ISIS/14] 20:57:34, metric 20
> to 192.168.12.1 via ge-0/0/0.0, Push 1104
to 192.168.13.1 via ge-0/0/1.0, Push 1104
The only lsp in in inet.3.
As a consequence, transport route to 200.1.1.1 (bgp.transport.3) cannot be resolved. Due to a chain effect, service route 200.200.200.200 cannot be resolved as it relies on the transport route.
The issue is not with the service route itself (200.200.200.200) but with the underlying transport route it uses (bgp.transport.3 route to 200.1.1.1) to resolve service route PNH 200.1.1.1 (which in turn relies on the existence of a route to 100.4.4.4 in tc 555 rib).
But why does 123.4.4.41 is active anyway? To answer that, we need to recall resolution schemes:
root@r1a# run show route resolution scheme all
Resolution scheme: junos-resol-schem-tc-555-v4-service
References: 1
Mapping community: color:0:555
Resolution Tree index 1, Nodes: 3
Policy: [__resol-schem-common-import-policy__]
Contributing routing tables: junos-rti-tc-555.inet.3 inet.3
Resolution scheme: junos-resol-schem-tc-555-v4-transport
References: 1
Mapping community: transport-target:0:555
Resolution Tree index 2, Nodes: 0
Policy: [__resol-schem-common-import-policy__]
Contributing routing tables: junos-rti-tc-555.inet.3
Service routes are resolved into tc 555 rib first. If no route to PNH is found there, then table inet.3 is used as fallback.
As a consequence, service route 123.4.4.41 finds a suitable route to PNH 100.4.4.4 in inet.3 and can remain active.
On the other transport routes do not have a fallback by default. If no route to PNH is found in tc 555 rib, route is declared unusable.
In our case, service route 200.200.200.200, potentially, might use a fallback route but the issue arise before, at a previous resolution step. When it tries to resolve PNH 200.1.1.1, as we have seen before, primary routing table for that prefix is bgp.transport.3. Route to 200.1.1.1 there is a transport route and transport routes do not have any fallback table by default. As a result, bgp.transport.3 route to 200.1.1.1 is hidden, resulting in service route 200.200.200.200 being hidden as well.
Simply put, we might say that, by default, intra-AS routes can leverage fallback routes while inter-AS service routes have a harder time doing it as they rely on transport routes that do not have a fallback mechanism.
One might wonder why… I think the reason is not technical. After all, nothing prevents us to program our router to perform a second lookup in another table if needed. Anyhow, we have to think about what inter-as end to end tc paths mean. We said transport classes might be seen as SLA profiles. LSPs included into a transport class normally are built so to guarantee certain service levels (for example, into a premium transport class we might include only lsps with high bw and low delay). If we build a path crossing multiple ASs, for example a premium path, all the ASs should guarantee, within its borders, to meet those service levels.
Behind such a path, we probably have a contract between two companies clearly stating that those service levels must be met and it is not acceptable to use lower standards. Considering this, in such a scenario, fallback is not ideal as one AS might fallback to a lsp that cannot meet agreed service levels, causing “troubles” to the other AS (other ISP). For this reason, not enabling fallback by default on transport route is a way to impose that service levels must be met and respected along the whole path strictly.
What an ISP can do is to have multiple lsps towards “bordering” PNHs so to be more resilient and fault tolerant. To make an example, in our topology, r1a had 3 lsps to 100.4.4.4 and the assumption is, of course, that all those 3 lsps meet the SLA. Outage is still possible as we have seen but having all those lsps down at the same time is unlikely and more a lab thing. As usual, careful planning is fundamental!
Do we really have to give up on fallback for transport routes? Not really…we might configure customer configuration schemes but this is another story…
We should be confident with transport classes and how they work with BGP colored routes.
Anyhow, we have also seen them in action within a single domain (single AS). We can refer to that as the Intra-AS TC scenario.
What if we wanted to extend TCs to multiple ASs? That is possible and allows us to create an end to end path.
Just few words about terminology. What kind of end to end path is this? Informally, we might talk about a a TE end to end path. Anyhow, what we build is not a single TE path. It is more like stitching multiple TE paths together via labels. For this reason, it might be more useful to talk about an end to end SLA path. After all what we do is to “connect” different TCs belonging to multiple domains. TCs, as we have seen, are logical representations of SLAs and those SLAs are turned into something real through TE lsps. Let’s agree on talking about an end to end path…which is a SLA path, not a TE one.
We might define 3 transport classes: gold, silver and bronze. Gold one might include high-bw redundant lsps while silver and bronze might include more expensive lsps. Through color community I can map a route to a given TC, hence, to a given service. It is no surprise that colored route are also known as service routes.
The idea is to give the adequate service to routes. For instance, route towards a critical web server might be assigned to gold tc while the one towards a mail server just a bronze service.
Another option is to sell VPN to customers and, based on the service they purchase, map their traffic to a specific TC.
This is nothing more than good old Traffic Engineering.
We have already said many time that one of SR benefits is to bring TE to another level by allowing us to be more flexible and granular when providing TE paths. This is possible by combining SRTE paths (explicit, dcspf, …), flex algo and, with transport classic, to leverage classic rsvp tunnels as well.
What if we had some traffic spanning over multiple ASs but desiring to have an end to end path providing certain SLAs.? Let’s consider this simple scenario: AS1 and AS2. Locally, they both have a premium TC. There is some traffic going from AS1 to AS2 and we would like that traffic to follow and end to end premium path. This means “stitching” the two premium paths (internal to a single ASO so to create an end to end one (SLA path composed of two local TE paths, each of them part of the same TC).
This is made possible, guess what, by BGP by introducing new family: inet transport. This BGP flavor is known as BGP-CT: BGP classfull transport. Basically, we want to have the same transport class on both ASs and seamlessly create an end to end path from AS1 to AS2 and viceversa. BGP-CT is the one responsible for sticking premium path in AS1 with premium path in AS2.
We are going to work on this topology:
but first, we will focus on the bgp-ct part to create the end to end tc555 path:
What we want to achieve is to have a path from 100.1.1.1 to 200.1.1.1 (and viceversa) in tc 555 rib.
Both ASs are configured similarly (ISIS L2 as IGP, flex algo, RSVP, …) and we omit this part.
Most importantly,they both have TC 555 configured!
If you remember from a previous post, we saw this:
root@r1a# run show route resolution scheme all
Resolution scheme: junos-resol-schem-tc-555-v4-service
References: 1
Mapping community: color:0:555
Resolution Tree index 1, Nodes: 5
Policy: [__resol-schem-common-import-policy__]
Contributing routing tables: junos-rti-tc-555.inet.3 inet.3
Resolution scheme: junos-resol-schem-tc-555-v4-transport
References: 1
Mapping community: transport-target:0:555
Resolution Tree index 2, Nodes: 4
Policy: [__resol-schem-common-import-policy__]
Contributing routing tables: junos-rti-tc-555.inet.3
We have a service schema and a transport schema. Up to now, we have dealt with service routes, tagged with color community.
Now, we are going to focus on transport routes tagged with transport-target community.
We have seen that tc rib includes all the routers it can reach with lsps associated to the tc.
root@r1a# run show route table junos-rti-tc-555
junos-rti-tc-555.inet.3: 4 destinations, 6 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
100.2.2.2/32 *[L-ISIS/7] 02:05:04, metric 10
> to 192.168.12.1 via ge-0/0/0.0
100.4.4.4/32 *[L-ISIS/7] 02:05:04, metric 20
> to 192.168.12.1 via ge-0/0/0.0, Push 1114
[SPRING-TE/8] 02:11:49, metric 1, metric2 20
> to 192.168.13.1 via ge-0/0/1.0, Push 1104
[RSVP/9/1] 02:14:11, metric 20
> to 192.168.12.1 via ge-0/0/0.0, label-switched-path rsvp-r4a
This tells us tc 555 can reach r2a (100.2.2.2) via a flex algo route and r4a (100.4.4.4) via three routes (flex algo, rsvp, srte).
The active route for each destination is copied into another table called bgp.transport.3:
root@r1a# run show route table bgp.transport.3
bgp.transport.3: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
100.1.1.1:8:100.2.2.2/96
*[L-ISIS/7] 02:06:44, metric 10
> to 192.168.12.1 via ge-0/0/0.0
100.1.1.1:8:100.4.4.4/96
*[L-ISIS/7] 02:06:44, metric 20
> to 192.168.12.1 via ge-0/0/0.0, Push 1114
100.1.1.1:9:100.3.3.3/96
*[L-ISIS/7] 02:06:44, metric 10
> to 192.168.13.1 via ge-0/0/1.0
root@r1a# run show route table bgp.transport.3 extensive | match comm
Communities: transport-target:0:555
Communities: transport-target:0:555
Those routes, een if they are bgp routes, are tagged with a transport-target community.
We might say that, as a starting point, bgp.transport.3 includes routes towards all the intra-as routers it can reach within that tc.
Moreover, you can see those routes have a MP-BGP-like NLRI structure. They start with a RD. That RD was automatically generated and that why we needed to configured route-distinguisher-id under routing-options when enabling transport classes.
Similarly, we can see this on r4a:
root@r4a> show route table bgp.transport.3
bgp.transport.3: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
100.4.4.4:9:100.1.1.1/96
*[L-ISIS/14] 18:54:15, metric 20
> to 192.168.24.0 via ge-0/0/0.0, Push 1111
100.4.4.4:9:100.2.2.2/96
*[L-ISIS/14] 18:54:15, metric 10
> to 192.168.24.0 via ge-0/0/0.0
R4a is a special router; it is a border router between AS 100 and AS 200. It has the information about the endpoint it can reach within tc 555 stored in bgp.transport.3. That “table name is “bgp.” is there for a reason. The idea is to use BGP to advertise those routes to r4b, the border router of AS 200.
We are going to use eBGP-CT. This is configuration on r4a (r4b is specular):
set protocols bgp group ebgp type external
set protocols bgp group ebgp import imp-ebgp
set protocols bgp group ebgp family inet transport
set protocols bgp group ebgp export exp-ebgp
set protocols bgp group ebgp peer-as 200
set protocols bgp group ebgp neighbor 192.168.45.1
set policy-options policy-statement exp-ebgp term tc from community tc555
set policy-options policy-statement exp-ebgp term tc then accept
set policy-options policy-statement imp-ebgp term ok from protocol bgp
set policy-options policy-statement imp-ebgp term ok then accept
The key here is to enable family inet transport (BGP-CT). Then, we have an export policy to advertise transport routes tagged with transport-target:0:555 (transport rt associated to tc555) and an import policy to accept bgp routes (here we do not filter on any specific transport rt but we accept anything. Filtering can be achieved with usual policy manipulation).
As a result:
root@r4a> show route advertising-protocol bgp 192.168.45.1 table bgp.transport.3 extensive
bgp.transport.3: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
* 100.4.4.4:9:100.1.1.1/96 (1 entry, 1 announced)
BGP group ebgp type External
Route Distinguisher: 100.4.4.4:9
Route Label: 18
Nexthop: Self
Flags: Nexthop Change
MED: 20
AS path: [100] I
Communities: transport-target:0:555
* 100.4.4.4:9:100.2.2.2/96 (1 entry, 1 announced)
BGP group ebgp type External
Route Distinguisher: 100.4.4.4:9
Route Label: 19
Nexthop: Self
Flags: Nexthop Change
MED: 10
AS path: [100] I
Communities: transport-target:0:555
As you can see, a label is assigned as well.
Next, we move to r4b, the border router in AS 200.
root@r4b> show route table bgp.transport.3
bgp.transport.3: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
200.4.4.4:8:200.1.1.1/96
*[L-ISIS/14] 19:07:54, metric 20
> to 192.168.124.0 via ge-0/0/0.0, Push 1211
200.4.4.4:8:200.2.2.2/96
*[L-ISIS/14] 19:08:04, metric 10
> to 192.168.124.0 via ge-0/0/0.0
100.4.4.4:9:100.1.1.1/96
*[BGP/167] 18:42:20, MED 20, localpref 100
AS path: 100 I, validation-state: unverified
> to 192.168.45.0 via ge-0/0/2.0, Push 18
100.4.4.4:9:100.2.2.2/96
*[BGP/167] 18:42:20, MED 10, localpref 100
AS path: 100 I, validation-state: unverified
> to 192.168.45.0 via ge-0/0/2.0, Push 19
Here, table bgp.transport.3 has internal routes plus BGP-CT routes to reach endpoint in AS 100. Notice, to reach remote endpoint the labels r4a advertised are pushed.
Last step, is to advertise those remote endpoint internally, to r1b. This is done via iBGP-CT.
On r4b:
set protocols bgp group ibgp type internal
set protocols bgp group ibgp local-address 200.4.4.4
set protocols bgp group ibgp family inet transport
set protocols bgp group ibgp neighbor 200.1.1.1
On r1b:
set protocols bgp group ibgp type internal
set protocols bgp group ibgp local-address 200.1.1.1
set protocols bgp group ibgp import imp-ct
set protocols bgp group ibgp family inet transport
set protocols bgp group ibgp neighbor 200.4.4.4
set policy-options policy-statement imp-ct term ok from protocol bgp
set policy-options policy-statement imp-ct term ok from community tc555
set policy-options policy-statement imp-ct term ok then accept
This is what we have on r1b bgp.transport.3:
root@r1b> show route receive-protocol bgp 200.4.4.4 table bgp.transport.3 extensive
bgp.transport.3: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
* 100.4.4.4:9:100.1.1.1/96 (1 entry, 0 announced)
Import Accepted
Route Distinguisher: 100.4.4.4:9
Route Label: 30
Nexthop: 200.4.4.4
MED: 20
Localpref: 100
AS path: 100 I
Communities: transport-target:0:555
* 100.4.4.4:9:100.2.2.2/96 (1 entry, 0 announced)
Import Accepted
Route Distinguisher: 100.4.4.4:9
Route Label: 29
Nexthop: 200.4.4.4
MED: 10
Localpref: 100
AS path: 100 I
Communities: transport-target:0:555
root@r1b> show route table bgp.transport.3
bgp.transport.3: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
200.1.1.1:8:200.2.2.2/96
*[L-ISIS/14] 19:18:29, metric 10
> to 192.168.112.1 via ge-0/0/0.0
200.1.1.1:8:200.4.4.4/96
*[L-ISIS/14] 19:16:26, metric 20
> to 192.168.112.1 via ge-0/0/0.0, Push 1214
100.4.4.4:9:100.1.1.1/96
*[BGP/167] 18:50:41, MED 20, localpref 100, from 200.4.4.4
AS path: 100 I, validation-state: unverified
> to 192.168.112.1 via ge-0/0/0.0, Push 30, Push 1214(top)
100.4.4.4:9:100.2.2.2/96
*[BGP/167] 18:50:41, MED 10, localpref 100, from 200.4.4.4
AS path: 100 I, validation-state: unverified
> to 192.168.112.1 via ge-0/0/0.0, Push 29, Push 1214(top)
R1b can reach both endpoint in its AS and remote endpoints (r1a and r2a). Again, r3a is not reachable as tc 555 in AS 100 has no route to that router.
To reach r1a (PNH 100.1.1.1) a double push is performed. Why?
To understand it, we need to recall the resolution schema and what the BGP advertisement contains:
Route has community transport-target:0:555. Resolution scheme for that community says to resolve the route in tc 555 rib. There we should find a route for the BGP protocol next-hop (200.4.4.4):
root@r1b> show route 200.4.4.4 table junos-rti-tc-555
junos-rti-tc-555.inet.3: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
200.4.4.4/32 *[L-ISIS/14] 19:21:23, metric 20
> to 192.168.112.1 via ge-0/0/0.0, Push 1214
There it is! Top label is the label to reach PNH (200.4.4.4) while bottom label is CT route label.
Our end to end path is ready!
Let’s follow it from r1b to r1a.
As just seen, first step is to reach r4b (AS 200 border router). We follow the lsp to r4b alg 128 node-sid (1214).
On r4b we have label 30 as top label. This is how it is processed:
root@r4b> show route label 30
mpls.0: 25 destinations, 25 routes (25 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
30 *[VPN/170] 19:01:18
> to 192.168.45.0 via ge-0/0/2.0, Swap 18
A label swap is performed. New label is the route label advertised over eBGP-CT by r4a.
Next, we are in AS 100. R4a processes label 18:
root@r4a> show route label 18
mpls.0: 29 destinations, 29 routes (29 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
18 *[VPN/170] 19:28:27
> to 192.168.24.0 via ge-0/0/0.0, Swap 1111
Label swap to r1a node sid to reach our final destination (100.1.1.1).
Route to 100.1.1.1 on r1b is also available in tc 555 rib:
root@r1b> show route 100.1.1.1
junos-rti-tc-555.inet.3: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
100.1.1.1/32 *[BGP/167] 19:04:33, MED 20, localpref 100, from 200.4.4.4
AS path: 100 I, validation-state: unverified
> to 192.168.112.1 via ge-0/0/0.0, Push 30, Push 1214(top)
Why that? Suppose a BGP route with PNH 100.1.1.1 with community color:0:555 arrives at r1b. As we have tc 55 configured, that BGP route is resolved into tc 555 rib so we need a route there towards 100.1.1.1.
Now, it should be clear the difference between service routes and transport routes.
Transport routes, tagged with transport-target community, are used to build end to end tunnel across ASs. They allow routers in an AS to reach endpoints in remote ASs.
Service routes, instead, are non infra routes (e.g. customer routes) that rely on transport routes to find a valid inter-as end to end tunnel to reach BGP PNH.
There are some interesting considerations to be done about their inter-dependence and fallback but we will see it later.
You have probably already thought about that but building inter-as end to end labelled paths is not something so new. It looks like an evolved inter-as option C. Comparison is correct. BGP-CT replaces BGP-LU while intra-AS LDP/RSVP lsps are replaced by a mix of SRTE/RSVP/FlexAlgo lsps to provide better TE capabilites. On top of that, transport classes allow to further slice the network to provide different SLAs.
One difference between this BGP-CT driven model and a BGP-LU one is that remote PNH are not installed into inet.0 but into tc ribs (and only those tc ribs that share the same tc with remote endpoint). This has a consequence: it is less straightforward to build that PE-PE multihop MP-eBGP session used to carry service routes.
Anyhow, this is not a big deal as, commonly, we do not have those PE-PE session but we go through the mediation of route reflectors.
Here we will use this model
both ASs have their RR (rr100 and rr200)
rr100 peers with r1a
rr200 peers with r1b
rr100 and rr200 have an eBGP multihop session to exchange routes without modifying the next-hop
rrs must have reachability somehow (this is out of the scope of this post)
Here is sample minimal config for rr100 (rr200 is specular0):
set interfaces ge-0/0/0 unit 0 family inet address 192.168.100.1/31
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 100.0.0.100/32
set interfaces lo0 unit 0 family iso address 49.0001.0000.0000.0100.00
set routing-options rib inet.3 static route 0.0.0.0/0 discard
set routing-options autonomous-system 100
set routing-options static route 200.0.0.0/8 next-hop 192.168.100.0
set protocols bgp family inet unicast
set protocols bgp family inet-vpn unicast
set protocols bgp group rr type internal
set protocols bgp group rr local-address 100.0.0.100
set protocols bgp group rr cluster 0.0.0.100
set protocols bgp group rr neighbor 100.1.1.1
set protocols bgp group rr neighbor 100.4.4.4
set protocols bgp group otherrr type external
set protocols bgp group otherrr local-address 100.0.0.100
set protocols bgp group otherrr peer-as 200
set protocols bgp group otherrr neighbor 200.0.0.200 multihop no-nexthop-change
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 lo0.0
set protocols isis level 2 wide-metrics-only
In previous post we have already set up a bgp session between r1a/r4a and rr100 to exchange inet unicast and inet-vpn routes. Now, we do the same on r1b (towards rr200) and extend the VPN to r1b as well (we omit bgp session to rr and vrf configuration on r1b as identical to what was done in previous post).
As a result, on r1a, we have this for an inet route:
root@r1a# run show route 200.200.200.200
inet.0: 20 destinations, 20 routes (20 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
200.200.200.200/32 *[BGP/170] 03:22:10, localpref 100, from 100.0.0.100
AS path: 200 I, validation-state: unverified
> to 192.168.12.1 via ge-0/0/0.0, Push 33, Push 1114(top)
[edit]
root@r1a# run show route 200.200.200.200 extensive | match "comm|orig|Protocol nex"
Protocol next hop: 200.1.1.1
Communities: color:0:555
Protocol next hop: 200.1.1.1 Metric: 20
200.1.1.1/32 Originating RIB: junos-rti-tc-555.inet.3
Protocol next hop: 100.4.4.4 Metric: 20
100.4.4.4/32 Originating RIB: junos-rti-tc-555.inet.3
and this for a vpn route:
root@r1a# run show route table vpn100.inet.0
vpn100.inet.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
1.2.3.4/32 *[Direct/0] 08:53:23
> via lo0.100
4.3.2.1/32 *[BGP/170] 02:31:11, localpref 100, from 100.0.0.100
AS path: I, validation-state: unverified
> to 192.168.12.1 via ge-0/0/0.0, Push 35, Push 1114(top)
5.6.7.8/32 *[BGP/170] 03:23:56, localpref 100, from 100.0.0.100
AS path: 200 I, validation-state: unverified
> to 192.168.12.1 via ge-0/0/0.0, Push 18, Push 33, Push 1114(top)
[edit]
root@r1a# run show route table vpn100.inet.0 5.6.7.8 extensive | match "comm|orig|Protocol nex"
Protocol next hop: 200.1.1.1
Communities: target:1:100 color:0:555
Protocol next hop: 200.1.1.1 Metric: 20
200.1.1.1/32 Originating RIB: junos-rti-tc-555.inet.3
Protocol next hop: 100.4.4.4 Metric: 20
100.4.4.4/32 Originating RIB: junos-rti-tc-555.inet.3
As you can see, the VPN route requires 3 labels to be pushed which what we had with classic inter-as option C. Here, we might have more if the intra-AS lsp was, for example, a SRTE path built with Adj SIDs.
As already said, we might see this BGP-CT scenario as the enabler for an evolved Inter-AS option C use-case leveraging the advanced TE capabilities transport classes and SR can provide.
IoSonoUnRouter 