JNP: USO DE ROUTING INSTANCE – FORWARDING
Esta
opción sirve básicamente para enrutar tráfico dependiendo del origen del mismo.
El primer
paso es definir un filtro para elegir los orígenes que queremos enrutar.
Definimos
una instancia de enrutamiento utilizando la funcionabilidad de Forwarding* (instance-type)[1]
y configuramos la ip o red destino.
set
routing-instances RI-DSO-WEB instance-type forwarding
set
routing-instances RI-DSO-WEB routing-options static route X.X.X.X/32 next-hop Y.Y.Y.Y
[1] type—Can be one of the following:
·
evpn—(MX 3D Series routers only) Enable an Ethernet VPN
(EVPN) on the routing instance. You cannot configure the evpn option
under the [edit logical-systems logical-system-namerouting-instances routing-instance-name instance-type] hierarchy level.
·
forwarding—Provide support for filter-based forwarding, where
interfaces are not associated with instances. All interfaces belong to the
default instance. Other instances are used for populating RPD learned routes.
For this instance type, there is no one-to-one mapping between an interface and
a routing instance. All interfaces belong to the default instance inet.0.
·
l2backhaul-vpn—Provide support for Layer 2 wholesale VLAN packets
with no existing corresponding logical interface. When using this instance, the
router learns both the outer tag and inner tag of the incoming packets, when
the instance-role statement is defined as access, or the
outer VLAN tag only, when the instance-role statement is defined as nni.
·
l2vpn—Enable a Layer 2 VPN on the routing instance.
You must configure the interface, route-distinguisher, vrf-import, and vrf-export statements for this type of routing instance.
·
layer2-control—(MX Series routers only) Provide support for RSTP or
MSTP in customer edge interfaces of a VPLS routing instance. This instance type
cannot be used if the customer edge interface is multihomed to two provider
edge interfaces. If the customer edge interface is multihomed to two provider
edge interfaces, use the default BPDU tunneling.
·
no-forwarding—This is the default routing instance. Do not create a
corresponding forwarding instance. Use this routing instance type when a
separation of routing table information is required. There is no corresponding
forwarding table. All routes are installed into the default forwarding table. IS-IS
instances are strictly nonforwarding instance types.
·
virtual-router—Enable a virtual router routing instance. This
instance type is similar to a VPN routing and forwarding instance type, but
used for non-VPN-related applications. You must configure the interface statement
for this type of routing instance. You do not need to configure the route-distinguisher, vrf-import, and vrf-export statements.
·
virtual-switch—(MX Series routers only) Provide support for
Layer 2 bridging. Use this routing instance type to isolate a LAN segment
with its Spanning Tree Protocol (STP) instance and to separate its VLAN
identifier space.
·
vpls—Enable VPLS on the routing instance. Use this routing
instance type for point-to-multipoint LAN implementations between a set of
sites in a VPN. You must configure the interface, route-distinguisher, vrf-import, and vrf-export statements for this type of routing instance.
·
vrf—VPN routing and forwarding (VRF) instance. Provides
support for Layer 3 VPNs, where interface routes for each instance go into
the corresponding forwarding table only. Required to create a Layer 3 VPN.
Create a VRF table (instance-name.inet.0) that contains the routes originating from and
destined for a particular Layer 3 VPN. For this instance type, there is a
one-to-one mapping between an interface and a routing instance. Each VRF
instance corresponds with a forwarding table. Routes on an interface go into
the corresponding forwarding table. You must configure the interface, route-distinguisher, vrf-import, and vrf-export statements for this type of routing instance.
- http://www.juniper.net/documentation/en_US/junos13.2/topics/reference/configuration-statement/instance-type-edit-routing-instances-vp.html
Continuamos
definiendo un filtro[1]
para elegir los orígenes que queremos enrutar. Se asocia la red origen y la
instancia de enrutamiento, recordemos
que esta tiene rutas confguradas previamente.
set firewall
filter Filter-DSO term SRV_TEST from source-address Z.Z.Z.Z/32
set firewall
filter Filter-DSO term SRV_TEST then log
set firewall
filter Filter-DSO term SRV_TEST then routing-instance RI-DSO-WEB
set firewall
filter Filter-DSO term default then accept
Y
aplicamos el filtro sobre una de las
interfaces del firewall.
set interfaces
reth5 unit 20 family inet filter input Filter-DSO
[1] Understanding Filter-Based Forwarding to a Specific
Outgoing Interface or Destination IP Address
Policy-based routing (also known as
filter-based forwarding) refers to the use of firewall filters that are applied
to an interface to match certain IP header characteristics and to route only
those matching packets differently than the packets would normally be routed.
Starting in Junos OS Release 12.2, you can use then
next-interface, then
next-ip, or then
next-ip6 as an action in a firewall filter. From specific match conditions, IPv4
and IPv6 addresses or an interface name can be specified as the response action
to a match.
The set of match conditions can be as
follows:
·
Layer-3
properties (for example, the source or destination IP address or the TOS byte)
·
Layer-4
properties (for example, the source or destination port)
The route for the given IPv4 or IPv6 address has to be
present in the routing table for policy-based routing to take effect.
Similarly, the route through the given interface has to be present in the
forwarding table for next-interface action to take effect. This can be
achieved by configuring an interior gateway protocol (IGP), such as OSPF or
IS-IS, to advertise Layer 3 routes.
The firewall filter matches the
conditions and forwards the packet to one of the following:
·
An IPv4
address (using the next-ip firewall filter action)
·
An IPv6
address (using the next-ip6 firewall filter action)
·
An interface
(using the next-interface firewall filter action)
Suppose, for example, that you want to offer services
to your customers, and the services reside on different servers. An example of
a service might be hosted DNS or hosted FTP. As customer traffic arrives at the
Juniper Networks routing device, you can use filter-based forwarding to send
traffic to the servers by applying a match condition on a MAC address or an IP
address or simply an incoming interface and send the packets to a certain
outgoing interface that is associated with the appropriate server. Some of your
destinations might be IPv4 or IPv6 addresses, in which case the next-ip or next-ip6 action is useful.
·
http://www.juniper.net/techpubs/en_US/junos15.1/topics/topic-map/filter-based-forwarding-policy-based-routing.html
Por
ultimo redistribuimos (RIB)[1]
las rutas general sobre la instancia de enrutamiento que creamos inicialmente.
set
routing-options interface-routes rib-group inet DO-group
set
routing-options rib-groups DO-group import-rib inet.0
set
routing-options rib-groups DO-group import-rib RI-DSO-WEB.inet.0
Lo
que pasa aca es que de la table general inet.0 se importa a la table de nuestra
instancia de enrutamiento. La primera tabla se pasa a la segunda, y a la
tercera, y asi si ponemos mas.
