CCIE #21047

Juniper - Interinstance Route Sharing

Chris van den Brink, CCIE #21047 — Fri, 18 Mar 2011 21:46:26 +0000

This post is about how to configure interinstance route sharing on a Juniper PE router.

What we want to accomplish is that Router 7 and Router 9 are able to reach the lo0 interface on router 8 and vice versa. Router 7 and Router 9 should not be able to reach each others loopback interfaces.

The diagram is shown below :

Interinstance route sharing on Juniper routers can be configured in different ways. The easiest way to do this is in my opinion by using an auto-export policy which I will show how to configure in this post.

First we need to creat an auto-export policy which can be used to enable the auto-export function for all vrf’s. It is also possible to configure this policy per vrf.

Auto-export policy :


Router 4 :
set groups vrf-export-on routing-instances <*> routing-options auto-export

or 

chris@IPLOGIC-4# run show configuration groups
vrf-export-on {
    routing-instances {
        <*> {
            routing-options {
                auto-export;
            }
        }
    }
}

Next we need to apply this policy to all vrf’s so we can choose which routes from which vrf to import in which vrf :

Apply auto-export policy to vrf’s:


Router 4 :
set routing-instances apply-groups vrf-export-on

or

routing-instances {
    apply-groups vrf-export-on;
}

As shown in the diagram VPNB uses eBGP as PE-CE routing-protocol, VPNBC uses static and VPNC uses OSPF as PE-CE protocol.

Below are the VPN configurations on the PE-side (Router 4) :

Routing-instances configuration :


Router 4 :
set routing-instances VPNB instance-type vrf
set routing-instances VPNB interface fxp7.470
set routing-instances VPNB route-distinguisher 65000:9
set routing-instances VPNB vrf-import VPNB-in
set routing-instances VPNB vrf-export VPNB-out
set routing-instances VPNB vrf-table-label
set routing-instances VPNB routing-options autonomous-system 65001
set routing-instances VPNB routing-options autonomous-system independent-domain
set routing-instances VPNB routing-options auto-export
set routing-instances VPNB protocols bgp group VPNB_EBGP type external
set routing-instances VPNB protocols bgp group VPNB_EBGP local-address 10.0.47.1
set routing-instances VPNB protocols bgp group VPNB_EBGP peer-as 65005
set routing-instances VPNB protocols bgp group VPNB_EBGP neighbor 10.0.47.2
set routing-instances VPNBC instance-type vrf
set routing-instances VPNBC interface fxp5.480
set routing-instances VPNBC route-distinguisher 65000:10
set routing-instances VPNBC vrf-import VPNBC-in
set routing-instances VPNBC vrf-export VPNBC-out
set routing-instances VPNBC vrf-table-label
set routing-instances VPNBC routing-options static route 8.8.8.8/32 next-hop 10.0.48.2
set routing-instances VPNBC routing-options auto-export
set routing-instances VPNC instance-type vrf
set routing-instances VPNC interface fxp6.490
set routing-instances VPNC route-distinguisher 65000:3
set routing-instances VPNC vrf-import VPNC-in
set routing-instances VPNC vrf-export VPNC-out
set routing-instances VPNC vrf-table-label
set routing-instances VPNC routing-options auto-export
set routing-instances VPNC protocols ospf area 0.0.0.0 interface fxp6.490 interface-type p2p
set policy-options community VPNB members target:65000:222
set policy-options community VPNBC members target:65000:232
set policy-options community VPNC members target:65000:333

or

routing-instances {
    apply-groups vrf-export-on;
    VPNB {
        instance-type vrf;
        interface fxp7.470;
        route-distinguisher 65000:9;
        vrf-import VPNB-in;
        vrf-export VPNB-out;
        vrf-table-label;
        routing-options {
            autonomous-system 65001 independent-domain;
            auto-export;
        }
        protocols {
            bgp {
                group VPNB_EBGP {
                    type external;
                    local-address 10.0.47.1;
                    peer-as 65005;
                    neighbor 10.0.47.2;
                }
            }
        }
    }
    VPNBC {
        instance-type vrf;
        interface fxp5.480;
        route-distinguisher 65000:10;
        vrf-import VPNBC-in;
        vrf-export VPNBC-out;
        vrf-table-label;
        routing-options {
            static {
                route 8.8.8.8/32 next-hop 10.0.48.2;
            }
            auto-export;
        }
    }
    VPNC {
        instance-type vrf;
        interface fxp6.490;
        route-distinguisher 65000:3;
        vrf-import VPNC-in;
        vrf-export VPNC-out;
        vrf-table-label;
        routing-options {
            auto-export;
        }
        protocols {
            ospf {
                area 0.0.0.0 {
                    interface fxp6.490 {
                        interface-type p2p;
                    }
                }
            }
        }
    }
}
policy-options {
    community VPNB members target:65000:222;
    community VPNBC members target:65000:232;
    community VPNC members target:65000:333;
}

Next we need to configure the import and export policies for the vrf’s because these policies decide which routes will get imported into the routing-instances routing tables.

Export and Import policy configurations :


Router 4 :
set policy-options policy-statement VPNB-in from community VPNB
set policy-options policy-statement VPNB-in then accept
set policy-options policy-statement VPNB-out term 10 from protocol bgp
set policy-options policy-statement VPNB-out term 10 from route-filter 7.7.7.7/32 exact
set policy-options policy-statement VPNB-out term 10 then community add VPNB
set policy-options policy-statement VPNB-out term 10 then accept
set policy-options policy-statement VPNB-out term 30 from protocol direct
set policy-options policy-statement VPNB-out term 30 from route-filter 10.0.47.0/30 exact
set policy-options policy-statement VPNB-out term 30 then community add VPNB
set policy-options policy-statement VPNB-out term 30 then accept
set policy-options policy-statement VPNB-out term REJECT then reject
set policy-options policy-statement VPNBC-in from community VPNB
set policy-options policy-statement VPNBC-in from community VPNC
set policy-options policy-statement VPNBC-in then accept
set policy-options policy-statement VPNBC-out then community add VPNB
set policy-options policy-statement VPNBC-out then community add VPNC
set policy-options policy-statement VPNBC-out then accept
set policy-options policy-statement VPNC-in from community VPNC
set policy-options policy-statement VPNC-in then accept
set policy-options policy-statement VPNC-out then community add VPNC
set policy-options policy-statement VPNC-out then accept

or

