Juniper routing instances
Routing Instance is a collection of routing tables, interfaces, and parameters for routing protocols. Routing protocols control information in the routing tables, and in one routing instance there can be both IPv4 and IPv6 routes at the same time, 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 physical interface, not divided into units, cannot be attached to different routing instance ).
Routing instance is the most powerful tool of the JunOS operating system, which allows you to perform any task when sharing c rib-groups, firewall filters and policy. Unfortunately, many engineers are unaware of the appointment of most of the routing instances, except for all the painfully familiar VRF.
JunOS provides us with a large selection of routing instances available for configuration:
At the time of this 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. Virtual switch (MX Series routers only)
9. Layer 2 Backhaul VPN (MX Series routers only) (I'll try to write a separate post about it).
')
If someone finds out any mistakes or inaccuracies in the article (I am also a person 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 terms of its functionality, it is similar to that of the Cisco world and is used to implement services based on MPLS (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 the routing tables and interfaces of other clients. The VRF configuration is as follows:
The functionality of this routing-instance supports all routing protocols, static routes, the ldp label distribution protocol (but rsvp is not supported), as well as export and import of routes (from the routing protocols of the main routing-instance and other VRF configured on the router).
In the configuration, you must specify the unique value of route-distinguisher, route-targets values ​​(import and export), as well as the interface (or interfaces) towards the client, related to this routing-instance. Using RT and RD is one of the key concepts in the implementation of l3vpn (and other technologies that use this logic, for example, 6VPE, respectively) - these two values ​​allow you to use overlapping client addressing (RD) and filter the prefixes received from different clients and follow installing them into 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 has the appearance of a router to which all its sites are connected.
In addition to the client's routing table, another bgp.l3vpn.0 routing table will be created on the router, into which all routes received by the bgp router (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, then an additional unit of the Lo logical interface must be configured with the NET address, and this logic interface must be attached to the VRF:
Note: there is a vrf-table-label command in the configuration. By default, JunOS uses per-next-hop label allocation for client routes. The above command translates the label distribution mode into per-vrf, that is, all routes of this vrf will have the same label. (If anyone is interested, I will write an article about it.)
Moving on to the next type of routing instance - Forwarding .
As you know, JunOS deters many newbies with long and seemingly incomprehensible configurations, especially if this newcomer comes from the Cisco world. For example, if at Cisco you need to do policy based routing (PBR), then you write an access-list and a simple route-map. In JunOS, everything is more complicated, but by understanding Juniper's approach, you will understand how elegant he is than tsiskovskogo. Why am I writing this? The fact is that routing instance Forwarding was conceived precisely for PBR purposes (in the Juniper world, this kind of routing is called filter based routing). Below is the configuration of this routing instance:
It's simple - not any RT, RD. This routing instance does not support interface specification and configuration of the routing protocol *. The fact is that for the work of the FBR this is not necessary. We make a static route with the next-hop we need, and on the interface from which the packets will arrive at the router, we hang the filter, which in case of coincidence, for example, of the outgoing address, will send traffic through the configured routing instance along the static route, Otherwise, the package will “fly” according to the main routing table.
There is one thing but that the routing instance can send a packet to the desired next-hop, we need it to have a route to this next-hop. To do this, we need to transfer the routes from the inet.0 routing table to the routing table of the configured routing instance (which will be called instance_name.inet.0), and not all the routes are necessary (don't forget about directly connected). This is done with the help of the rib groups, the description can be read here .
This routing instance creates its own routing table, by manipulating the contents of which we can send traffic along a different route.
* 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 routing instance, using the routing protocol will be meaningless, and you can add routes from the main table via rib- groups without using a separate routing protocol.
Virtual router.
Functional routing instance virtual router is similar to vrf-lite from the world of Cisco. 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 task of this routing instance is to isolate the client’s 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 type of routing instance we are considering sets the routes to a separate routing table that has the name instance_name.inet.0 (instance_name.inet6.0):
The client is given only the routes that are in this routing-instance. With the help of 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 to compare it with VRF, then this routing instance is free from 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, in contrast to the three previous ones, although it creates its own routing table, but installs all routes into the main default forwarding table.
The difference between fib and rib is that all routes for example the ospf protocol fall into rib (for example, there are two routes to the same prefix - both will be mapped to rib), but only the best of these routes will fall into fib and will be used for traffic transfer (exceptions, for example ECMP). Also rib is designed for storing and exchanging 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 perform network segmentation at the third level (like VLAN). The configuration is presented below:
Note: auto-export must be configured to basic routing instance and routing instance no-forwarding, otherwise you will not get the expected result.
Let's look at how this routing instance works. We have several configured routing instances:
From the conclusion that we have three configured and one default routing instance (we do not consider private routing instance):
1.virtual-router with type virtual-router (corresponds to the routing table of virtual-router.inet.0)
2.forward with the type of forwarding (corresponds to the routing table forward.inet.0)
3.default (corresponds to the inet.0 routing table)
4.no-frw with non-forwarding type (corresponds to the no-frw.inet.0 routing table)
While everything is as usual - each routing instance has its own routing table.
Now let's see how things are with forwarding-table on the router:
Only forwarding table was 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 to forwarding-table default (more precisely, in addition to its routing table, routing instance no-forwarding exports its routes to defaul inet. 0, whence they get into defaul fib).
Then the question arises - why do we need this routing instance? Unlike Cisco, you cannot run two copies of the same routing protocol in the same instance on Juniper hardware. That is, if at Cisco we can start the ospf 1 process and the ospf 2 process at the same time, then at JunOS at the level of the hierarchy [edit protocols], there is no possibility to run two copies of the same process, for example, OSPF (do not confuse with the area, since there may be several). This routing instance is designed just to run multiple copies of a single routing protocol.
The functionality of this routing instance supports all routing protocols, with the exception of BGP. Not supported and distribution protocols labels ldp or rsvp.
For completeness, consider the following scheme (taken from the site Juniper):
So, suppose that we want CE2 to communicate only with CE3, and, accordingly, CE1 can communicate only with CE4. This is where we will use the routing instance no-forwarding.
We create two routing instance (1 and 2) with no-forwarding type on PE0 and PE2, specify the necessary interface in them and start 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 it to default rib inet.0, and the ospf routing instance 2 process adds the tag 200 to the routes received from CE2 and exports it to default rib inet.0.
That is, we received all the routes from CE1 and CE2 in inet.0, and we can clearly distinguish which routes came from CE1 and which routes came from CE2.
Further, these routes are transmitted to PE2 along with tags. With the help of the policy, on PE2 in routing instance 1 we indicate 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 received practically VLAN at the third level.
As we wanted, traffic exchange is possible between CE1 and CE4, and accordingly between CE2 and CE3; Why is there no traffic exchange between CE1 and CE3? For a simple reason - CE1 does not have a route to CE2 or CE3. A similar picture will be on the rest of the 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 the VPLS technology is not included in the text of this article, but will be partially affected during the explanations (otherwise nothing can be explained).
We need to implement the Virtual Private LAN Service, we create this routing instance. In essence, it repeats the functional VRF (especially when using BGP signaling), but it 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 protocols and label distribution, does not support their configuration. Since this routing instance works with l2 and not IP addresses, the forwarding table stores the mac addresses:
Below is the routing table of 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 a block of labels, if anyone is interested, I can write a separate article about operations with labels when organizing VPLS)
In addition to the above routing table, JunOS will have another bgp.l2vpn.0 routing table, which will display all l2vpn routes of this PE router (when using bgp as an alarm):
The configuration of this routing instance depends on what kind of signaling is used to organize the VPLS - BGP (draft CompELLA) or LDP (Martini). Depending on your choice, the configuration will vary.
If we implement VPLS according to the Compell Draft (BGP signaling), then the configuration will look like this:
Since Compella's Draft includes autodiscovery PE routers, in the configuration, besides the interface, specify RT and RD. As I showed earlier, RD is used to find and identify PE routers to which client sites are connected. At the hierarchy level [edit routing-instance protocols vpls], you must specify the site name, its site-identifier (this JunOS can be set 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 bit 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, neither RT nor RD. At the hierarchy level [edit routing-instance protocols vpls], you must specify the loopbacks of all PE routers to which the client's 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 address family bgp l2vpn auto-discovery-only. At the same time, it is not necessary to explicitly specify neighbors on PE routers, but then you need to configure RT, RD, and also l2vpn-id:
You can check the status of the connections that this routing instance has established using the show vpls connections command:
From the client’s point of view, this technology will be in the form of a switch to which client sites are connected.
Layer 2 VPN
In Junos, there are (in any case, I know) three ways to create l2vpn (unlike VPLS, l2vpn has the p2p topology). This routing-instance is similar in configuration and signaling to VPLS BGP signaling. The configuration provides an indication of rd and rt to search for PE routers and then establish a p2p connection:
Like its older brother, the routing-instance vpls, this routing-instance, by virtue of its purpose, does not imply setting up routing protocols.
The advantage of this routing-instance is the ease of configuration and, unlike other types of l2vpn, has better scalability (if necessary, other sites are easily added). Unlike VPLS, routing-instance l2vpn does not support cross-platform interaction (for example, between Juniper and Cisco).
This routing-instance does not allow you to create a VPLS, although it does allow you 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 connection status using the show l2vpn connections command, and the output will be similar to the show vpls connections output (routing-instance VPLS).
Layer2-control
This routing-instance is designed to run the STP family protocol when using VPLS Multihoming. Its use is very well described in this article , so I will not repeat.
Virtual switch
In addition to routing, MX series routers can perform functions unique to the switch. Initially, when configuring VLAN and trunk ports on an MX-series router, all VLAN and trunk interfaces fall into one bridge domian, 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 switch functionality on the router and isolates interfaces and one or more VLANs. That is, virtual switch allows you to 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 the most powerful tool of the JunOS operating system, which allows you to perform any task when sharing c rib-groups, firewall filters and policy. Unfortunately, many engineers are unaware of the appointment of most of the routing instances, except for all 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 this 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. Virtual switch (MX Series routers only)
9. Layer 2 Backhaul VPN (MX Series routers only) (I'll try to write a separate post about it).
')
If someone finds out any mistakes or inaccuracies in the article (I am also a person 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 terms of its functionality, it is similar to that of the Cisco world and is used to implement services based on MPLS (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 the routing tables and interfaces of other clients. The 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 ldp label distribution protocol (but rsvp is not supported), as well as export and import of routes (from the routing protocols of the main routing-instance and other VRF configured on the router).
In the configuration, you must specify the unique value of route-distinguisher, route-targets values ​​(import and export), as well as the interface (or interfaces) towards the client, related to this routing-instance. Using RT and RD is one of the key concepts in the implementation of l3vpn (and other technologies that use this logic, for example, 6VPE, respectively) - these two values ​​allow you to use overlapping client addressing (RD) and filter the prefixes received from different clients and follow installing them into 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 has the appearance of a router to which all its sites are connected.
In addition to the client's routing table, another bgp.l3vpn.0 routing table will be created on the router, into which all routes received by the bgp router (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, then an additional unit of the Lo logical interface must be configured with the NET address, and this logic interface must be attached 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: there is a vrf-table-label command in the configuration. By default, JunOS uses per-next-hop label allocation for client routes. The above command translates the label distribution mode into per-vrf, that is, all routes of this vrf will have the same label. (If anyone is interested, I will write an article about it.)
Moving on to the next type of routing instance - Forwarding .
As you know, JunOS deters many newbies with long and seemingly incomprehensible configurations, especially if this newcomer comes from the Cisco world. For example, if at Cisco you need to do policy based routing (PBR), then you write an access-list and a simple route-map. In JunOS, everything is more complicated, but by understanding Juniper's approach, you will understand how elegant he is than tsiskovskogo. Why am I writing this? The fact is that routing instance Forwarding was conceived precisely for PBR purposes (in the Juniper world, this kind of routing is called filter based routing). Below is the configuration of 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; } } } It's simple - not any RT, RD. This routing instance does not support interface specification and configuration of the routing protocol *. The fact is that for the work of the FBR this is not necessary. We make a static route with the next-hop we need, and on the interface from which the packets will arrive at the router, we hang the filter, which in case of coincidence, for example, of the outgoing address, will send traffic through the configured routing instance along the static route, Otherwise, the package will “fly” according to the main routing table.
There is one thing but that the routing instance can send a packet to the desired next-hop, we need it to have a route to this next-hop. To do this, we need to transfer the routes from the inet.0 routing table to the routing table of the configured routing instance (which will be called instance_name.inet.0), and not all the routes are necessary (don't forget about directly connected). This is done with the help of the rib groups, the description can be read here .
This routing instance creates its own routing table, by manipulating the contents of which we can send traffic along a different route.
* 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 routing instance, using the routing protocol will be meaningless, and you can add routes from the main table via rib- groups without using a separate routing protocol.
Virtual router.
Functional routing instance virtual router is similar to vrf-lite from the world of Cisco. 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 task of this routing instance is to isolate the client’s 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 type of routing instance we are considering sets the routes to a separate routing table that 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 MultiRecv The client is given only the routes that are in this routing-instance. With the help of 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 to compare it with VRF, then this routing instance is free from 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, in contrast to the three previous ones, although it creates its own routing table, but installs all routes into the main default forwarding table.
The difference between fib and rib is that all routes for example the ospf protocol fall into rib (for example, there are two routes to the same prefix - both will be mapped to rib), but only the best of these routes will fall into fib and will be used for traffic transfer (exceptions, for example ECMP). Also rib is designed for storing and exchanging 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 perform network segmentation 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 to basic routing instance and routing instance no-forwarding, otherwise you will not get the expected result.
Let's look at how this routing instance works. We have several configured routing instances:
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 From the conclusion that we have three configured and one default routing instance (we do not consider private routing instance):
1.virtual-router with type virtual-router (corresponds to the routing table of virtual-router.inet.0)
2.forward with the type of forwarding (corresponds to the routing table forward.inet.0)
3.default (corresponds to the inet.0 routing table)
4.no-frw with non-forwarding type (corresponds to the no-frw.inet.0 routing table)
While everything is as usual - each routing instance has its own routing table.
Now let's see how things are with 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 was 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 to forwarding-table default (more precisely, in addition to its routing table, routing instance no-forwarding exports its routes to defaul inet. 0, whence they get into defaul fib).
Then the question arises - why do we need this routing instance? Unlike Cisco, you cannot run two copies of the same routing protocol in the same instance on Juniper hardware. That is, if at Cisco we can start the ospf 1 process and the ospf 2 process at the same time, then at JunOS at the level of the hierarchy [edit protocols], there is no possibility to run two copies of the same process, for example, OSPF (do not confuse with the area, since there may be several). This routing instance is designed just to run multiple copies of a single routing protocol.
The functionality of this routing instance supports all routing protocols, with the exception of BGP. Not supported and distribution protocols labels ldp or rsvp.
For completeness, consider the following scheme (taken from the site Juniper):
So, suppose that we want CE2 to communicate only with CE3, and, accordingly, CE1 can communicate only with CE4. This is where we will use the routing instance no-forwarding.
We create two routing instance (1 and 2) with no-forwarding type on PE0 and PE2, specify the necessary interface in them and start 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 it to default rib inet.0, and the ospf routing instance 2 process adds the tag 200 to the routes received from CE2 and exports it to default rib inet.0.
That is, we received all the routes from CE1 and CE2 in inet.0, and we can clearly distinguish which routes came from CE1 and which routes came from CE2.
Further, these routes are transmitted to PE2 along with tags. With the help of the policy, on PE2 in routing instance 1 we indicate 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 received practically VLAN at the third level.
As we wanted, traffic exchange is possible between CE1 and CE4, and accordingly between CE2 and CE3; Why is there no traffic exchange between CE1 and CE3? For a simple reason - CE1 does not have a route to CE2 or CE3. A similar picture will be on the rest of the 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 the VPLS technology is not included in the text of this article, but will be partially affected during the explanations (otherwise nothing can be explained).
We need to implement the Virtual Private LAN Service, we create this routing instance. In essence, it repeats the functional VRF (especially when using BGP signaling), but it 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 protocols and label distribution, does not support their configuration. Since this routing instance works with l2 and not IP addresses, the forwarding table stores the 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 Below is the routing table of 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 a block of labels, if anyone is interested, I can write a separate article about operations with labels when organizing VPLS)
In addition to the above routing table, JunOS will have another bgp.l2vpn.0 routing table, which will display all l2vpn routes of this PE router (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 what kind of signaling is used to organize the VPLS - BGP (draft CompELLA) or LDP (Martini). Depending on your choice, the configuration will vary.
If we implement VPLS according to the Compell 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 Compella's Draft includes autodiscovery PE routers, in the configuration, besides the interface, specify RT and RD. As I showed earlier, RD is used to find and identify PE routers to which client sites are connected. At the hierarchy level [edit routing-instance protocols vpls], you must specify the site name, its site-identifier (this JunOS can be set 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 bit 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, neither RT nor RD. At the hierarchy level [edit routing-instance protocols vpls], you must specify the loopbacks of all PE routers to which the client's 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 address family bgp l2vpn auto-discovery-only. At the same time, it is not necessary to explicitly specify neighbors on PE routers, but then you need to configure RT, RD, and also 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 using 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 be in the form of a switch to which client sites are connected.
Layer 2 VPN
In Junos, there are (in any case, I know) three ways to create l2vpn (unlike VPLS, l2vpn has the p2p topology). This routing-instance is similar in configuration and signaling to VPLS BGP signaling. The configuration provides an indication of 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 its older brother, the routing-instance vpls, this routing-instance, by virtue of its purpose, does not imply setting up routing protocols.
The advantage of this routing-instance is the ease of configuration and, unlike other types of l2vpn, has better scalability (if necessary, other sites are easily added). Unlike VPLS, routing-instance l2vpn does not support cross-platform interaction (for example, between Juniper and Cisco).
This routing-instance does not allow you to create a VPLS, although it does allow you 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 Indirect You can check the connection status using the show l2vpn connections command, and the output will be similar to the show vpls connections output (routing-instance VPLS).
Layer2-control
This routing-instance is designed to run the STP family protocol when using VPLS Multihoming. Its use is very well described in this article , so I will not repeat.
Virtual switch
In addition to routing, MX series routers can perform functions unique to the switch. Initially, when configuring VLAN and trunk ports on an MX-series router, all VLAN and trunk interfaces fall into one bridge domian, 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 switch functionality on the router and isolates interfaces and one or more VLANs. That is, virtual switch allows you to 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!
Source: https://habr.com/ru/post/275119/
All Articles