January 17, 2016 at 16:45Juniper routing instances
Routing Instance is a collection of routing tables, interfaces, and routing protocol parameters. Routing protocols control information in routing tables, and in one routing instance there can be both IPv4 and IPv6 routes simultaneously, as well as several physical or logical interfaces. One physical interface, divided into several logical units (subinterfaces), can be assigned to different routing instance (however, the same unit (subinterface) or, not divided into units, a physical interface cannot be attached to different routing instances )
Routing instance is a powerful tool of the JunOS operating system, which, when combined with c rib-groups, firewall filters and policy, can perform any task. Unfortunately, many engineers are not aware of the purpose of most routing instances, except for the painfully familiar VRF.
JunOS provides us with a large selection of routing instances available for configuration:
At the time of writing, the following types of routing instance are available for configuration:
1. VRF,
2. Forwarding,
3. Virtual router,
4. Nonforwarding,
5. VPLS,
6. Layer 2 VPN,
7. Layer2-control (MX Series routers only) ,
8. the Virtual switch statement (the MX the Series routers only),
9. Layer 2 Backhaul VPN (MX Series routers only) ( of which I will try to write a separate post).
If someone finds some kind of clerical or inaccuracies in the article (I am also a human being and I can be mistaken) or someone will have additions, please write personal messages with links to the necessary information.
VRF (Virtual routing and forwarding).
Almost everyone knows this type of routing instance. In its functionality, it is similar to that of the Cisco world and is used to implement MPLS-based services (for example, for L3VPN, 6VPE).
VRF is not a separate router inside the main router (or switch). VRF isolates the routing table and client interfaces from the main routing table and router interfaces, as well as from routing tables and other client interfaces. VRF configuration is as follows:
The functionality of this routing-instance supports all routing protocols, static routes, the label distribution protocol ldp (but rsvp is not supported), as well as the export and import of routes (from the routing protocols of the main routing-instance and other VRFs configured on the router).
In the configuration, you must specify the unique route-distinguisher value, route-targets (import and export) values, as well as the client-side interface (or interfaces) related to this routing-instance. The use of RT and RD is one of the key concepts in the implementation of l3vpn (respectively, and other technologies that use this logic, for example 6VPE) - these two values allow you to use overlapping client addressing (RD) and filter prefixes received from different clients and the subsequent Installing them in isolated routing tables (RT). This routing-instance creates its own routing table, which has the name instance_name.inet.0 or instance_name.inet6.0:
In the client's routing table, there are only routes to other sites of this client and its internal routes. That is, for the client, the provider's network is transparent and looks like a router, to which all its sites are connected.
In addition to the client's routing table, another routing table bgp.l3vpn.0 will be created on the router, in which all the routes received by the router using the bgp protocol (address family inet-vpn unicast) are installed according to the configured RT import values:
Note: in the case when it is necessary to run the ISIS protocol in this VRF, you need to configure an additional unit of the Lo logical interface with the NET address, and also attach this logical interface to the VRF:
Note: in the configuration there is a vrf-table-label command. By default, JunOS uses per-next-hop label allocation for client routes. The above command sets the label distribution mode to per-vrf, that is, all routes of a given vrf will have the same label. (If anyone is interested, I’ll write an article about this.)
We proceed to the next type of routing instance - Forwarding .
As you know, JunOS scares away many newcomers with long and at first glance incomprehensible configurations, especially if this newcomer came from the Cisco world. For example, if in Cisco you need to do policy based routing (PBR), then you write access-list and a simple route-map. Everything is more complicated in JunOS, but if you understand the Juniper approach, you will understand how much more elegant it is than the Tsiskovsky one. Why am I writing this? The fact is that the routing instance Forwarding was conceived specifically for PBR purposes (in the Juniper world, this type of routing is called filter based routing). The following is the configuration for this routing instance:
Everything is simple - not any RT, RD. This routing instance does not support specifying an interface and configuring a routing protocol *. The fact is that for the operation of the FBR this is not necessary. We make a static route with the next-hop we need, and we put a filter on the interface from which packets will arrive to the router, which, if, for example, the outgoing address matches, will send traffic through the configured routing instance along the static route, otherwise, the packet will “fly” according to the main routing table.
There is one thing, however, so that a routing instance can send a packet to the next-hop you need, we need it to have a route to this next-hop. To do this, we need to transfer the routes from the routing table inet.0 to the routing table of the configured routing instance (which will be called instance_name.inet.0), and not all routes are just necessary (we’ll also remember about directly connected). This is done using rib groups, the description can be found here .
This routing instance creates its own routing table, by manipulating the contents of which we can direct traffic along a route other than the main one.
* JunOS will allow you to configure for example ospf or isis in this type of routing instance (BGP is not supported), but since you do not have interfaces assigned to the routing instance, using the routing protocol will be pointless, and you can add routes from the main table via rib- groups without using a separate routing protocol.
Virtual router.
The routing instance virtual router functionality is similar to vrf-lite from the Cisco world. This routing instance allows you to run any routing protocols from rip to bgp, create GRE and ipsec tunnels, implement the nat and dhcp functionality, and also supports the LDP protocol (however, RSVP is not supported). The main objective of this routing instance is to isolate the client interface (s) and its routing table. The closest relative of virtual-router can be called routing instance no-forwarding (to be described below), their functionality is somewhat similar. But, the routing instance type that we are considering sets the routes to a separate routing table, which has the name instance_name.inet.0 (instance_name.inet6.0):
Only routes that are in this routing-instance are given to the client. Using rib groups, you can redistribute routes from the main routing table to the client's routing table or redistribute routes between virtual routers that live on the router.
This type of routing instance is used quite often. If we compare it with VRF, then this routing instance eliminates the need to configure RT and RD. An example configuration of this routing-instance is presented below:
The next type of routing instance is No-forwarding.
This type of routing instance, unlike the previous three, although it creates its own routing table, but installs all routes in the main default forwarding table.
The difference between fib and rib is that all routes, for example, the ospf protocol, get into rib (for example, there are two routes to the same prefix - both will be displayed in rib), but only the best of these routes will go to fib and will be used for traffic transfers (exceptions, for example, ECMP). Also rib is intended for storage and exchange of routing information between peers in the network and it is not convenient for sending traffic. Fib is just designed to quickly find the data necessary for sending traffic and makes it possible to implement hardware-based traffic processing.
This routing instance is used when it is necessary to segment the network at the third level (like VLAN). The configuration is presented below:
Note: auto-export must be configured in the main routing instance and routing instance no-forwarding, otherwise you will not get the expected result.
Let's see how this routing instance works. We have several configured routing instance:
It follows from the conclusion that we have three configured and one default routing instance (we do not consider private routing instance):
1.virtual-router with the virtual-router type (corresponds to the virtual-router.inet.0 routing table)
2.forward with the type forwarding (corresponds to the routing table forward.inet.0)
3.default (corresponds to the routing table inet.0)
4.no-frw with the type non-forwarding (corresponds to the routing table no-frw.inet.0)
So far, as usual - with Each routing instance has its own routing table.
Now let's see how things are going with the forwarding-table on the router:
Only forwarding-table is created for:
1.virtual-router.inet.0
2.forward.inet.0
3.default.inet.0
forwarding-table for no-frw.inet.0 does not exist, therefore routing instance no- forwarding installs its routes in forwarding-table default (more precisely, in addition to its routing table, routing instance no-forwarding exports its routes to defaul inet.0, from where they get into defaul fib).
Then the question arises - why do we need this routing instance? Unlike Cisco, on Juniper hardware you cannot run two copies of the same routing protocol in the same instance. That is, if in Cisco we can start the ospf 1 process and the ospf 2 process at the same time, then in JunOS at the [edit protocols] hierarchy level, there is no way to start two copies of the same process, for example OSPF (do not confuse them with area, they are like since there may be several). This routing instance is designed to run multiple copies of the same routing protocol.
The functionality of this routing instance supports all routing protocols, with the exception of BGP. The ldp or rsvp label allocation protocols are also not supported.
For completeness, consider this scheme (taken from the Juniper website):
So, suppose we want CE2 to communicate only with CE3, and accordingly, CE1 can only communicate with CE4. Here we will use routing instance no-forwarding.
We create two routing instance (1 and 2) with type no-forwarding on PE0 and PE2, specify the necessary interface in them and run ospf.
We create policies according to which the ospf routing instance 1 process, receiving routes from CE1, adds the tag 100 to these routes and exports to default rib inet.0, and the ospf routing instance 2 process adds the 200 tag to the routes received from CE2 and exports to default rib inet. 0.
That is, we received in inet.0 all routes from CE1 and CE2, and we can clearly distinguish which routes came from CE1 and which from CE2.
Further, these routes are transferred to PE2 along with tags. Using the policy, on PE2 in routing instance 1, we specify that only routes with a tag of 200 should be exported to CE3, and, accordingly, only routes with a tag of 100 should be exported to CE4. As a result, we got almost VLAN at the third level.
As we wanted, traffic exchange is possible between CE1 and CE4, and accordingly between CE2 and CE3; Why is traffic exchange impossible between CE1 and CE3? For a simple reason - CE1 does not have a route to CE2 or CE3. A similar picture will be on other routers of this topology.
At first glance, the considered routing instance is very similar to virtual-router. But I hope that now you understand that it is intended for other purposes and has less functionality.
VPLS.
The principle of operation of VPLS technology is not included in the text of this article, but will be partially affected by the explanations (otherwise nothing can be explained).
We need to implement Virtual Private LAN Service, we create this routing instance. In fact, it repeats functionally VRF (especially when using BGP signaling), but is intended for the implementation of L2 services. This type of routing instance allows you to automatically create a fully connected topology from virtual l2 connections between client sites. This routing instance, due to the lack of the need to run routing and label distribution protocols, does not support their configuration. Since this routing instance works with l2 and not IP addresses, the forwarding table stores mac addresses:
The following is a routing table for one of the clients (BGP signaling):
10.0.1.1:100:1:1/96 - this prefix denotes the client’s site and consists of:
1. 10.0.1.1:100 - RD
2. 1 - site-id
3. 1 - label block offcet (shift of the block of labels, if I’m interested, I can write a separate article on tagging when organizing VPLS)
In addition to the routing table presented above, JunOS will have another routing table bgp.l2vpn.0, in which all l2vpn routes of this PE router will be displayed (when using bgp as an alarm ):
The configuration of this routing instance depends on which signaling is used to organize the VPLS - BGP (Compell draft) or LDP (Martini). The configuration will change depending on your choice.
If we implement VPLS according to the Kompl draft (BGP signaling), then the configuration will look like this:
Since the Compell draft includes autodiscovery PE routers, in the configuration, you must specify RT and RD in addition to the interface. As I showed earlier, RD is used to search and identify PE routers to which client sites are connected. At the hierarchy level [edit routing-instance protocols vpls] it is necessary to specify the name of the site, its site-identifier (this can be specified by JunOS automatically, if specified in the configuration) and the maximum number of sites (site-range) of the client, and site-identifier must be less than site-range.
If we use LDP signaling (Martini), then the configuration will be a little simpler:
This VPLS technology does not support autodiscovery without an additional “crutch” *, therefore, in the basic configuration, only the interface to which the client is connected is specified, there is neither RT nor RD. At the hierarchy level [edit routing-instance protocols vpls], it is necessary to specify the loopbacks of all PE routers to which the client sites are connected, as well as the VPLS-ID, which must be the same for all VPLS routing instance of this client.
* To use autodiscovery in this case, you must use BGP using the address family bgp l2vpn auto-discovery-only. At the same time, you do not need to explicitly specify neighbors on PE routers, but then you need to configure RT, RD, as well as l2vpn-id:
You can check the status of the connections that this routing instance has established with the show vpls connections command:
From the client’s point of view, this technology will look like a switch to which the client’s sites are connected.
Layer 2 VPN
Junos has (at least I know) three ways to create l2vpn (unlike VPLS, l2vpn has a p2p topology). This routing-instance is close in configuration and signaling to VPLS BGP signaling. The configuration includes specifying rd and rt to search for PE routers and then establish a p2p connection:
Like her older brother routing-instance vpls, this routing-instance, by virtue of its purpose, does not imply the configuration of routing protocols.
The advantage of this routing-instance is its ease of configuration and, unlike other types of l2vpn, it has better scalability (other sites are easily added if necessary). Unlike VPLS, routing-instance l2vpn does not support cross-platform interaction (for example, between Juniper and Cisco).
This routing-instance does not make it possible to create VPLS, although it does make it possible to configure more than one virtual L2 connection (but this will not be a full-fledged VPLS).
The routing table looks almost the same as VPLS:
You can check the status of connections using the show l2vpn connections command, and the output will be similar to the output of show vpls connections (routing-instance VPLS).
Layer2-control
This routing-instance is designed to run the STP family protocol using VPLS Multihoming. Its application is very well described in this article , so I will not repeat it.
Virtual switch
In addition to routing, MX series routers can also perform functions unique to the switch. Initially, when configuring VLAN and trunk ports on an MX-series router, all VLANs and trunk interfaces fall into the same bridge domian, which is called default-switch routing-instance. MX series routers provide the ability to configure custom routing-instance virtual-switch:
This routing-instance allows you to implement the switch functionality on the router and isolates the interfaces and one or more VLANs. That is, a virtual switch allows segmentation of networks at the second level, without resorting to network segmentation at the third level (which will save us IP addresses). For each segment, you can run your own protocol from the STP family. MX series routers support protocols: STP, RSTP, MSTP, VSTP.
Thanks for attention!
Routing instance is a powerful tool of the JunOS operating system, which, when combined with c rib-groups, firewall filters and policy, can perform any task. Unfortunately, many engineers are not aware of the purpose of most routing instances, except for the painfully familiar VRF.
JunOS provides us with a large selection of routing instances available for configuration:
routing-instances {
routing-instance-name {
interface interface-name;
instance-type (forwarding | l2vpn | layer2-control | no-forwarding | virtual-router | virtual-switch | vpls | vrf);
}
}At the time of writing, the following types of routing instance are available for configuration:
1. VRF,
2. Forwarding,
3. Virtual router,
4. Nonforwarding,
5. VPLS,
6. Layer 2 VPN,
7. Layer2-control (MX Series routers only) ,
8. the Virtual switch statement (the MX the Series routers only),
9. Layer 2 Backhaul VPN (MX Series routers only) ( of which I will try to write a separate post).
If someone finds some kind of clerical or inaccuracies in the article (I am also a human being and I can be mistaken) or someone will have additions, please write personal messages with links to the necessary information.
VRF (Virtual routing and forwarding).
Almost everyone knows this type of routing instance. In its functionality, it is similar to that of the Cisco world and is used to implement MPLS-based services (for example, for L3VPN, 6VPE).
VRF is not a separate router inside the main router (or switch). VRF isolates the routing table and client interfaces from the main routing table and router interfaces, as well as from routing tables and other client interfaces. VRF configuration is as follows:
root@PE2# show routing-instances
6pe-2 {
instance-type vrf;
interface ge-0/0/3.101;
route-distinguisher 2001:31133;
vrf-target target:200:31133;
vrf-table-label;
routing-options {
router-id 101.101.101.101;
}
protocols {
ospf3 {
export isis-ce2-export;
area 0.0.0.0 {
interface ge-0/0/3.101;
}
}
}
}The functionality of this routing-instance supports all routing protocols, static routes, the label distribution protocol ldp (but rsvp is not supported), as well as the export and import of routes (from the routing protocols of the main routing-instance and other VRFs configured on the router).
In the configuration, you must specify the unique route-distinguisher value, route-targets (import and export) values, as well as the client-side interface (or interfaces) related to this routing-instance. The use of RT and RD is one of the key concepts in the implementation of l3vpn (respectively, and other technologies that use this logic, for example 6VPE) - these two values allow you to use overlapping client addressing (RD) and filter prefixes received from different clients and the subsequent Installing them in isolated routing tables (RT). This routing-instance creates its own routing table, which has the name instance_name.inet.0 or instance_name.inet6.0:
vrf1.inet.0: 12 destinations, 22 routes (12 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.0.0/30 *[OSPF/10] 01:59:31, metric 2
> to 10.0.1.1 via ge-0/0/0.0
10.1.1.1/32 *[OSPF/10] 01:59:31, metric 2
> to 10.0.1.1 via ge-0/0/0.0
10.2.2.2/32 *[OSPF/10] 01:59:31, metric 2
> to 10.0.1.1 via ge-0/0/0.0
In the client's routing table, there are only routes to other sites of this client and its internal routes. That is, for the client, the provider's network is transparent and looks like a router, to which all its sites are connected.
In addition to the client's routing table, another routing table bgp.l3vpn.0 will be created on the router, in which all the routes received by the router using the bgp protocol (address family inet-vpn unicast) are installed according to the configured RT import values:
bgp.l3vpn.0: 12 destinations, 9 routes (9 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
100:100:10.0.0.0/16
* 10.2.2.2 0 100 ?
100:100:10.0.1.1/32
* 10.2.2.2 0 100 ?
200:100:10.0.0.0/16
* 10.3.3.3 0 100 ?
Note: in the case when it is necessary to run the ISIS protocol in this VRF, you need to configure an additional unit of the Lo logical interface with the NET address, and also attach this logical interface to the VRF:
ce2-l3vpn {
instance-type vrf;
interface ge-0/0/2.0;
interface lo0.1; #в VRF добавлен unit 1 интерфейса Lo0
route-distinguisher 10.0.1.0:31133;
vrf-target target:10:31133;
protocols {
isis {
export isis-ce2-export;
interface ge-0/0/2.0;
interface lo0.1;
}
}
}
Note: in the configuration there is a vrf-table-label command. By default, JunOS uses per-next-hop label allocation for client routes. The above command sets the label distribution mode to per-vrf, that is, all routes of a given vrf will have the same label. (If anyone is interested, I’ll write an article about this.)
We proceed to the next type of routing instance - Forwarding .
As you know, JunOS scares away many newcomers with long and at first glance incomprehensible configurations, especially if this newcomer came from the Cisco world. For example, if in Cisco you need to do policy based routing (PBR), then you write access-list and a simple route-map. Everything is more complicated in JunOS, but if you understand the Juniper approach, you will understand how much more elegant it is than the Tsiskovsky one. Why am I writing this? The fact is that the routing instance Forwarding was conceived specifically for PBR purposes (in the Juniper world, this type of routing is called filter based routing). The following is the configuration for this routing instance:
[edit routing-instances]
root# show
forward {
instance-type forwarding;
routing-options {
static {
route 10.0.0.0/24 next-hop 10.0.1.1;
}
}
}
Everything is simple - not any RT, RD. This routing instance does not support specifying an interface and configuring a routing protocol *. The fact is that for the operation of the FBR this is not necessary. We make a static route with the next-hop we need, and we put a filter on the interface from which packets will arrive to the router, which, if, for example, the outgoing address matches, will send traffic through the configured routing instance along the static route, otherwise, the packet will “fly” according to the main routing table.
There is one thing, however, so that a routing instance can send a packet to the next-hop you need, we need it to have a route to this next-hop. To do this, we need to transfer the routes from the routing table inet.0 to the routing table of the configured routing instance (which will be called instance_name.inet.0), and not all routes are just necessary (we’ll also remember about directly connected). This is done using rib groups, the description can be found here .
This routing instance creates its own routing table, by manipulating the contents of which we can direct traffic along a route other than the main one.
* JunOS will allow you to configure for example ospf or isis in this type of routing instance (BGP is not supported), but since you do not have interfaces assigned to the routing instance, using the routing protocol will be pointless, and you can add routes from the main table via rib- groups without using a separate routing protocol.
Virtual router.
The routing instance virtual router functionality is similar to vrf-lite from the Cisco world. This routing instance allows you to run any routing protocols from rip to bgp, create GRE and ipsec tunnels, implement the nat and dhcp functionality, and also supports the LDP protocol (however, RSVP is not supported). The main objective of this routing instance is to isolate the client interface (s) and its routing table. The closest relative of virtual-router can be called routing instance no-forwarding (to be described below), their functionality is somewhat similar. But, the routing instance type that we are considering sets the routes to a separate routing table, which has the name instance_name.inet.0 (instance_name.inet6.0):
r6.inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
60.0.0.0/30 *[Direct/0] 00:11:18
> via ge-0/0/2.0
60.0.0.1/32 *[Local/0] 00:11:18
Local via ge-0/0/2.0
60.1.1.1/32 *[OSPF/10] 00:11:04, metric 2
> to 60.0.0.2 via ge-0/0/2.0
224.0.0.5/32 *[OSPF/10] 00:11:19, metric 1
MultiRecvOnly routes that are in this routing-instance are given to the client. Using rib groups, you can redistribute routes from the main routing table to the client's routing table or redistribute routes between virtual routers that live on the router.
This type of routing instance is used quite often. If we compare it with VRF, then this routing instance eliminates the need to configure RT and RD. An example configuration of this routing-instance is presented below:
r6 {
instance-type virtual-router;
interface ge-0/0/2.0;
}
protocols {
ospf {
export export-200;
area 0.0.0.0 {
interface all;
}
}
}
The next type of routing instance is No-forwarding.
This type of routing instance, unlike the previous three, although it creates its own routing table, but installs all routes in the main default forwarding table.
The difference between fib and rib is that all routes, for example, the ospf protocol, get into rib (for example, there are two routes to the same prefix - both will be displayed in rib), but only the best of these routes will go to fib and will be used for traffic transfers (exceptions, for example, ECMP). Also rib is intended for storage and exchange of routing information between peers in the network and it is not convenient for sending traffic. Fib is just designed to quickly find the data necessary for sending traffic and makes it possible to implement hardware-based traffic processing.
This routing instance is used when it is necessary to segment the network at the third level (like VLAN). The configuration is presented below:
[edit routing-instances]
root# show
noforward {
instance-type no-forwarding;
interface ge-0/0/3.0;
routing-options {
auto-export;
}
protocols {
ospf {
export export-100;
area 0.0.0.0 {
interface ge-0/0/3.0;
}
}
}
}
Note: auto-export must be configured in the main routing instance and routing instance no-forwarding, otherwise you will not get the expected result.
Let's see how this routing instance works. We have several configured routing instance:
root> show route instance summary
Instance Type
Primary RIB Active/holddown/hidden
master forwarding
inet.0 19/0/0
__juniper_private1__ forwarding
__juniper_private1__.inet.0 7/0/0
__juniper_private2__ forwarding
__juniper_private2__.inet.0 0/0/1
__master.anon__ forwarding
forward forwarding
forward.inet.0 7/0/0
no-frw non-forwarding
no-frw.inet.0 16/0/0
virtual-router virtual-router
virtual-router.inet.0 14/0/0
It follows from the conclusion that we have three configured and one default routing instance (we do not consider private routing instance):
1.virtual-router with the virtual-router type (corresponds to the virtual-router.inet.0 routing table)
2.forward with the type forwarding (corresponds to the routing table forward.inet.0)
3.default (corresponds to the routing table inet.0)
4.no-frw with the type non-forwarding (corresponds to the routing table no-frw.inet.0)
So far, as usual - with Each routing instance has its own routing table.
Now let's see how things are going with the forwarding-table on the router:
root> show route forwarding-table | match table
Routing table: default.inet
Routing table: __master.anon__.inet
Routing table: forward.inet
Routing table: virtual-router.inet
Routing table: default.iso
Routing table: __master.anon__.iso
Routing table: forward.iso
Routing table: virtual-router.iso
Routing table: default.inet6
Routing table: __master.anon__.inet6
Routing table: forward.inet6
Routing table: virtual-router.inet6
Routing table: default.mpls
Routing table: :mpls-oam.mpls
Routing table: default.ethernet-switching
Routing table: default.vmembers
Routing table: default.device-route
Routing table: default.MSTI
Routing table: default.dhcp-snooping
Only forwarding-table is created for:
1.virtual-router.inet.0
2.forward.inet.0
3.default.inet.0
forwarding-table for no-frw.inet.0 does not exist, therefore routing instance no- forwarding installs its routes in forwarding-table default (more precisely, in addition to its routing table, routing instance no-forwarding exports its routes to defaul inet.0, from where they get into defaul fib).
Then the question arises - why do we need this routing instance? Unlike Cisco, on Juniper hardware you cannot run two copies of the same routing protocol in the same instance. That is, if in Cisco we can start the ospf 1 process and the ospf 2 process at the same time, then in JunOS at the [edit protocols] hierarchy level, there is no way to start two copies of the same process, for example OSPF (do not confuse them with area, they are like since there may be several). This routing instance is designed to run multiple copies of the same routing protocol.
The functionality of this routing instance supports all routing protocols, with the exception of BGP. The ldp or rsvp label allocation protocols are also not supported.
For completeness, consider this scheme (taken from the Juniper website):
So, suppose we want CE2 to communicate only with CE3, and accordingly, CE1 can only communicate with CE4. Here we will use routing instance no-forwarding.
We create two routing instance (1 and 2) with type no-forwarding on PE0 and PE2, specify the necessary interface in them and run ospf.
We create policies according to which the ospf routing instance 1 process, receiving routes from CE1, adds the tag 100 to these routes and exports to default rib inet.0, and the ospf routing instance 2 process adds the 200 tag to the routes received from CE2 and exports to default rib inet. 0.
That is, we received in inet.0 all routes from CE1 and CE2, and we can clearly distinguish which routes came from CE1 and which from CE2.
Further, these routes are transferred to PE2 along with tags. Using the policy, on PE2 in routing instance 1, we specify that only routes with a tag of 200 should be exported to CE3, and, accordingly, only routes with a tag of 100 should be exported to CE4. As a result, we got almost VLAN at the third level.
As we wanted, traffic exchange is possible between CE1 and CE4, and accordingly between CE2 and CE3; Why is traffic exchange impossible between CE1 and CE3? For a simple reason - CE1 does not have a route to CE2 or CE3. A similar picture will be on other routers of this topology.
At first glance, the considered routing instance is very similar to virtual-router. But I hope that now you understand that it is intended for other purposes and has less functionality.
VPLS.
The principle of operation of VPLS technology is not included in the text of this article, but will be partially affected by the explanations (otherwise nothing can be explained).
We need to implement Virtual Private LAN Service, we create this routing instance. In fact, it repeats functionally VRF (especially when using BGP signaling), but is intended for the implementation of L2 services. This type of routing instance allows you to automatically create a fully connected topology from virtual l2 connections between client sites. This routing instance, due to the lack of the need to run routing and label distribution protocols, does not support their configuration. Since this routing instance works with l2 and not IP addresses, the forwarding table stores mac addresses:
Routing table: vpls_bgp_signalig.vpls
VPLS:
Destination Type RtRef Next hop Type Index NhRef Netif
default perm 0 rjct 587 1
ge-0/0/3.0 user 0 comp 580 2
lsi.1048577 user 0 comp 581 2
ca:04:76:68:00:1c/48 dynm 0 ucst 577 3 ge-0/0/3.0
ca:05:79:f4:00:1c/48 dynm 0 indr 262142 5
10.0.0.2 Push 262146, Push 17(top) 572 2 ge-0/0/0.0
ca:08:5f:e4:00:1c/48 dynm 0 indr 262142 5
10.0.0.2 Push 262146, Push 17(top) 572 2 ge-0/0/0.0
The following is a routing table for one of the clients (BGP signaling):
customer1.site1.l2vpn.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.1.1:100:1:1/96
*[L2VPN/170/-101] 04:00:26, metric2 1
Indirect
10.0.1.2:100:2:1/96
*[BGP/170] 00:04:23, localpref 100, from 1.1.1.254
AS path: I
> to 20.0.0.2 via ge-0/0/1.0
10.0.1.3:100:3:1/96
*[BGP/170] 00:04:54, localpref 100, from 1.1.1.254
AS path: I
> to 20.0.2.2 via ge-0/0/0.0, Push 299808
to 20.0.1.2 via ge-0/0/2.0, Push 299808
10.0.1.1:100:1:1/96 - this prefix denotes the client’s site and consists of:
1. 10.0.1.1:100 - RD
2. 1 - site-id
3. 1 - label block offcet (shift of the block of labels, if I’m interested, I can write a separate article on tagging when organizing VPLS)
In addition to the routing table presented above, JunOS will have another routing table bgp.l2vpn.0, in which all l2vpn routes of this PE router will be displayed (when using bgp as an alarm ):
bgp.l2vpn.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
30.0.1.1:100:102:97/96
*[BGP/170] 00:04:55, localpref 100, from 1.1.1.254
AS path: I
> to 20.0.2.2 via ge-0/0/0.0, Push 299808
to 20.0.1.2 via ge-0/0/2.0, Push 299808
10.0.1.2:100:2:1/96
*[BGP/170] 00:04:23, localpref 100, from 1.1.1.254
AS path: I
> to 20.0.0.2 via ge-0/0/1.0
The configuration of this routing instance depends on which signaling is used to organize the VPLS - BGP (Compell draft) or LDP (Martini). The configuration will change depending on your choice.
If we implement VPLS according to the Kompl draft (BGP signaling), then the configuration will look like this:
routing-instances {
customer1.site1 {
instance-type vpls;
interface ge-0/0/3.0;
route-distinguisher 10.0.1.1:100;
vrf-target target:10.0.1.0:100;
protocols {
vpls {
no-tunnel-services;
site site1 {
site-range 10;
site-identifier 1;
interface ge-0/0/3.0;
}
}
}
} Since the Compell draft includes autodiscovery PE routers, in the configuration, you must specify RT and RD in addition to the interface. As I showed earlier, RD is used to search and identify PE routers to which client sites are connected. At the hierarchy level [edit routing-instance protocols vpls] it is necessary to specify the name of the site, its site-identifier (this can be specified by JunOS automatically, if specified in the configuration) and the maximum number of sites (site-range) of the client, and site-identifier must be less than site-range.
If we use LDP signaling (Martini), then the configuration will be a little simpler:
ce3-vpls-ldp {
instance-type vpls;
interface ge-0/0/3.0;
protocols {
vpls {
no-tunnel-services;
vpls-id 101;
neighbor 1.1.1.1;
neighbor 2.2.2.2;
}
}
}This VPLS technology does not support autodiscovery without an additional “crutch” *, therefore, in the basic configuration, only the interface to which the client is connected is specified, there is neither RT nor RD. At the hierarchy level [edit routing-instance protocols vpls], it is necessary to specify the loopbacks of all PE routers to which the client sites are connected, as well as the VPLS-ID, which must be the same for all VPLS routing instance of this client.
* To use autodiscovery in this case, you must use BGP using the address family bgp l2vpn auto-discovery-only. At the same time, you do not need to explicitly specify neighbors on PE routers, but then you need to configure RT, RD, as well as l2vpn-id:
vpls100 {
instance-type vpls;
interface ge-1/1/0.100;
l2vpn-id l2vpn-id:100:200;
vrf-target target:100:208;
protocols {
vpls {
no-tunnel-services;
}
}
}
You can check the status of the connections that this routing instance has established with the show vpls connections command:
[edit]
root# run show vpls connections
Layer-2 VPN connections:
Legend for connection status (St)
EI -- encapsulation invalid NC -- interface encapsulation not CCC/TCC/VPLS
EM -- encapsulation mismatch WE -- interface and instance encaps not same
VC-Dn -- Virtual circuit down NP -- interface hardware not present
CM -- control-word mismatch -> -- only outbound connection is up
CN -- circuit not provisioned <- -- only inbound connection is up
OR -- out of range Up -- operational
OL -- no outgoing label Dn -- down
LD -- local site signaled down CF -- call admission control failure
RD -- remote site signaled down SC -- local and remote site ID collision
LN -- local site not designated LM -- local site ID not minimum designated
RN -- remote site not designated RM -- remote site ID not minimum designated
XX -- unknown connection status IL -- no incoming label
MM -- MTU mismatch MI -- Mesh-Group ID not available
BK -- Backup connection ST -- Standby connection
PF -- Profile parse failure PB -- Profile busy
RS -- remote site standby SN -- Static Neighbor
VM -- VLAN ID mismatch
Legend for interface status
Up -- operational
Dn -- down
Instance: customer1.site1
Local site: site1 (1)
connection-site Type St Time last up # Up trans
2 rmt Up Nov 2 00:25:33 2015 1
Remote PE: 1.1.1.2, Negotiated control-word: No
Incoming label: 262154, Outgoing label: 262153
Local interface: lsi.1049099, Status: Up, Encapsulation: VPLS
Description: Intf - vpls customer1.site1 local site 1 remote site 2
3 rmt Up Nov 2 00:25:01 2015 1
Remote PE: 1.1.1.3, Negotiated control-word: No
Incoming label: 262155, Outgoing label: 262153
Local interface: lsi.1049098, Status: Up, Encapsulation: VPLS
Description: Intf - vpls customer1.site1 local site 1 remote site 3
From the client’s point of view, this technology will look like a switch to which the client’s sites are connected.
Layer 2 VPN
Junos has (at least I know) three ways to create l2vpn (unlike VPLS, l2vpn has a p2p topology). This routing-instance is close in configuration and signaling to VPLS BGP signaling. The configuration includes specifying rd and rt to search for PE routers and then establish a p2p connection:
root# show
instance-type l2vpn;
interface ge-0/0/3.0;
route-distinguisher 100:100;
vrf-target target:1:1;
protocols {
l2vpn {
encapsulation-type ethernet-vlan;
no-control-word;
site site2 {
site-identifier 2;
interface ge-0/0/3.0 {
remote-site-id 1;
}
}
}
}
Like her older brother routing-instance vpls, this routing-instance, by virtue of its purpose, does not imply the configuration of routing protocols.
The advantage of this routing-instance is its ease of configuration and, unlike other types of l2vpn, it has better scalability (other sites are easily added if necessary). Unlike VPLS, routing-instance l2vpn does not support cross-platform interaction (for example, between Juniper and Cisco).
This routing-instance does not make it possible to create VPLS, although it does make it possible to configure more than one virtual L2 connection (but this will not be a full-fledged VPLS).
The routing table looks almost the same as VPLS:
root@PE1> show route table vpn.l2vpn.0
vpn1.l2vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
100:100:1:1/96
*[BGP/170] 00:14:00, localpref 100, from 10.1.1.1
AS path: I
> to 10.0.0.2 via ge-0/0/3.0, label-switched-path pe1_to_pe2
200:200:1:2/96
*[L2VPN/170/-101] 00:17:35, metric2 1
IndirectYou can check the status of connections using the show l2vpn connections command, and the output will be similar to the output of show vpls connections (routing-instance VPLS).
Layer2-control
This routing-instance is designed to run the STP family protocol using VPLS Multihoming. Its application is very well described in this article , so I will not repeat it.
Virtual switch
In addition to routing, MX series routers can also perform functions unique to the switch. Initially, when configuring VLAN and trunk ports on an MX-series router, all VLANs and trunk interfaces fall into the same bridge domian, which is called default-switch routing-instance. MX series routers provide the ability to configure custom routing-instance virtual-switch:
[edit]
routing-instances {
routing-instance-name (
instance-type virtual-switch;
bridge-domains {
bridge-domain-name {
domain-type bridge;
interface interface-name;
vlan-id (all | none | number);
vlan-id-list [ vlan-id-numbers ];
vlan-tags outer number inner number;
}
}
protocols {
mstp {
...mstp-configuration ...
}
}
}
}This routing-instance allows you to implement the switch functionality on the router and isolates the interfaces and one or more VLANs. That is, a virtual switch allows segmentation of networks at the second level, without resorting to network segmentation at the third level (which will save us IP addresses). For each segment, you can run your own protocol from the STP family. MX series routers support protocols: STP, RSTP, MSTP, VSTP.
Thanks for attention!