policy-options {
    policy-statement VPNB-in {
        from community VPNB;
        then accept;
    }
    policy-statement VPNB-out {
        term 10 {
            from {
                protocol bgp;
                route-filter 7.7.7.7/32 exact;
            }
            then {
                community add VPNB;
                accept;
            }
        }
        term 30 {
            from {
                protocol direct;
                route-filter 10.0.47.0/30 exact;
            }
            then {
                community add VPNB;
                accept;
            }
        }
        term REJECT {
            then reject;
        }
    }
    policy-statement VPNBC-in {
        from community [ VPNB VPNC ];
        then accept;
    }
    policy-statement VPNBC-out {
        then {
            community add VPNB;
            community add VPNC;
            accept;
        }
    }
    policy-statement VPNC-in {
        from community VPNC;
        then accept;
    }
    policy-statement VPNC-out {
        then {
            community add VPNC;
            accept;
        }
    }
    community VPNB members target:65000:222;
    community VPNBC members target:65000:232;
    community VPNC members target:65000:333;
}

Let’s take a look at the routing-tables of the routing-instances :

Routing-tables :


Router 4 :
chris@IPLOGIC-4# run show route table VPNB

VPNB.inet.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

8.8.8.8/32         *[Static/5] 01:22:53
                    > to 10.0.48.2 via fxp5.480
10.0.47.0/30       *[Direct/0] 01:22:54
                    > via fxp7.470
10.0.47.1/32       *[Local/0] 01:22:54
                      Local via fxp7.470
10.0.48.0/30       *[Direct/0] 01:22:53
                    > via fxp5.480
10.0.48.1/32       *[Local/0] 01:22:53
                      Local via fxp5.480
7.7.7.7/32         *[BGP/170] 00:31:09, localpref 100
                      AS path: 65005 I
                    > to 10.0.47.2 via fxp7.470

Routing-table VPNBC :

chris@IPLOGIC-4# run show route table VPNBC

VPNBC.inet.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

8.8.8.8/32         *[Static/5] 01:24:42
                    > to 10.0.48.2 via fxp5.480
9.9.9.9/32         *[OSPF/10] 01:24:27, metric 10
                    > to 10.0.49.2 via fxp6.490
10.0.47.0/30       *[Direct/0] 01:24:41
                    > via fxp7.470
10.0.48.0/30       *[Direct/0] 01:24:42
                    > via fxp5.480
10.0.48.1/32       *[Local/0] 01:24:42
                      Local via fxp5.480
10.0.49.0/30       *[Direct/0] 01:24:41
                    > via fxp6.490
10.0.49.1/32       *[Local/0] 01:24:41
                      Local via fxp6.490
7.7.7.7/32         *[BGP/170] 00:30:36, localpref 100
                      AS path: 65005 I
                    > to 10.0.47.2 via fxp7.470

Routing-table VPNC :

chris@IPLOGIC-4# run show route table VPNC

VPNC.inet.0: 7 destinations, 8 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

8.8.8.8/32         *[Static/5] 01:25:53
                    > to 10.0.48.2 via fxp5.480
9.9.9.9/32         *[OSPF/10] 01:25:39, metric 10
                    > to 10.0.49.2 via fxp6.490
10.0.48.0/30       *[Direct/0] 01:25:53
                    > via fxp5.480
10.0.48.1/32       *[Local/0] 01:25:53
                      Local via fxp5.480
10.0.49.0/30       *[Direct/0] 01:25:54
                    > via fxp6.490
                    [OSPF/10] 01:25:49, metric 10
                    > via fxp6.490
10.0.49.1/32       *[Local/0] 01:25:54
                      Local via fxp6.490
224.0.0.5/32       *[OSPF/10] 01:25:55, metric 1
                      MultiRecv

Juniper Lab aggregate route

Chris van den Brink, CCIE #21047 — Wed, 02 Mar 2011 20:53:18 +0000

This post is about how to configure aggregation and redistribute it into bgp.

Starting point for this post will be the same mpls network as seen in the previous posts. See below the diagram of the network topology :

For the purpose of this post I configured the following ip address on router 6

Interface configuration :


Router 6 :

set interfaces fxp2 vlan-tagging
set interfaces fxp2 unit 10 vlan-id 10
set interfaces fxp2 unit 10 family inet address 10.10.1.1/24
set interfaces fxp2 unit 10 family inet address 10.10.2.1/24
set interfaces fxp2 unit 10 family inet address 10.10.3.1/24
set interfaces fxp2 unit 10 family inet address 10.10.4.1/24

On router 1 I configured statics which point router 6, this is needed so that there are contributing routes for the aggregate route.

Static routes :


Router 1 :

set routing-instances VPNA routing-options static route 10.10.1.0/24 next-hop 10.0.16.2
set routing-instances VPNA routing-options static route 10.10.2.0/24 next-hop 10.0.16.2
set routing-instances VPNA routing-options static route 10.10.3.0/24 next-hop 10.0.16.2

Now that the statics are defined we can define the aggregate route in VPNA on router 1 :

set routing-instances VPNA routing-options aggregate route 10.10.0.0/22

And redistribute it in BGP :

set policy-options policy-statement export-VPNA term 20 from protocol aggregate
set policy-options policy-statement export-VPNA term 20 from route-filter 10.10.0.0/22 exact
set policy-options policy-statement export-VPNA term 20 then community add VPNA
set policy-options policy-statement export-VPNA term 20 then accept

Be sure to insert it before the REJECT term :

insert policy-options policy-statement export-VPNA term 20 before term REJECT

See details about the aggregated route in VPNA :

Show aggregate route detail :


Router 1 :

chris@IPLOGIC-1# run show route protocol aggregate table VPNA detail

VPNA.inet.0: 11 destinations, 11 routes (10 active, 0 holddown, 1 hidden)
10.10.0.0/22 (1 entry, 1 announced)
        *Aggregate Preference: 130
                Next hop type: Reject
                Next-hop reference count: 3
                State: 
                Local AS: 65001
                Age: 52:12
                Task: Aggregate
                Announcement bits (2): 1-KRT 3-BGP RT Background
                AS path: I (LocalAgg)
                Flags:                  Depth: 0        Active
                AS path list:
                AS path: I Refcount: 3
               Contributing Routes (3):
                        10.10.1.0/24 proto Static
                        10.10.2.0/24 proto Static
                        10.10.3.0/24 proto Static

Now let’s take a look in the routing table of router 5 and see if the aggregated route is there :

