[Contents] [Prev] [Next] [Index] [Report an Error]

Configuring Nonforwarding Instances

In nonforwarding instances implemented in JUNOS Release 5.3 and earlier, you could configure interinstance export through use of import routing table groups. A secondary routing instance would import routes from the primary routing instance. Then, IGPs would advertise the routes received from the second instance table as shown in the example in Figure 32.

Figure 32: Nonforwarding Instance Concept

Image h1754.gif

In JUNOS Release 5.4 and later, you can use the instance-import and instance-export policy keywords to perform nonforwarding, interinstance route sharing. The keywords are assigned at the [edit routing-instances instance-name routing-options] hierarchy level. These statements are similar to VRF import and VRF export policies used for VRF instances.

The “rt-export” module examines the from instance statements present in an instance import policy to construct the list of import tables for a particular exporting instance. The following example illustrates the configuration hierarchy for this feature:

[edit]
policy-options {
policy-statement {
red-import {
from instance blue;
then {
tag 1;
accept;
}
}
blue-import {
from instance red;
then {
tag 2;
accept;
}
}
}
}
routing-instances {
red {
routing-options {
instance-import red-import;
}
}
blue {
routing-options {
instance-import blue-import;
}
}
}

To advertise instance blue routes through an instance red IGP such as OSPF, you would add an export policy to OSPF to advertise routes from the local table.

[edit}
policy-options {
policy-statement ospf-export {
from /* some criteria */
then accept;
}
}
routing-instances {
red {
protocols ospf {
export ospf-export;
}
}
}

When an instance import policy is configured, the policy is allowed to modify route attributes other than next-hop.

Example: Nonforwarding Instances Configuration

Figure 33: Nonforwarding Instances Topology Diagram

Image g017146.gif

In Figure 33, routers CE1, CE2, CE3, and CE4 are CE routers, PE0 and PE2 are PE routers, and Router P is the provider core transit router. CE1 and CE3 are part of a “community of interest” group called data, whereas CE2 and CE4 belong to a group called voice. Your goal is to connect the members of each group to each other by using a nonforwarding instance at the PE routers.

Note that routers PE0, CE1, and CE2 mirror the configurations on PE2, CE3, and CE4, respectively. Therefore, the latter routers are not shown in this example. The loopback addressing scheme for this network is shown in Table 20.

Table 20: Nonforwarding Instances—Loopback Addresses

Router

Loopback Address

CE1

10.255.255.172

CE2

10.255.255.180

PE0

10.255.255.176

P

10.255.255.178

PE2

10.255.255.174

CE3

10.255.255.182

CE4

10.255.255.181

Routers CE1, CE2, CE3, and CE4 only need basic connectivity to their directly connected PE router. You enable OSPF on the interface that connects the CE routers to the PE routers. Since the configurations for all the CE routers are almost identical, only CE3 and CE4 are shown.

Router CE3

[edit]
protocols {
ospf {
area 0.0.0.0 {
interface t3-0/0/0.0;
}
}
}

Router CE4

[edit]
protocols {
ospf {
area 0.0.0.0 {
interface t3-0/0/2.0;
}
}
}

PE router configuration is next. Because the configurations for routers PE0 and PE2 mirror each other, only Router PE2 is displayed.

You must enable auto-export at the routing-options level for both the main configuration and the nonforwarding instances, establish policies that set tags on packets arriving from the CE routers, and accept packets into a specific instance that match the corresponding outbound tags. Specifically, you configure the router to attach a data tag to all packets coming from Router CE3 and a voice tag to all packets arriving from Router CE4. Also, forward any OSPF traffic coming from the core with a data tag to Router CE3, while OSPF core traffic with a voice tag is sent to Router CE4.

Router PE2

[edit]
routing-options {
auto-export;
}
protocols {
ospf {
export [tag-voice tag-data];
area 0.0.0.0 {
interface t3-0/1/1.0;
}
}
}
routing-instances {
data {
instance-type no-forwarding;
interface t3-0/1/3.0;
routing-options {
auto-export;
}
protocols {
ospf {
export import-data;
area 0.0.0.0 {
interface all;
}
}
}
}
voice {
instance-type no-forwarding;
interface t3-0/1/0.0;
routing-options {
auto-export
}
protocols {
ospf {
export import-voice;
area 0.0.0.0 {
interface all;
}
}
}
}
}
policy-options {
policy-statement tag-voice {
from instance voice;
then {
tag 11;
accept;
}
}
policy-statement tag-data {
from instance data;
then {
tag 12;
accept;
}
}
policy-statement import-voice {
from {
instance master;
protocol ospf;
tag 11;
}
then accept;
}
policy-statement import-data {
from {
instance master;
protocol ospf;
tag 12;
}
then accept;
}
}

On Router P, the provider core router configuration is simple. Include the interfaces that connect to the two PE routers (PE0 and PE2) in the OSPF process.

Router P

[edit]
protocols {
ospf {
area 0.0.0.0 {
interface t1-0/1/1.0;
interface t3-0/0/1.0;
}
}
}

If all the configurations are correct, routers CE1 and CE3 (the data tagged routers) can send traffic to one another and routers CE2 and CE4 (the voice tagged routers) can communicate bidirectionally, but routers with different tag types cannot reach each other.

Verifying Your Work

To verify that the nonforwarding instances configuration is functioning properly, you can use the following commands:

The following sections show the output of these commands used with the configuration example:

[Contents] [Prev] [Next] [Index] [Report an Error]

Copyright © 2008, Juniper Networks, Inc. All rights reserved. Trademark Notice.