Example: Non-Forwarding Instances Configuration
In Figure 25, 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, while 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 non-forwarding 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 15.
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.
CE3
[edit]
protocols {
ospf{
area 0.0.0.0 {
interface t3-0/0/0.0;
}
}
}
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 non-forwarding 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.
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.
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.