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.3We 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-r4aThis 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.0R4a 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 acceptThe 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:555As 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 19Here, 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.1On 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 acceptThis 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:
* 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:555Route 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 1214There 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 18A 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 1111Label 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-onlyIn 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.3and 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.3As 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.
Ciao
IoSonoUmberto
IoSonoUnRouter 
2 thoughts on “BGP-CT for Inter-AS TE”