Show route table on router 5 :


Router 5 :

chris@IPLOGIC-5# run show route

inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

5.5.5.5/32         *[Direct/0] 02:52:18
                    > via lo0.0
6.6.6.6/32         *[BGP/170] 02:51:30, localpref 100
                      AS path: 65001 65006 I
                    > to 10.0.45.1 via fxp3.450
10.0.45.0/30       *[Direct/0] 02:52:18
                    > via fxp3.450
10.0.45.2/32       *[Local/0] 02:52:18
                      Local via fxp3.450
10.10.0.0/22       *[BGP/170] 02:51:30, localpref 100
                      AS path: 65001 I
                    > to 10.0.45.1 via fxp3.450

__juniper_private2__.inet.0: 1 destinations, 1 routes (0 active, 0 holddown, 1 hidden)

As you can see the aggregate is in there, let’s see if we can ping one of the ip-addresses configured on router 6 :

Ping from router 5 :


Router 5 :

chris@IPLOGIC-5# run ping 10.10.3.1 source 5.5.5.5
PING 10.10.3.1 (10.10.3.1): 56 data bytes
64 bytes from 10.10.3.1: icmp_seq=0 ttl=63 time=70.974 ms
64 bytes from 10.10.3.1: icmp_seq=1 ttl=63 time=2.368 ms
64 bytes from 10.10.3.1: icmp_seq=2 ttl=63 time=1.525 ms
^C
--- 10.10.3.1 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.525/24.956/70.974/32.542 ms

Juniper Lab MPLS PE-CE eBGP

Chris van den Brink, CCIE #21047 — Sun, 27 Feb 2011 21:49:25 +0000

This post is about how to configure eBGP as PE to CE protocol on Juniper routers. This post uses and builds on the same MPLS core network which we configured in the previous 3 posts.

Below the diagram with the topology used for this post :

The thing we want to accomplish is to create connectivity over the MPLS network between the two loopback addresses of Router 5 and Router 6. The chosen PE-CE protocol in this post is eBGP.

First thing to do is to configure the CE routers Router 6 and Router 5 with a base configuration :

Base configurations CE Routers:


Router 5 :

set system host-name IPLOGIC-5
set interfaces fxp3 unit 450 vlan-id 450
set interfaces fxp3 unit 450 family inet address 10.0.45.2/30
set interfaces lo0 unit 0 family inet address 5.5.5.5/32

Router 6 :

set system host-name IPLOGIC-6
set interfaces fxp4 unit 160 vlan-id 160
set interfaces fxp4 unit 160 family inet address 10.0.16.2/30
set interfaces lo0 unit 0 family inet address 6.6.6.6/32

The configuration on the PE side :

Base configurations PE Routers:


Router 1 :

set interfaces fxp5 unit 160 vlan-id 160
set interfaces fxp5 unit 160 family inet address 10.0.16.1/30

set routing-instances VPNA interface fxp5.160

Router 4 :

set interfaces fxp3 unit 450 vlan-id 450
set interfaces fxp3 unit 450 family inet address 10.0.45.1/30

set routing-instances VPNA interface fxp3.450

Next we configure eBGP on the CE-routers :

eBGP configurations CE Routers:


Router 5 :

set routing-options autonomous-system 65005

set protocols bgp group VPNA-EBGP type external
set protocols bgp group VPNA-EBGP local-address 10.0.45.2
set protocols bgp group VPNA-EBGP export EXPORTBGP1
set protocols bgp group VPNA-EBGP neighbor 10.0.45.1 peer-as 65001

set policy-options policy-statement EXPORTBGP1 term 10 from route-filter 5.5.5.5/32 exact
set policy-options policy-statement EXPORTBGP1 term 10 then accept
set policy-options policy-statement EXPORTBGP1 term REJECT then reject

Router 6 :

set routing-options autonomous-system 65006

set protocols bgp group EBGP-VPNA type external
set protocols bgp group EBGP-VPNA local-address 10.0.16.2
set protocols bgp group EBGP-VPNA export EXPORTBGP1
set protocols bgp group EBGP-VPNA neighbor 10.0.16.1 peer-as 65001

set policy-options policy-statement EXPORTBGP1 term 10 from route-filter 6.6.6.6/32 exact
set policy-options policy-statement EXPORTBGP1 term 10 then accept
set policy-options policy-statement EXPORTBGP1 term REJECT then reject

And last but not least the eBGP configuration on the PE-routers in the VPNA routing-instance.

eBGP configurations PE Routers:


Router 1 :

set routing-instances VPNA routing-options autonomous-system 65001
set routing-instances VPNA routing-options autonomous-system independent-domain

set routing-instances VPNA protocols bgp family inet unicast
set routing-instances VPNA protocols bgp group VPNA-EBGP type external
set routing-instances VPNA protocols bgp group VPNA-EBGP local-address 10.0.16.1
set routing-instances VPNA protocols bgp group VPNA-EBGP neighbor 10.0.16.2 peer-as 65006

set policy-options policy-statement export-VPNA term 10 from protocol bgp
set policy-options policy-statement export-VPNA term 10 from route-filter 6.6.6.6/32 exact
set policy-options policy-statement export-VPNA term 10 then community add VPNA
set policy-options policy-statement export-VPNA term 10 then accept
set policy-options policy-statement export-VPNA term REJECT then reject

set policy-options policy-statement import-VPNA term 10 from protocol bgp
set policy-options policy-statement import-VPNA term 10 from community VPNA
set policy-options policy-statement import-VPNA term 10 then accept
set policy-options policy-statement import-VPNA term REJECT then reject

Router 4  :

set routing-instances VPNA routing-options autonomous-system 65001
set routing-instances VPNA routing-options autonomous-system independent-domain

set routing-instances VPNA protocols bgp group VPNA-EBGP type external
set routing-instances VPNA protocols bgp group VPNA-EBGP local-address 10.0.45.1
set routing-instances VPNA protocols bgp group VPNA-EBGP family inet unicast
set routing-instances VPNA protocols bgp group VPNA-EBGP neighbor 10.0.45.2 peer-as 65005

set policy-options policy-statement export-VPNA term 10 from protocol bgp
set policy-options policy-statement export-VPNA term 10 from route-filter 5.5.5.5/32 exact
set policy-options policy-statement export-VPNA term 10 then community add VPNA
set policy-options policy-statement export-VPNA term 10 then accept
set policy-options policy-statement export-VPNA term REJECT then reject

