Juniper tincture: Prepare Juniper SRX. Part 3: Virtual Routers
juniper - juniper (eng.)
We continue to prepare the tincture of juniper. About how we started, you can read here and here . Today, we’ll touch a handy thing like Virtual Routers and think about how to use it with the greatest benefit.
')
Content:
Part 1: Introduction
Part 2: IPSec
Part 3: Virtual Routers
Juniper has a type of entity, Routing Instance, designed to manipulate traffic (routing and encapsulation). RIs allow you to “split” one router into several smaller ones, with each instance processing traffic “in its own way,” independently of the others and with different capabilities. This is useful for organizing all sorts of VPNs when you need to isolate several clients from each other and resolve them according to different rules. At the same time, you can exchange VPN information with other routers (for example, when organizing an MPLS VPN).
* Forwarding - Used to build special filter-based forwarding applications (or policy-based routing in Cisco terminology). In this case, 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 it is possible to "divide" the main routing table into several smaller ones.
* VPN routing and forwarding (VRF) - Used to organize L3VPN. It contains not only the routing table (routing table), but also the switching table (forwarding table). At the same time, traffic from the interface is displayed in the RI one-to-one, which allows you to send routing labels and receive them, 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 send) routes only within 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, since A separate routing table "lives" only within one router. Due to simplicity, it is used much more often than its “big brother”.
* Virtual private LAN service (VPLS) - An entity for organizing multipoint distributed L2VPN over MPLS. To the client it will look like a virtual switch, to the ports of which its border (CE) devices are connected.
At once we will not look at all this magnificence, and we will be engaged only in VR. What is it all about? From the description it is clear that this is a slightly simplified version of VRF, in fact - VRF-lite from the world of Cisco. Supported logical tunnels and rib-groups for the exchange of routes and VR communication between them. Of course, the routing protocols (ospf, bgp, isis) are configured separately for each VR. Each VR requires its own Security zone (interfaces from different VR cannot be placed in the zone).
Why is all this necessary? Exactly then, why VRFs are usually done - isolating networks (clients) from each other and simplifying routing. For example, it is possible to divide the routing of branches, IPSec tunnels to customers and the routing of service devices and the traffic of the router itself (default routing table). With a bonus (weighty!), We get convenience in compiling routing table, security policies, and also get rid of the swelling of the ospf database.
- routing table;
- interfaces;
- routing protocol settings (for example, OSPF, ISIS, BGP);
- routing-options settings (for example 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 either relate to very exotic configurations (for example, PKI), or things that in our case are not supported by hardware (working in active / active is possible only in older versions of the SRX, intended for data centers). The restriction on Dynamic VPN is, of course, offensive (there is such a plan), but you can survive it.
We turn to the most interesting: to practice. Let's see how this is all configured and what happens in the end.
There are two possible scenarios: when gre himself 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 identify the external interface, which can also be in another VR. After that, add st0 to the desired VR, configure routing and policy. In our case, 10.6.6.0/24 is the network behind our partner's ipsec gateway.
There is also no additional configuration required, the main thing, as is the case with IPSec, is to correctly configure routing and permissive policies.
With routing inside VR, everything is quite simple: protocol (routing-options in the case of static routing) are specified directly in the VR settings. It's more interesting when we need to exchange routes between VRs. Here we come to the rescue:
a. Static routing
It works only in one direction (you cannot set up "counter" routes between VR).
Here we indicate to VR that the abcd address should be searched in the default routing table (inet.0).
b. rib-groups
Allows you to import routing tables from one VR to another. And not completely, but those parts that are needed. For example, static routes, interface routes (direct connected networks), or routes from a dynamic routing protocol.
At the same time, you can configure "counter" routing between VR (different rib-groups), or, for example, make a static route in one direction and a rib-group in the opposite direction. Routes imported in this way are perceived as “native” by VR, i.e. they can be, for example, exported to OSPF / BGP.
c. logical-tunnels
The option is transparent in implementation and convenient in some cases (for example, when it is necessary to exchange BGP tables between different VRs). Virtual interfaces are created, in appearance - just like the real ones. They can be added to the security zone, routing instances, policies can be applied to them, addresses can be hung, etc. But the traffic does not come out of the router.
The setup is pretty simple. Note that when configuring lt, the id of the neighbor is specified. Those. tunnels may be more than two (which is logical).
From the minuses - you need to create interfaces, add them to the VR, security-zone, take into account when setting up dynamic routing, etc.
That's all. I will be glad to answer questions and comments in the comments.
Links (some of them may be available only if there is 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
[SRX, J Series] Example - Importing Routes on the SRX and J Series
Understanding Logical Tunnel Interface (lt-0/0/0) on SRX branch series platforms
KDPV taken from here
We continue to prepare the tincture of juniper. About how we started, you can read here and here . Today, we’ll touch a handy thing like Virtual Routers and think about how to use it with the greatest benefit.
')
Content:
Part 1: Introduction
Part 2: IPSec
Part 3: Virtual Routers
Juniper has a type of entity, Routing Instance, designed to manipulate traffic (routing and encapsulation). RIs allow you to “split” one router into several smaller ones, with each instance processing traffic “in its own way,” independently of the others and with different capabilities. This is useful for organizing all sorts of VPNs when you need to isolate several clients from each other and resolve them according to different rules. At the same time, you can exchange VPN information with other routers (for example, when organizing an MPLS VPN).
Routing Instances Types
* Forwarding - Used to build special filter-based forwarding applications (or policy-based routing in Cisco terminology). In this case, 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 it is possible to "divide" the main routing table into several smaller ones.
* VPN routing and forwarding (VRF) - Used to organize L3VPN. It contains not only the routing table (routing table), but also the switching table (forwarding table). At the same time, traffic from the interface is displayed in the RI one-to-one, which allows you to send routing labels and receive them, 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 send) routes only within 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, since A separate routing table "lives" only within one router. Due to simplicity, it is used much more often than its “big brother”.
* Virtual private LAN service (VPLS) - An entity for organizing multipoint distributed L2VPN over MPLS. To the client it will look like a virtual switch, to the ports of which its border (CE) devices are connected.
At once we will not look at all this magnificence, and we will be engaged only in VR. What is it all about? From the description it is clear that this is a slightly simplified version of VRF, in fact - VRF-lite from the world of Cisco. Supported logical tunnels and rib-groups for the exchange of routes and VR communication between them. Of course, the routing protocols (ospf, bgp, isis) are configured separately for each VR. Each VR requires its own Security zone (interfaces from different VR cannot be placed in the zone).
Why is all this necessary? Exactly then, why VRFs are usually done - isolating networks (clients) from each other and simplifying routing. For example, it is possible to divide the routing of branches, IPSec tunnels to customers and the routing of service devices and the traffic of the router itself (default routing table). With a bonus (weighty!), We get convenience in compiling routing table, security policies, and also get rid of the swelling of the ospf database.
We briefly describe the contents of VR
- routing table;
- interfaces;
- routing protocol settings (for example, OSPF, ISIS, BGP);
- routing-options settings (for example static)
VR restrictions
- 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 either relate to very exotic configurations (for example, PKI), or things that in our case are not supported by hardware (working in active / active is possible only in older versions of the SRX, intended for data centers). The restriction on Dynamic VPN is, of course, offensive (there is such a plan), but you can survive it.
And what do we do with these VR?
We turn to the most interesting: to practice. Let's see how this is all configured and what happens in the end.
GRE
There are two possible scenarios: when gre himself 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 identify the external interface, which can also be in another VR. After that, add st0 to the desired VR, configure routing and policy. In our case, 10.6.6.0/24 is the network behind our partner's ipsec gateway.
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
There is also no additional configuration required, the main thing, as is the case with IPSec, is to correctly configure routing and permissive policies.
Routing
With routing inside VR, everything is quite simple: protocol (routing-options in the case of static routing) are specified directly in the VR settings. It's more interesting when we need to exchange routes between VRs. Here we come to the rescue:
a. Static routing
It works only in one direction (you cannot set up "counter" routes between VR).
admin@jpsrx550# show routing-instances SAMPLE_VR routing-options static route abcd/32 next-table inet.0; Here we indicate to VR that the abcd address should be searched in the default routing table (inet.0).
b. rib-groups
Allows you to import routing tables from one VR to another. And not completely, but 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 At the same time, you can configure "counter" routing between VR (different rib-groups), or, for example, make a static route in one direction and a rib-group in the opposite direction. Routes imported in this way are perceived as “native” by VR, i.e. they can be, for example, exported to OSPF / BGP.
c. logical-tunnels
The option is transparent in implementation and convenient in some cases (for example, when it is necessary to exchange BGP tables between different VRs). Virtual interfaces are created, in appearance - just like the real ones. They can be added to the security zone, routing instances, policies can be applied to them, addresses can be hung, etc. But the traffic does not come out of the router.
The setup is pretty simple. Note that when configuring lt, the id of the neighbor is specified. Those. tunnels may be more than two (which is logical).
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; } } } } } From the minuses - you need to create interfaces, add them to the VR, security-zone, take into account when setting up dynamic routing, etc.
That's all. I will be glad to answer questions and comments in the comments.
Links (some of them may be available only if there is 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
[SRX, J Series] Example - Importing Routes on the SRX and J Series
Understanding Logical Tunnel Interface (lt-0/0/0) on SRX branch series platforms
KDPV taken from here
Source: https://habr.com/ru/post/253315/
All Articles