March 18, 2015 at 08:39Juniper tincture: preparing Juniper SRX. Part 3: Virtual Routers
- Tutorial
juniper - juniper (eng.) We
continue to prepare tincture from juniper. How we started, you can read here and here . Today, we touch a little such a convenient thing as Virtual Routers, and think about how to use it with the greatest benefit.
Contents:
Part 1: Introducing
Part 2: IPSec
Part 3: Virtual Routers
Juniper has a Routing Instance entity type designed for traffic manipulation (routing and encapsulation). RIs allow you to "split" one router into several smaller ones, while each instance will process the traffic "in its own way", independently of the others and with different capabilities. This is useful for organizing all kinds of VPNs when you need to isolate several clients from each other and resolve them according to different rules. At the same time, information about the VPN can be exchanged with other routers (for example, when organizing MPLS VPN).
* Forwarding - Serves for building special filter-based forwarding applications (well, or policy-based routing in Cisco terminology). At the same time, the interfaces are not tied to the RI, but remain in the default RI.
* Layer 2 virtual private network (VPN) - Used to organize MPLS L2VPN.
* Nonforwarding - All routes and interfaces are placed in the main routing instance, but you can "divide" the main routing table into several smaller ones.
* VPN routing and forwarding (VRF)- Used to organize L3VPN. It contains not only a routing table, but also a switching table (forwarding table). At the same time, traffic from the interface is displayed in RI one-to-one, which allows you to send and receive routing labels, receiving a distributed VPN. Using dynamic routing protocols (BGP, OSPF or ISIS), you can organize the exchange of information between PE (provider edge) and CE (client edge) in such a way that each of them will receive (and give) routes only inside its “own” VPN.
* Virtual router- Similar to VRF, but does not have options such as VRF import, VRF export, VRF target, or route distinguisher. Accordingly, it is not suitable for creating L3VPN, because a separate routing table "lives" only within the same router. Due to its simplicity, it is used much more often than its "older brother".
* Virtual private LAN service (VPLS) - An entity for organizing multipoint distributed L2VPN on top of MPLS. For the client it will look like a virtual switch, to the ports of which its borderline (CE) devices are connected.
We will not look at all this magnificence right away, but we will only deal with VR. What is this all about? The description shows that this is a slightly simplified version of VRF, in fact - VRF-lite from the Cisco world. Logical tunnels and rib-groups are supported for exchanging routes and connecting VR to each other. Of course, routing protocols (ospf, bgp, isis) are configured separately for each VR. Each VR requires its own Security zone (you cannot place interfaces from different VRs in a zone).
Why is all this necessary? Exactly then why VRF is usually done - isolating networks (clients) from each other and simplifying routing. For example, you can separate the routing of branches, IPSec tunnels to customers and the routing of service devices and the traffic of the router itself (default routing table). As a bonus (weighty!) We get convenience in compiling a routing table, security policies, and also get rid of the ospf database swelling.
- routing table;
- interfaces;
- routing protocol settings (for example, OSPF, ISIS, BGP);
- routing-options settings (e.g. static)
- Dynamic VPN or remote access VPN inside VR
- Public key infrastructure (PKI) inside VR
- Chassis cluster active / active with VPN inside VR
As you can see, the restrictions or concern very exotic configurations (for example, PKI), or things that in our case not supported by hardware (work in active / active is possible only in older versions of SRX designed for data centers). The restriction on Dynamic VPN is, of course, offensive (there is such a plan), but you can survive it.
Let's move on to the most interesting: to practice. Let's see how this is all set up and what happens in the end.
Two scenarios are possible here: when gre itself is located in VR:
Or when in VR there are only interfaces on top of which a GRE tunnel is built:
The setting is no different from the usual . The main thing is to correctly determine the external interface, which can also be in another VR. After that we add st0 to the necessary VR, we configure routing and policy. In our case, 10.6.6.0/24 is the network behind the IPsec gateway of our partner.
Here, additional configuration is also not required, the main thing, as in the case with IPSec, is to correctly configure routing and allowing policies.
With routing inside VR, everything is quite simple: protocol (routing-options in the case of static routing) are set directly in the VR settings. It is more interesting when we need to exchange routes between VR. Here come to our aid:
a. Static Routing
It works only in one direction (you cannot configure “oncoming” routes between VR).
Here we indicate to VR that the address abcd should be looked up in the default routing table (inet.0).
b. rib-groups
Allows you to import routing tables from one VR to another. And not completely, namely those parts that are needed. For example, static routes, interface routes (direct connected networks) or routes from a dynamic routing protocol.
In this case, you can configure “on-the-fly” routing between VR (different rib-groups), or, for example, make a static route in one direction and rib-group in the opposite. Routes imported in this way are perceived by VR “as native”, i.e. they can, for example, be exported to OSPF / BGP.
c. logical-tunnels
The option is transparent in implementation and convenient in some cases (for example, when you need to exchange BGP tables between different VRs). Virtual interfaces are created, seemingly just like real ones. They can be added to security zone, routing-instances, policies can be applied to them, hang addresses, etc. But the traffic does not exit the router.
The setup is pretty straightforward. Please note that when configuring lt, the neighbor id is specified. Those. tunnels can be more than two (which is logical).
Of the minuses - you need to create interfaces, add them to VR, security-zone, consider when configuring dynamic routing, etc.
That, in fact, is all. I will be glad to answer questions and comments in the comments.
Links (some of them may be available only with a service contract):
Junos OS Routing Protocols Configuration Guide PDF Document
Junos OS Security Configuration Guide PDF Document
Junos OS MPLS Configuration Guide for Security Devices PDF Document
Example: Configuring an st0 Interface in a Virtual Router
[SRX] Static NAT using Virtual-Routing Instance
[SRX] Configuration of the GRE tunnel in a routing-instance
[SRX] Configuration Example: Destination NAT two destinations to the same IP address and distinguish based on source address
[SRX, J Series] Example - Importing Routes to and from virtual routers on SRX and J Series
Understanding Logical Tunnel Interface (lt-0/0 / 0) on SRX branch series platforms
KDPV taken from here
continue to prepare tincture from juniper. How we started, you can read here and here . Today, we touch a little such a convenient thing as Virtual Routers, and think about how to use it with the greatest benefit.
Contents:
Part 1: Introducing
Part 2: IPSec
Part 3: Virtual Routers
Juniper has a Routing Instance entity type designed for traffic manipulation (routing and encapsulation). RIs allow you to "split" one router into several smaller ones, while each instance will process the traffic "in its own way", independently of the others and with different capabilities. This is useful for organizing all kinds of VPNs when you need to isolate several clients from each other and resolve them according to different rules. At the same time, information about the VPN can be exchanged with other routers (for example, when organizing MPLS VPN).
Types of Routing Instances
* Forwarding - Serves for building special filter-based forwarding applications (well, or policy-based routing in Cisco terminology). At the same time, the interfaces are not tied to the RI, but remain in the default RI.
* Layer 2 virtual private network (VPN) - Used to organize MPLS L2VPN.
* Nonforwarding - All routes and interfaces are placed in the main routing instance, but you can "divide" the main routing table into several smaller ones.
* VPN routing and forwarding (VRF)- Used to organize L3VPN. It contains not only a routing table, but also a switching table (forwarding table). At the same time, traffic from the interface is displayed in RI one-to-one, which allows you to send and receive routing labels, receiving a distributed VPN. Using dynamic routing protocols (BGP, OSPF or ISIS), you can organize the exchange of information between PE (provider edge) and CE (client edge) in such a way that each of them will receive (and give) routes only inside its “own” VPN.
* Virtual router- Similar to VRF, but does not have options such as VRF import, VRF export, VRF target, or route distinguisher. Accordingly, it is not suitable for creating L3VPN, because a separate routing table "lives" only within the same router. Due to its simplicity, it is used much more often than its "older brother".
* Virtual private LAN service (VPLS) - An entity for organizing multipoint distributed L2VPN on top of MPLS. For the client it will look like a virtual switch, to the ports of which its borderline (CE) devices are connected.
We will not look at all this magnificence right away, but we will only deal with VR. What is this all about? The description shows that this is a slightly simplified version of VRF, in fact - VRF-lite from the Cisco world. Logical tunnels and rib-groups are supported for exchanging routes and connecting VR to each other. Of course, routing protocols (ospf, bgp, isis) are configured separately for each VR. Each VR requires its own Security zone (you cannot place interfaces from different VRs in a zone).
Why is all this necessary? Exactly then why VRF is usually done - isolating networks (clients) from each other and simplifying routing. For example, you can separate the routing of branches, IPSec tunnels to customers and the routing of service devices and the traffic of the router itself (default routing table). As a bonus (weighty!) We get convenience in compiling a routing table, security policies, and also get rid of the ospf database swelling.
We will briefly describe the contents of VR
- routing table;
- interfaces;
- routing protocol settings (for example, OSPF, ISIS, BGP);
- routing-options settings (e.g. static)
VR limitations
- Dynamic VPN or remote access VPN inside VR
- Public key infrastructure (PKI) inside VR
- Chassis cluster active / active with VPN inside VR
As you can see, the restrictions or concern very exotic configurations (for example, PKI), or things that in our case not supported by hardware (work in active / active is possible only in older versions of SRX designed for data centers). The restriction on Dynamic VPN is, of course, offensive (there is such a plan), but you can survive it.
So what do we do with these VRs?
Let's move on to the most interesting: to practice. Let's see how this is all set up and what happens in the end.
GRE
Two scenarios are possible here: when gre itself is located in VR:
set interfaces gr-0/0/0 unit 1 description cs3925-1-smr--tun13
set interfaces gr-0/0/0 unit 1 point-to-point
set interfaces gr-0/0/0 unit 1 tunnel source 192.168.0.13
set interfaces gr-0/0/0 unit 1 tunnel destination 192.168.0.21
set interfaces gr-0/0/0 unit 1 tunnel routing-instance destination BRANCH_VR
set interfaces gr-0/0/0 unit 1 family inet mtu 1448
set interfaces gr-0/0/0 unit 1 family inet address 192.168.77.12/31
Or when in VR there are only interfaces on top of which a GRE tunnel is built:
set interfaces gr-0/0/0 unit 8 description cs3925-1-smr--tun15
set interfaces gr-0/0/0 unit 8 point-to-point
set interfaces gr-0/0/0 unit 8 tunnel source 1.2.3.4
set interfaces gr-0/0/0 unit 8 tunnel destination 2.3.4.2
set interfaces gr-0/0/0 unit 8 family inet mtu 1446
set interfaces gr-0/0/0 unit 8 family inet address 192.168.77.26/31
set routing-instances BRANCH_VR routing-options static route 2.3.4.2/32 next-table inet.0
set routing-instances BRANCH_VR routing-options static route 192.168.0.21/32 next-hop 192.168.0.14
IPsec
The setting is no different from the usual . The main thing is to correctly determine the external interface, which can also be in another VR. After that we add st0 to the necessary VR, we configure routing and policy. In our case, 10.6.6.0/24 is the network behind the IPsec gateway of our partner.
set routing-instances VR1 instance-type virtual-router
set routing-instances VR1 interface ge-0/0/1.0
set routing-instances VR1 interface st0.0
set routing-instances VR1 routing-options static route 10.6.6.0/24 next-hop st0.0
NAT
Here, additional configuration is also not required, the main thing, as in the case with IPSec, is to correctly configure routing and allowing policies.
Routing
With routing inside VR, everything is quite simple: protocol (routing-options in the case of static routing) are set directly in the VR settings. It is more interesting when we need to exchange routes between VR. Here come to our aid:
a. Static Routing
It works only in one direction (you cannot configure “oncoming” routes between VR).
admin@jpsrx550# show routing-instances SAMPLE_VR routing-options static
route a.b.c.d/32 next-table inet.0;
Here we indicate to VR that the address abcd should be looked up in the default routing table (inet.0).
b. rib-groups
Allows you to import routing tables from one VR to another. And not completely, namely those parts that are needed. For example, static routes, interface routes (direct connected networks) or routes from a dynamic routing protocol.
set routing-options rib-groups IPSEC_to_default_RIB import-rib IPSEC_VR.inet.0
set routing-options rib-groups IPSEC_to_default_RIB import-rib inet.0
set routing-instances IPSEC_VR routing-options static rib-group IPSEC_to_default_RIB
set routing-options rib-groups default_to_IPSEC_RIB import-rib inet.0
set routing-options rib-groups default_to_IPSEC_RIB import-rib IPSEC_VR.inet.0
set protocols ospf rib-group default_to_IPSEC_RIB
In this case, you can configure “on-the-fly” routing between VR (different rib-groups), or, for example, make a static route in one direction and rib-group in the opposite. Routes imported in this way are perceived by VR “as native”, i.e. they can, for example, be exported to OSPF / BGP.
c. logical-tunnels
The option is transparent in implementation and convenient in some cases (for example, when you need to exchange BGP tables between different VRs). Virtual interfaces are created, seemingly just like real ones. They can be added to security zone, routing-instances, policies can be applied to them, hang addresses, etc. But the traffic does not exit the router.
The setup is pretty straightforward. Please note that when configuring lt, the neighbor id is specified. Those. tunnels can be more than two (which is logical).
A long piece of config
interfaces {
lt-0/0/0 {
unit 1 {
encapsulation ethernet;
peer-unit 2;
family inet {
address 10.20.30.1/30;
}
}
unit 2 {
encapsulation ethernet;
peer-unit 1;
family inet {
address 10.20.30.2/30;
}
}
}
policy-options {
policy-statement p1 {
from {
instance R1;
protocol direct;
}
then accept;
}
policy-statement p2 {
from {
instance R2;
protocol direct;
}
then accept;
}
}
security {
zones {
security-zone Z1 {
host-inbound-traffic {
system-services {
all;
}
protocols {
all;
}
}
interfaces {
ge-0/0/1.0;
lt-0/0/0.1;
}
}
security-zone Z2 {
host-inbound-traffic {
system-services {
all;
}
protocols {
all;
}
}
interfaces {
ge-0/0/2.0;
lt-0/0/0.2;
}
}
}
policies {
from-zone Z1 to-zone Z1 {
policy Z1-Z1 {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
}
}
from-zone Z2 to-zone Z2 {
policy Z2-Z2 {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
}
}
}
flow {
traceoptions {
file lt-testing;
flag basic-datapath;
packet-filter 1 {
source-prefix 192.168.1.2/32;
destination-prefix 192.168.2.2/32;
}
}
}
}
routing-instances {
R1 {
instance-type virtual-router;
interface lt-0/0/0.1;
interface ge-0/0/1.0;
protocols {
ospf {
traceoptions {
file R1;
flag all;
}
export p1;
area 0.0.0.0 {
interface lt-0/0/0.1;
}
}
}
}
R2 {
instance-type virtual-router;
interface lt-0/0/0.2;
interface ge-0/0/2.0;
protocols {
ospf {
export p2;
area 0.0.0.0 {
interface lt-0/0/0.2;
}
}
}
}
}
Of the minuses - you need to create interfaces, add them to VR, security-zone, consider when configuring dynamic routing, etc.
That, in fact, is all. I will be glad to answer questions and comments in the comments.
Links (some of them may be available only with a service contract):
Junos OS Routing Protocols Configuration Guide PDF Document
Junos OS Security Configuration Guide PDF Document
Junos OS MPLS Configuration Guide for Security Devices PDF Document
Example: Configuring an st0 Interface in a Virtual Router
[SRX] Static NAT using Virtual-Routing Instance
[SRX] Configuration of the GRE tunnel in a routing-instance
[SRX] Configuration Example: Destination NAT two destinations to the same IP address and distinguish based on source address
[SRX, J Series] Example - Importing Routes to and from virtual routers on SRX and J Series
Understanding Logical Tunnel Interface (lt-0/0 / 0) on SRX branch series platforms
KDPV taken from here