set policy-options policy-statement import-VPNA term 10 from protocol bgp
set policy-options policy-statement import-VPNA term 10 from community VPNA
set policy-options policy-statement import-VPNA term 10 then accept
set policy-options policy-statement import-VPNA term REJECT then reject

Below the route table and ping results between the two loopback addresses :

Route table and ping :


Router 5 :

chris@IPLOGIC-5# run show route

inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

5.5.5.5/32         *[Direct/0] 01:39:53
                    > via lo0.0
6.6.6.6/32         *[BGP/170] 01:38:42, localpref 100
                      AS path: 65001 65006 I
                    > to 10.0.45.1 via fxp3.450
10.0.45.0/30       *[Direct/0] 01:39:53
                    > via fxp3.450
10.0.45.2/32       *[Local/0] 01:39:53
                      Local via fxp3.450

__juniper_private2__.inet.0: 1 destinations, 1 routes (0 active, 0 holddown, 1 hidden)

[edit]
chris@IPLOGIC-5# run ping 6.6.6.6
PING 6.6.6.6 (6.6.6.6): 56 data bytes
^C
--- 6.6.6.6 ping statistics ---
2 packets transmitted, 0 packets received, 100% packet loss

[edit]
chris@IPLOGIC-5# run ping 6.6.6.6 source 5.5.5.5
PING 6.6.6.6 (6.6.6.6): 56 data bytes
64 bytes from 6.6.6.6: icmp_seq=0 ttl=63 time=5.171 ms
64 bytes from 6.6.6.6: icmp_seq=1 ttl=63 time=1.615 ms
64 bytes from 6.6.6.6: icmp_seq=2 ttl=63 time=1.658 ms
64 bytes from 6.6.6.6: icmp_seq=3 ttl=63 time=2.445 ms
^C
--- 6.6.6.6 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.615/2.722/5.171/1.452 ms

Router 6 :

chris@IPLOGIC-6# run show route

inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

5.5.5.5/32         *[BGP/170] 01:39:12, localpref 100
                      AS path: 65001 65005 I
                    > to 10.0.16.1 via fxp4.160
6.6.6.6/32         *[Direct/0] 01:40:23
                    > via lo0.0
10.0.16.0/30       *[Direct/0] 01:40:23
                    > via fxp4.160
10.0.16.2/32       *[Local/0] 01:40:23
                      Local via fxp4.160

__juniper_private2__.inet.0: 1 destinations, 1 routes (0 active, 0 holddown, 1 hidden)

[edit]
chris@IPLOGIC-6# run ping 5.5.5.5
PING 5.5.5.5 (5.5.5.5): 56 data bytes
^C
--- 5.5.5.5 ping statistics ---
2 packets transmitted, 0 packets received, 100% packet loss

[edit]
chris@IPLOGIC-6# run ping 5.5.5.5 source 6.6.6.6
PING 5.5.5.5 (5.5.5.5): 56 data bytes
64 bytes from 5.5.5.5: icmp_seq=0 ttl=63 time=4.962 ms
64 bytes from 5.5.5.5: icmp_seq=1 ttl=63 time=1.688 ms
64 bytes from 5.5.5.5: icmp_seq=2 ttl=63 time=1.627 ms
64 bytes from 5.5.5.5: icmp_seq=3 ttl=63 time=1.701 ms
^C
--- 5.5.5.5 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.627/2.494/4.962/1.425 ms

Juniper Lab I part 3

Chris van den Brink, CCIE #21047 — Fri, 18 Feb 2011 22:17:58 +0000

In the previous posts we configured the interfaces, ospf, bgp, rsvp, mpls and mbgp. In this post we will configure a vrf (routing-instance) named VPNA.

Below is the lab topology again which we use for this lab :

As you can see the vrf VPNA resides on Router 1 and Router 4. For testing purposes I configured two interfaces in it which should be able to ping each other from within the routing-instance after we are finished.

Below is the configuration of VPNA on Router 1 :
Router 1 :


set policy-options community VPNA members target:65000:104
set routing-instances VPNA instance-type vrf
set routing-instances VPNA interface fxp1.10
set routing-instances VPNA route-distinguisher 65000:1
set routing-instances VPNA vrf-import import-VPNA
set routing-instances VPNA vrf-export export-VPNA
set routing-instances VPNA vrf-table-label

Although it would also be possible to control the import and export of routes by issuing the “set routing-instances VPNA vrf-target target:65000:104″ command we are not going to configure it like that because we want to exactly be in control what routes come in and go out of the routing-instance.

The import and export policies define what routes are getting imported and exported, below the policies specified :

Policies:


set policy-options policy-statement export-VPNA term 10 from protocol direct
set policy-options policy-statement export-VPNA term 10 from route-filter 11.11.11.0/24 exact
set policy-options policy-statement export-VPNA term 10 then community add VPNA
set policy-options policy-statement export-VPNA then accept
set policy-options policy-statement export-VPNA term REJECT then reject

set policy-options policy-statement import-VPNA term 10 from protocol bgp
set policy-options policy-statement import-VPNA term 10 from community VPNA
set policy-options policy-statement import-VPNA term 10 then accept
set policy-options policy-statement import-VPNA term REJECT then reject

Below is the configuration of VPNA on Router 4 :
Router 4 :


set policy-options community VPNA members target:65000:104
set routing-instances VPNA instance-type vrf
set routing-instances VPNA interface fxp3.30
set routing-instances VPNA route-distinguisher 65000:4
set routing-instances VPNA vrf-import import-VPNA
set routing-instances VPNA vrf-export export-VPNA
set routing-instances VPNA vrf-table-label

Policies:


set policy-options policy-statement export-VPNA term 10 from protocol direct
set policy-options policy-statement export-VPNA term 10 from route-filter 44.44.44.0/24 exact
set policy-options policy-statement export-VPNA term 10 then community add VPNA
set policy-options policy-statement export-VPNA term 10 then accept
set policy-options policy-statement export-VPNA term REJECT then reject

set policy-options policy-statement import-VPNA term 10 from protocol bgp
set policy-options policy-statement import-VPNA term 10 from community VPNA
set policy-options policy-statement import-VPNA term 10 then accept
set policy-options policy-statement import-VPNA term REJECT then reject

Below the route table of routing-instance VPNA on Router 1 :

Router 1 :


chris@IPLOGIC-1# run show route table VPNA

VPNA.inet.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

11.11.11.0/24      *[Direct/0] 01:55:27
                    > via fxp1.10
11.11.11.1/32      *[Local/0] 01:55:27
                      Local via fxp1.10
44.44.44.0/24      *[BGP/170] 00:03:38, localpref 100, from 4.4.4.4
                      AS path: I
                    > to 10.0.12.2 via fxp3.120, label-switched-path R1-to-R4
                      to 10.0.13.3 via fxp2.130, label-switched-path R1-to-R4

Below the route table of routing-instance VPNA on Router 1 :

Router 4 :


chris@IPLOGIC-4# run show route table VPNA

VPNA.inet.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

11.11.11.0/24      *[BGP/170] 00:04:31, localpref 100, from 1.1.1.1
                      AS path: I
                    > to 10.0.24.2 via fxp1.240, label-switched-path R4-to-R1
                      to 10.0.34.3 via fxp2.340, label-switched-path R4-to-R1
44.44.44.0/24      *[Direct/0] 01:51:24
                    > via fxp3.30
44.44.44.4/32      *[Local/0] 01:51:24
                      Local via fxp3.30

Now let’s ping ip address 44.44.44.4 from source-address 11.11.11.1 from within routing-instance VPNA :

Router 1 :


chris@IPLOGIC-1# run ping routing-instance VPNA 44.44.44.4 source 11.11.11.1
PING 44.44.44.4 (44.44.44.4): 56 data bytes
64 bytes from 44.44.44.4: icmp_seq=0 ttl=64 time=4.680 ms
64 bytes from 44.44.44.4: icmp_seq=1 ttl=64 time=1.064 ms
64 bytes from 44.44.44.4: icmp_seq=2 ttl=64 time=1.122 ms
^C
--- 44.44.44.4 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.064/2.289/4.680/1.691 ms

Juniper Lab I part 2

Chris van den Brink, CCIE #21047 — Fri, 18 Feb 2011 15:27:41 +0000

In the previous post we configured the interfaces, ospf and bgp. In this post we will configure rsvp, mpls, mbgp. In the next post we will configure routing-instances.

Below is the lab topology used for this lab :

Since I prefer rsvp-signaled lsp’s over ldp based mpls we will set it up like this. First thing to do is to activate the signalling protocol, rsvp in this case, on all relevant interfaces. See below :

RSVP:


Router 1 :
set protocols rsvp interface fxp3.120
set protocols rsvp interface fxp2.130

Router 2 :
set protocols rsvp interface fxp4.120
set protocols rsvp interface fxp2.240

Router 3 :
set protocols rsvp interface fxp1.130
set protocols rsvp interface fxp4.340

Router 4 :
set protocols rsvp interface fxp2.340
set protocols rsvp interface fxp1.240

Also we should enable MPLS on the relevant interfaces, see below :

MPLS:


Router 1 :
set interfaces fxp2 unit 130 family mpls <-- this is to support the mpls address family
set interfaces fxp3 unit 120 family mpls
set protocols mpls interface all  <-- this is to enable the mpls protocol on all the interfaces

Router 2 :
set interfaces fxp2 unit 240 family mpls
set interfaces fxp4 unit 120 family mpls
set protocols mpls interface all

Router 3 :
set interfaces fxp1 unit 130 family mpls
set interfaces fxp4 unit 340 family mpls
set protocols mpls interface all

Router 4 :
set interfaces fxp1 unit 240 family mpls
set interfaces fxp2 unit 340 family mpls
set protocols mpls interface all

OSPF traffic engineering support

When traffic engineering is enabled on the routing device, you can enable OSPF traffic engineering support, which allows OSPF to generate LSAs that carry traffic engineering parameters. These parameters are used to create the traffic engineering database, which is used by Constrained Shortest Path First (CSPF) to compute MPLS LSPs. WIth ISIS it is turned on by default, with OSPF it is not.
But since we are going to explicitly tell MPLS what path to take there is no need to turn it on.

To make sure BGP can carry Multiprotocol BGP information the following commend is issued on Router 1 and Router 4 :
MpBGP:


set protocols bgp group internal family inet-vpn unicast

Router 2 and 3 are just stupid transit routers so they don’t need to take part in BGP.

The next thing to do is to define the MPLS LSP’s.

Path’s:


On Router 1 :
set protocols mpls label-switched-path R1-to-R4 to 4.4.4.4
set protocols mpls label-switched-path R1-to-R4 no-cspf
set protocols mpls label-switched-path R1-to-R4 primary PRIMARY-TO-R4
set protocols mpls label-switched-path R1-to-R4 secondary SECONDARY-TO-R4 standby
set protocols mpls path PRIMARY-TO-R4 10.0.12.2 strict
set protocols mpls path SECONDARY-TO-R4 10.0.13.3 strict
set protocols mpls path SECONDARY-TO-R4 10.0.34.4 strict

On Router 4 :
set protocols mpls label-switched-path R4-to-R1 to 1.1.1.1
set protocols mpls label-switched-path R4-to-R1 no-cspf
set protocols mpls label-switched-path R4-to-R1 primary PRIMARY-TO-R1
set protocols mpls label-switched-path R4-to-R1 secondary SECONDARY-TO-R1 standby
set protocols mpls path PRIMARY-TO-R1 10.0.24.2 strict
set protocols mpls path SECONDARY-TO-R1 10.0.34.3 strict
set protocols mpls path SECONDARY-TO-R1 10.0.13.1 strict

Now we can check on the routers if the MPLS LSPs are visible :

Show mpls path’s:


Router 1 :
chris@IPLOGIC-1# run show mpls lsp brief
Ingress LSP: 1 sessions
To              From            State Rt ActivePath       P     LSPname
4.4.4.4         1.1.1.1         Up     0 PRIMARY-TO-R4    *     R1-to-R4
Total 1 displayed, Up 1, Down 0

Egress LSP: 2 sessions
To              From            State   Rt Style Labelin Labelout LSPname
1.1.1.1         4.4.4.4         Up       0  1 FF       3        - R4-to-R1
1.1.1.1         4.4.4.4         Up       0  1 FF       3        - R4-to-R1
Total 2 displayed, Up 2, Down 0

Transit LSP: 0 sessions
Total 0 displayed, Up 0, Down 0


Router 2 :
chris@IPLOGIC-2# run show mpls lsp transit
Transit LSP: 2 sessions
To              From            State   Rt Style Labelin Labelout LSPname
1.1.1.1         4.4.4.4         Up       1  1 FF  100192        3 R4-to-R1
4.4.4.4         1.1.1.1         Up       1  1 FF  100176        3 R1-to-R4
Total 2 displayed, Up 2, Down 0


Router 3 :
chris@IPLOGIC-3# run show mpls lsp transit
Transit LSP: 2 sessions
To              From            State   Rt Style Labelin Labelout LSPname
1.1.1.1         4.4.4.4         Up       1  1 FF  100160        3 R4-to-R1
4.4.4.4         1.1.1.1         Up       1  1 FF  100144        3 R1-to-R4
Total 2 displayed, Up 2, Down 0


Router 4 :
chris@IPLOGIC-4# run show mpls lsp brief
Ingress LSP: 1 sessions
To              From            State Rt ActivePath       P     LSPname
1.1.1.1         4.4.4.4         Up     0 PRIMARY-TO-R1    *     R4-to-R1
Total 1 displayed, Up 1, Down 0

Egress LSP: 2 sessions
To              From            State   Rt Style Labelin Labelout LSPname
4.4.4.4         1.1.1.1         Up       0  1 FF       3        - R1-to-R4
4.4.4.4         1.1.1.1         Up       0  1 FF       3        - R1-to-R4
Total 2 displayed, Up 2, Down 0

Transit LSP: 0 sessions
Total 0 displayed, Up 0, Down 0

If we take a closer look at the LSP like below we can see the two specified path’s :


Router 1 :
chris@IPLOGIC-1# run show mpls lsp name R1-to-R4 detail
Ingress LSP: 1 sessions

4.4.4.4
  From: 1.1.1.1, State: Up, ActiveRoute: 0, LSPname: R1-to-R4
  ActivePath: PRIMARY-TO-R4 (primary)
  LoadBalance: Random
  Encoding type: Packet, Switching type: Packet, GPID: IPv4
 *Primary   PRIMARY-TO-R4    State: Up
    SmartOptimizeTimer: 180
    Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt):
          10.0.12.2 10.0.24.4
  Standby   SECONDARY-TO-R4  State: Up
    SmartOptimizeTimer: 180
    Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt):
          10.0.13.3 10.0.34.4
Total 1 displayed, Up 1, Down 0

Egress LSP: 2 sessions
Total 0 displayed, Up 0, Down 0

Transit LSP: 0 sessions
Total 0 displayed, Up 0, Down 0

In the next post I will show how to configure vrf’s (routing-instances).

Juniper Lab I part 1

Chris van den Brink, CCIE #21047 — Sat, 03 Apr 2010 21:43:04 +0000

In this series I will show how to set up MPLS LSP paths on Juniper routers and run layer 3 vpn’s over it. I will also show how to configure primary and secondary LSP paths.

Below is the lab topology I will use for this lab :

But first things first, in this post I will show how to configure the interfaces for this lab. Let’s start configuring the interfaces on the routers.

Interfaces:


R1 :

set interfaces fxp1 vlan-tagging
set interfaces fxp1 unit 10 vlan-id 10
set interfaces fxp1 unit 10 family inet address 11.11.11.1/24
set interfaces fxp2 vlan-tagging
set interfaces fxp2 unit 130 vlan-id 130
set interfaces fxp2 unit 130 family inet address 10.0.13.1/24
set interfaces fxp3 vlan-tagging
set interfaces fxp3 unit 120 vlan-id 120
set interfaces fxp3 unit 120 family inet address 10.0.12.1/24
set interfaces lo0 unit 0 family inet address 1.1.1.1/32

R2 :

set interfaces fxp2 vlan-tagging
set interfaces fxp2 unit 240 vlan-id 240
set interfaces fxp2 unit 240 family inet address 10.0.24.2/24
set interfaces fxp4 vlan-tagging
set interfaces fxp4 unit 120 vlan-id 120
set interfaces fxp4 unit 120 family inet address 10.0.12.2/24
set interfaces lo0 unit 0 family inet address 2.2.2.2/32

R3 :

set interfaces fxp1 vlan-tagging
set interfaces fxp1 unit 130 vlan-id 130
set interfaces fxp1 unit 130 family inet address 10.0.13.3/24
set interfaces fxp4 vlan-tagging
set interfaces fxp4 unit 340 vlan-id 340
set interfaces fxp4 unit 340 family inet address 10.0.34.3/24
set interfaces lo0 unit 0 family inet address 3.3.3.3/32

R4 :

set interfaces fxp1 vlan-tagging
set interfaces fxp1 unit 240 vlan-id 240
set interfaces fxp1 unit 240 family inet address 10.0.24.4/24
set interfaces fxp2 vlan-tagging
set interfaces fxp2 unit 340 vlan-id 340
set interfaces fxp2 unit 340 family inet address 10.0.34.4/24
set interfaces fxp3 vlan-tagging
set interfaces fxp3 unit 30 vlan-id 30
set interfaces fxp3 unit 30 family inet address 44.44.44.4/24
set interfaces lo0 unit 0 family inet address 4.4.4.4/32

Next let set up OSPF for this lab :

OSPF :


R1 :

set protocols ospf area 0.0.0.0 interface fxp3.120
set protocols ospf area 0.0.0.0 interface fxp2.130 metric 11
set protocols ospf area 0.0.0.0 interface lo0.0 passive

R2 :

set protocols ospf area 0.0.0.0 interface fxp4.120
set protocols ospf area 0.0.0.0 interface fxp2.240
set protocols ospf area 0.0.0.0 interface lo0.0 passive

R3 :

set protocols ospf area 0.0.0.0 interface fxp1.130
set protocols ospf area 0.0.0.0 interface fxp4.340
set protocols ospf area 0.0.0.0 interface lo0.0 passive

R4 :

set protocols ospf area 0.0.0.0 interface fxp1.240
set protocols ospf area 0.0.0.0 interface fxp2.340 metric 11
set protocols ospf area 0.0.0.0 interface lo0.0 passive

Next let set up iBGP :

iBGP :


R1 :

set protocols bgp group internal type internal
set protocols bgp group internal local-address 1.1.1.1
set protocols bgp group internal neighbor 4.4.4.4
set protocols bgp group internal family inet unicast

R4 :

set protocols bgp group internal type internal
set protocols bgp group internal local-address 4.4.4.4
set protocols bgp group internal neighbor 1.1.1.1
set protocols bgp group internal family inet unicast

In the next post I will show how to configure MPLS and LSP for this test lab.

Juniper Olive

Chris van den Brink, CCIE #21047 — Sat, 03 Apr 2010 21:05:13 +0000

This post will be about my Juniper test lab. To set up this lab I used the tutorial on this site. I am using a Ubuntu system for this with a i7 processor in it, the processor load is always below 30% when firing up 7 virtual Juniper devices. It took me a while to set it up with the right JunOS, some JunOS releases didn’t work properly. The JunOS version I am using in my virtual-lab environment is :

Juniper1:


juniper@Juniper1> show version
Hostname: Juniper1
Model: olive
JUNOS Base OS boot [8.4R4.2]
JUNOS Base OS Software Suite [8.4R4.2]
JUNOS Kernel Software Suite [8.4R4.2]
JUNOS Crypto Software Suite [8.4R4.2]
JUNOS Packet Forwarding Engine Support (M/T Common) [8.4R4.2]
JUNOS Packet Forwarding Engine Support (M20/M40) [8.4R4.2]
JUNOS Online Documentation [8.4R4.2]
JUNOS Routing Software Suite [8.4R4.2]

Below the drawing of the lab I built, I took the lab setup from the Juniper JNCIP study guide.

After installing it I used an intelligent script which I found on this site. This script makes it possible to start all routers with one simple command, with this script you can also stop and start 1 router a time.

OSPF Totally NSSA Area

Chris van den Brink, CCIE #21047 — Sun, 13 Dec 2009 20:13:45 +0000

This post will be about OSPF Totally Not-So-Stubby-Area’s. In the previous posts we talked about the OSPF nssa area type. For this post I will use the same topology as in the previous two posts, see below :

Let’s configure area 2 as a totally not-so-stubby-area. We need to configure the ABR with the area x nssa no-summary command and the rest of the routers in the area with the area x nssa command. See below :

R4 & R2 :


R4(config)#router ospf 1
R4(config-router)#area 2 nssa no-summary

R2(config)#router ospf 1
R2(config-router)#area 2 nssa

Now let’s look at the routing table of router R2 :

R2 :


R2#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is 192.168.14.4 to network 0.0.0.0

     2.0.0.0/32 is subnetted, 1 subnets
C       2.2.2.2 is directly connected, Loopback0
C    192.168.14.0/24 is directly connected, FastEthernet2/0
O*IA 0.0.0.0/0 [110/2] via 192.168.14.4, 00:09:05, FastEthernet2/0

R2#sh ip ospf dat

            OSPF Router with ID (2.2.2.2) (Process ID 1)

                Router Link States (Area 2)

Link ID         ADV Router      Age         Seq#       Checksum Link count
2.2.2.2         2.2.2.2         574         0x80000004 0x0027FD 1
4.4.4.4         4.4.4.4         573         0x80000004 0x00B35C 1

                Net Link States (Area 2)

Link ID         ADV Router      Age         Seq#       Checksum
192.168.14.4    4.4.4.4         573         0x80000003 0x00414D

                Summary Net Link States (Area 2)

Link ID         ADV Router      Age         Seq#       Checksum
0.0.0.0         4.4.4.4         578         0x80000001 0x00C065

As you can see in an totally not-so-stubby-area LSA types 3,4,5 will be blocked. A default-route is generated by the ABR.

OSPF NSSA Area

Chris van den Brink, CCIE #21047 — Sun, 06 Dec 2009 21:51:05 +0000

This post will be about OSPF Not-So-Stubby-Area’s. In the previous posts we talked about stubby and not-so-stubby-area’s. For this post I will use the same topology as in the previous two posts, see below :

On Router 1 we again redistribute the interface 172.20.1.1/24 into OSPF :

R1 :


router ospf 1
 router-id 1.1.1.1
 log-adjacency-changes
 redistribute connected subnets route-map CONNECTED
 network 172.16.15.1 0.0.0.0 area 51
!
route-map CONNECTED permit 10
 match interface FastEthernet3/0
!
interface FastEthernet3/0
 ip address 172.20.1.1 255.255.255.0
 duplex auto
 speed auto

Let’s make area 2 a nssa area and see how it impacts the LSA’s and the routing-table.

We need to issue the “area 2 nssa” command on Router 2 and Router 4.

R2 :


Router 2 :

router ospf 1
 router-id 2.2.2.2
 log-adjacency-changes
 area 2 nssa
 network 192.168.14.2 0.0.0.0 area 2

Router 4 :
router ospf 1
 router-id 4.4.4.4
 log-adjacency-changes
 area 2 nssa
 network 10.1.34.4 0.0.0.0 area 0
 network 192.168.14.4 0.0.0.0 area 2

Now let’s take a look at the routing-table and the OSPF database on Router 2 :

R2 :


R2#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     2.0.0.0/32 is subnetted, 1 subnets
C       2.2.2.2 is directly connected, Loopback0
C    192.168.14.0/24 is directly connected, FastEthernet2/0
     172.16.0.0/24 is subnetted, 1 subnets
O IA    172.16.15.0 [110/4] via 192.168.14.4, 01:29:51, FastEthernet2/0
     10.0.0.0/24 is subnetted, 2 subnets
O IA    10.1.35.0 [110/3] via 192.168.14.4, 01:29:51, FastEthernet2/0
O IA    10.1.34.0 [110/2] via 192.168.14.4, 01:29:51, FastEthernet2/0
R2#sh ip ospf database

            OSPF Router with ID (2.2.2.2) (Process ID 1)

                Router Link States (Area 2)

Link ID         ADV Router      Age         Seq#       Checksum Link count
2.2.2.2         2.2.2.2         1412        0x80000008 0x001F02 1
4.4.4.4         4.4.4.4         1402        0x80000008 0x00AB60 1

                Net Link States (Area 2)

Link ID         ADV Router      Age         Seq#       Checksum
192.168.14.4    4.4.4.4         1402        0x80000007 0x003951

                Summary Net Link States (Area 2)

Link ID         ADV Router      Age         Seq#       Checksum
10.1.34.0       4.4.4.4         412         0x80000007 0x00AE44
10.1.35.0       4.4.4.4         412         0x80000005 0x00B141
172.16.15.0     4.4.4.4         412         0x80000005 0x00A1B2

As you can see a NSSA area blocks type 4 & type 5 LSA’s and doesn’t originate a default-route by default.

Although the ABR doesn’t originate a default-route in a NSSA area by default it is possible to let the ABR originate a default route, this can be done like below on the ABR :

R4 :


R4(config-router)#area 2 nssa default-information-originate

Now let’s take a look on Router 2 again :

R2 :


R2#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is 192.168.14.4 to network 0.0.0.0

     2.0.0.0/32 is subnetted, 1 subnets
C       2.2.2.2 is directly connected, Loopback0
C    192.168.14.0/24 is directly connected, FastEthernet2/0
     172.16.0.0/24 is subnetted, 1 subnets
O IA    172.16.15.0 [110/4] via 192.168.14.4, 01:34:36, FastEthernet2/0
     10.0.0.0/24 is subnetted, 2 subnets
O IA    10.1.35.0 [110/3] via 192.168.14.4, 01:34:36, FastEthernet2/0
O IA    10.1.34.0 [110/2] via 192.168.14.4, 01:34:36, FastEthernet2/0
O*N2 0.0.0.0/0 [110/1] via 192.168.14.4, 00:01:46, FastEthernet2/0
R2#sh ip ospf database

            OSPF Router with ID (2.2.2.2) (Process ID 1)

                Router Link States (Area 2)

Link ID         ADV Router      Age         Seq#       Checksum Link count
2.2.2.2         2.2.2.2         1696        0x80000008 0x001F02 1
4.4.4.4         4.4.4.4         1686        0x80000008 0x00AB60 1

                Net Link States (Area 2)

Link ID         ADV Router      Age         Seq#       Checksum
192.168.14.4    4.4.4.4         1686        0x80000007 0x003951

                Summary Net Link States (Area 2)

Link ID         ADV Router      Age         Seq#       Checksum
10.1.34.0       4.4.4.4         695         0x80000007 0x00AE44
10.1.35.0       4.4.4.4         695         0x80000005 0x00B141
172.16.15.0     4.4.4.4         695         0x80000005 0x00A1B2

                Type-7 AS External Link States (Area 2)

Link ID         ADV Router      Age         Seq#       Checksum Tag
0.0.0.0         4.4.4.4         113         0x80000001 0x00B372 0

As you can see a default-route is now originated by the ABR. This is the type 7 (N2) LSA.

The next post will be about the OSPF totally not so stubby area type.

OSPF Totally Stubby Area

Chris van den Brink, CCIE #21047 — Sun, 06 Dec 2009 13:33:06 +0000

In my previous post I talked about OSPF stub area’s and how they impact the routing table and the OSPF database. This post will be about totally stubby area’s in OSPF.

I will continue this post where the previous post stopped. The diagram that will be used in this post is also the same, see below :

As you can see in the previous post stubby-area’s remove LSA type 4 & type 5 routes and replaces the type 5 LSA with a default-route. See below the routing table when R2 & R4 are configured with the “area 2 stub” command under the OSPF proces :

R2 :



R2#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is 192.168.14.4 to network 0.0.0.0

     2.0.0.0/32 is subnetted, 1 subnets
C       2.2.2.2 is directly connected, Loopback0
C    192.168.14.0/24 is directly connected, FastEthernet2/0
     172.16.0.0/24 is subnetted, 1 subnets
O IA    172.16.15.0 [110/4] via 192.168.14.4, 00:01:59, FastEthernet2/0
     10.0.0.0/24 is subnetted, 2 subnets
O IA    10.1.35.0 [110/3] via 192.168.14.4, 00:01:59, FastEthernet2/0
O IA    10.1.34.0 [110/2] via 192.168.14.4, 00:01:59, FastEthernet2/0
O*IA 0.0.0.0/0 [110/2] via 192.168.14.4, 00:01:59, FastEthernet2/0

R2#sh ip ospf database

            OSPF Router with ID (2.2.2.2) (Process ID 1)

                Router Link States (Area 2) <-- LSA type 1

Link ID         ADV Router      Age         Seq#       Checksum Link count
2.2.2.2         2.2.2.2         136         0x80000005 0x009D8E 1
4.4.4.4         4.4.4.4         136         0x80000005 0x0024F4 1

                Net Link States (Area 2) <-- LSA type 2

Link ID         ADV Router      Age         Seq#       Checksum
192.168.14.4    4.4.4.4         132         0x80000004 0x00B7DD

                Summary Net Link States (Area 2) <-- LSA type 3

Link ID         ADV Router      Age         Seq#       Checksum
0.0.0.0         4.4.4.4         154         0x80000001 0x0039F4
10.1.34.0       4.4.4.4         154         0x80000005 0x002BD1
10.1.35.0       4.4.4.4         154         0x80000003 0x002ECE
172.16.15.0     4.4.4.4         154         0x80000003 0x001E40

To configure an area as a totally stubby area you only need to issue the command “area 2 stub no-summary” under the OSPF process on the ABR.

So on Router 4 :

R4 :


R4(config)#router ospf 1
R4(config-router)#area 2 stub no-summary

Now let’s take a look at the routing-table and the OSPF database so we can compare this with the “stub area” routing-table and the OSPF database on Router R2:

R2 :


R2#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is 192.168.14.4 to network 0.0.0.0

     2.0.0.0/32 is subnetted, 1 subnets
C       2.2.2.2 is directly connected, Loopback0
C    192.168.14.0/24 is directly connected, FastEthernet2/0
O*IA 0.0.0.0/0 [110/2] via 192.168.14.4, 00:02:36, FastEthernet2/0
R2#sh ip ospf dat

            OSPF Router with ID (2.2.2.2) (Process ID 1)

                Router Link States (Area 2) <-- LSA type 1

Link ID         ADV Router      Age         Seq#       Checksum Link count
2.2.2.2         2.2.2.2         169         0x80000005 0x009D8E 1
4.4.4.4         4.4.4.4         145         0x80000005 0x0024F4 1

                Net Link States (Area 2) <-- LSA type 2

Link ID         ADV Router      Age         Seq#       Checksum
192.168.14.4    4.4.4.4         145         0x80000004 0x00B7DD

                Summary Net Link States (Area 2) <-- Default route replaces all LSA type 3 routes 

Link ID         ADV Router      Age         Seq#       Checksum
0.0.0.0         4.4.4.4         172         0x80000001 0x0039F4

As you can see in the routing-table and the OSPF database above not only the LSA type 4 & 5 routes are gone but also the type 3 LSA’s are no longer there. So for totally stubby area’s we can state that no type 3,4 and 5 LSA’s are allowed. A default route is injected into the area from the ABR.

The next post will be about the OSPF NSSA type.