Basic Junos MPLS based IP-VPNs

This post will cover how to set up and verify a basic MPLS based Unicast IPv4 VPN configuration using Junos.

This topology has 5 Routers:

Two CE routers each BGP peering with to two MPLS PE routers which are connected via a MPLS P router.  The P router is also acting as a BGP Route-Reflector.  The P/PE network is also using OSPF to support LDP and BGP loopback reachability:

R1(CE)-EBGP-R2(PE)-IBGP-R3(P)-IBGP-R4(PE)-EBGP-R5(CE)

We'll start with the PE and P configurations first

R2-PE

root@R2-PE> show configuration | display set
set system host-name R2-PE
set interfaces em1 vlan-tagging
set interfaces em1 unit 23 vlan-id 23
set interfaces em1 unit 23 family inet address 10.1.23.2/24
set interfaces lo0 unit 0 family inet address 2.2.2.2/32
set routing-options router-id 2.2.2.2
set protocols ospf area 0.0.0.0 interface em1.23
set protocols ospf area 0.0.0.0 interface lo0.0

So far this is just setting up the IGP so R2-PE will be able to communicate with R3-P

To enable MPLS, we need to add the protocol family to the interface so the interface will not discard MPLS traffic hitting it and then we need to add the interface to the protocol to establish the control plane level connectivity.  Finally to establish a mechanism to distribute MPLS labels, we turn on LDP.

root@R2-PE> configure
Entering configuration mode

[edit]
root@R2-PE# set interfaces em1 unit 23 family mplsroot@R2-PE# set protocols mpls interface em1.23root@R2-PE# set protocols ldp interface em1.23

Now we set up the IBGP connection to peer with R3-P only using the IPv4 VPN Unicast Address Family - note we are setting the local address to be the same as lo0.0

[edit]
root@R2-PE# set routing-options autonomous-system 65500
root@R2-PE# edit protocols bgp group Core
[edit protocols bgp group Core]
root@R2-PE# set type internal
root@R2-PE# set local-address 2.2.2.2
root@R2-PE# set family inet-vpn unicast
root@R2-PE# set peer-as 65500
root@R2-PE# set neighbor 3.3.3.3
root@R2-PE# commit and-quit
commit complete
Exiting configuration mode

The configuration for R4-PE is very similar to R2-PE

root@R4-PE> show configuration | display set
set system host-name R4-PE
set interfaces em1 vlan-tagging
set interfaces em1 unit 34 vlan-id 34
set interfaces em1 unit 34 family inet address 10.1.34.4/24
set interfaces lo0 unit 0 family inet address 4.4.4.4/32
set routing-options router-id 4.4.4.4
set protocols ospf area 0.0.0.0 interface lo0.0
set protocols ospf area 0.0.0.0 interface em1.34

set interfaces em1 unit 34 family mpls
set protocols mpls interface em1.34
set protocols ldp interface em1.34

set routing-options autonomous-system 65500
set protocols bgp group Core type internal
set protocols bgp group Core local-address 4.4.4.4
set protocols bgp group Core family inet-vpn unicast
set protocols bgp group Core peer-as 65500
set protocols bgp group Core neighbor 3.3.3.3

For R3-P - the configuration is very similar as to what has occured for R2-PE and R4-PE.  The primary difference here is that R3-P is a BGP route-reflector.  Within the configured BGP peer group, once the cluster id is set, the router is now acting as a route reflector

root@R3-P> show configuration | display set
set system host-name R3-P
set interfaces em1 vlan-tagging
set interfaces em1 unit 23 vlan-id 23
set interfaces em1 unit 23 family inet address 10.1.23.3/24
set interfaces em1 unit 34 vlan-id 34
set interfaces em1 unit 34 family inet address 10.1.34.3/24
set interfaces lo0 unit 0 family inet address 3.3.3.3/32
set routing-options router-id 3.3.3.3
set protocols ospf area 0.0.0.0 interface em1.23
set protocols ospf area 0.0.0.0 interface lo0.0
set protocols ospf area 0.0.0.0 interface em1.34

set interfaces em1 unit 23 family mpls
set interfaces em1 unit 34 family mpls
set protocols mpls interface em1.23
set protocols mpls interface em1.34
set protocols ldp interface em1.23
set protocols ldp interface em1.34

set routing-options autonomous-system 65500
set protocols bgp group Core-RRClients type internal
set protocols bgp group Core-RRClients local-address 3.3.3.3
set protocols bgp group Core-RRClients family inet-vpn unicast

set protocols bgp group Core-RRClients cluster 3.3.3.3 
set protocols bgp group Core-RRClients peer-as 65500
set protocols bgp group Core-RRClients neighbor 2.2.2.2
set protocols bgp group Core-RRClients neighbor 4.4.4.4

root@R3-P> show bgp neighbor | match "^Peer:|Type"
Peer: 2.2.2.2+64071 AS 65500   Local: 3.3.3.3+179 AS 65500
  Type: Internal    State: Established  (route reflector client)Flags:
Peer: 4.4.4.4+54609 AS 65500   Local: 3.3.3.3+179 AS 65500
  Type: Internal    State: Established  (route reflector client)Flags:

So at this stage, we have our core network MP-BGP enabled, MPLS/LDP active but no L3 VPN configuration yet

root@R2-PE> show bgp neighbor | match "^Peer:|Address families"
Peer: 3.3.3.3+179 AS 65500     Local: 2.2.2.2+64071 AS 65500
  Address families configured: inet-vpn-unicast

root@R2-PE> show route table inet.3

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

3.3.3.3/32         *[LDP/9] 00:26:46, metric 1
                    > to 10.1.23.3 via em1.23
4.4.4.4/32         *[LDP/9] 00:03:07, metric 1
                    > to 10.1.23.3 via em1.23, Push 299840

root@R3-P> show bgp neighbor | match "^Peer:|Address families"
Peer: 2.2.2.2+64071 AS 65500   Local: 3.3.3.3+179 AS 65500
  Address families configured: inet-vpn-unicast
Peer: 4.4.4.4+54609 AS 65500   Local: 3.3.3.3+179 AS 65500
  Address families configured: inet-vpn-unicast

root@R3-P> show route table inet.3

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

2.2.2.2/32         *[LDP/9] 00:04:14, metric 1
                    > to 10.1.23.2 via em1.23
4.4.4.4/32         *[LDP/9] 00:04:10, metric 1
                    > to 10.1.34.4 via em1.34

root@R4-PE> show bgp neighbor | match "^Peer:|Address families"
Peer: 3.3.3.3+179 AS 65500     Local: 4.4.4.4+54609 AS 65500
  Address families configured: inet-vpn-unicast

root@R4-PE> show route table inet.3

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

2.2.2.2/32         *[LDP/9] 00:04:48, metric 1
                    > to 10.1.34.3 via em1.34, Push 299872
3.3.3.3/32         *[LDP/9] 00:04:48, metric 1
                    > to 10.1.34.3 via em1.34

Lets create the Routing-Instance (VRF) on the PEs

Starting on R2 - we define the IP interface in the base router configuration facing R1-CE

root@R2-PE> configure
Entering configuration mode

[edit]
root@R2-PE# set interfaces em1 unit 12 vlan-id 12
root@R2-PE# set interfaces em1 unit 12 family inet address 10.1.12.2/24


Then the rest of the configuration will be contained within a routing-instance CustomerA

Firstly we add the interface to the routing instance and define the instance to be a vrf and set the L3 VPN's RD and RT values:

root@R2-PE# edit routing-instances CustomerA

[edit routing-instances CustomerA]
root@R2-PE# set interface em1.12
root@R2-PE# set instance-type vrf
root@R2-PE# set route-distinguisher 65500:1
root@R2-PE# set vrf-target target:65500:1

The following command is a hack used on Olives which doesn't have a tunnel services PIC to assist in the double label lookup, so normally isn't required on real platforms.

[edit routing-instances CustomerA]

root@R2-PE# set vrf-table-label

Now we set up the BGP configuration to peer with our R1-CE


[edit routing-instances CustomerA]
root@R2-PE# edit protocols bgp group CE

[edit routing-instances CustomerA protocols bgp group CE]
root@R2-PE# set type external
root@R2-PE# set family inet unicast
root@R2-PE# set neighbor 10.1.12.1 peer-as 64512
root@R2-PE# commit and-quit
commit complete
Exiting configuration mode

For R4-PE the configuration is similar (R5-CE is in AS 64513)

root@R4-PE> configure
Entering configuration mode

[edit]
root@R4-PE# set interfaces em1 unit 45 vlan-id 45
root@R4-PE# set interfaces em1 unit 45 family inet address 10.1.45.4/24
root@R4-PE# edit routing-instances CustomerA

[edit routing-instances CustomerA]
root@R4-PE# set instance-type vrf
root@R4-PE# set interface em1.45
root@R4-PE# set route-distinguisher 65500:1
root@R4-PE# set vrf-target target:65500:1
root@R4-PE# set vrf-table-label
root@R4-PE# edit protocols bgp group CE

[edit routing-instances CustomerA protocols bgp group CE]
root@R4-PE# set type external
root@R4-PE# set family inet unicast
root@R4-PE# set neighbor 10.1.45.5 peer-as 64513
root@R4-PE# commit and-quit
commit complete
Exiting configuration mode

The CE Configurations are quite straight forward - each has an EBGP peering with the MPLS PE and redistributes it's directly connected interfaces into BGP with the intention that each CE will have reachability to the others lo0.0 interface.

root@R1-CE> show configuration | display set
set system host-name R1-CE
set interfaces em1 vlan-tagging
set interfaces em1 unit 12 vlan-id 12
set interfaces em1 unit 12 family inet address 10.1.12.1/24
set interfaces lo0 unit 0 family inet address 1.1.1.1/32
set routing-options autonomous-system 64512
set protocols bgp export ToBGP
set protocols bgp group PE type external
set protocols bgp group PE family inet unicast
set protocols bgp group PE peer-as 65500
set protocols bgp group PE neighbor 10.1.12.2
set policy-options policy-statement ToBGP term Direct from protocol direct
set policy-options policy-statement ToBGP term Direct then accept

root@R5-CE> show configuration | display set
set system host-name R5-CE
set interfaces em1 vlan-tagging
set interfaces em1 unit 45 vlan-id 45
set interfaces em1 unit 45 family inet address 10.1.45.5/24
set interfaces lo0 unit 0 family inet address 5.5.5.5/32
set routing-options router-id 5.5.5.5
set routing-options autonomous-system 64513
set protocols bgp export ToBGP
set protocols bgp group PE type external
set protocols bgp group PE family inet unicast
set protocols bgp group PE peer-as 65500
set protocols bgp group PE neighbor 10.1.45.4
set policy-options policy-statement ToBGP term Direct from protocol direct
set policy-options policy-statement ToBGP term Direct then accept


Lets verify that things are operational First lets check the control plane view


root@R1-CE> show route terse

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

A Destination        P Prf   Metric 1   Metric 2  Next hop        AS path
* 1.1.1.1/32         D   0                       >lo0.0
* 5.5.5.5/32         B 170        100            >10.1.12.2       65500 64513 I
* 10.1.12.0/24       D   0                       >em1.12
* 10.1.12.1/32       L   0                        Local
* 10.1.45.0/24       B 170        100            >10.1.12.2       65500 I

R1 can see R5's loopback and the BGP AS path is as expected.

Lets track how things get there through the Core

root@R2-PE> show route instance CustomerA
Instance             Type
         Primary RIB                                     Active/holddown/hidden
CustomerA            vrf
         CustomerA.inet.0                                5/0/0

root@R2-PE> show route table CustomerA.inet.0

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

1.1.1.1/32         *[BGP/170] 00:16:58, localpref 100
                      AS path: 64512 I
                    > to 10.1.12.1 via em1.12
5.5.5.5/32         *[BGP/170] 00:06:01, localpref 100, from 3.3.3.3
                      AS path: 64513 I
                    > to 10.1.23.3 via em1.23, Push 16, Push 299840(top)
10.1.12.0/24       *[Direct/0] 00:17:02
                    > via em1.12
                    [BGP/170] 00:16:58, localpref 100
                      AS path: 64512 I
                    > to 10.1.12.1 via em1.12
10.1.12.2/32       *[Local/0] 00:17:02
                      Local via em1.12
10.1.45.0/24       *[BGP/170] 00:11:23, localpref 100, from 3.3.3.3
                      AS path: I
                    > to 10.1.23.3 via em1.23, Push 16, Push 299840(top)


The Top label should be the label that gets us to R4-PE

root@R2-PE> show route table inet.3

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

3.3.3.3/32         *[LDP/9] 00:41:33, metric 1
                    > to 10.1.23.3 via em1.23
4.4.4.4/32         *[LDP/9] 00:36:07, metric 1
                    > to 10.1.23.3 via em1.23, Push 299840

On the Route Reflector we can see that the VPN Label matches up as well

root@R3-P> show route table bgp.l3vpn.0 5.5.5.5/32

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

65500:1:5.5.5.5/32
                   *[BGP/170] 00:43:02, localpref 100, from 4.4.4.4
                      AS path: 64513 I
                    > to 10.1.34.4 via em1.34, Push 16


Which we can confirm that Label 16 on R4-PE refers to the CustomerA.inet.0 routing table.

root@R4-PE> show route table mpls

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

0                  *[MPLS/0] 02:21:40, metric 1
                      Receive
1                  *[MPLS/0] 02:21:40, metric 1
                      Receive
2                  *[MPLS/0] 02:21:40, metric 1
                      Receive
16                 *[VPN/0] 00:51:50
                      to table CustomerA.inet.0, Pop
300112             *[LDP/9] 00:51:37, metric 1
                    > to 10.1.34.3 via em1.34, Pop
300112(S=0)        *[LDP/9] 00:51:37, metric 1
                    > to 10.1.34.3 via em1.34, Pop
300128             *[LDP/9] 00:51:37, metric 1
                    > to 10.1.34.3 via em1.34, Swap 299872

All this certainly indicates that we should have connectivity from R1-CE to R5-CE, so lets verify it:

root@R1-CE> ping 5.5.5.5 source 1.1.1.1 count 3
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=6.351 ms
64 bytes from 5.5.5.5: icmp_seq=1 ttl=63 time=3.656 ms
64 bytes from 5.5.5.5: icmp_seq=2 ttl=63 time=4.496 ms

--- 5.5.5.5 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 3.656/4.834/6.351/1.126 ms

Yes we do.

OSPF External Route Summarization

Currently my CCIE studies are taking a slight detour while renew and upgrade one of my Juniper Certifications, so lately my current study area has been focused on Junos.  Just to be a little different today I'm going to discuss an OSPF operation and demonstrate it in IOS and then Junos.

The prime message I want to give here is that summarizing of OSPF external routes in certain circumstances occur at multiple places within the network.  Some people may believe that you can only summarize on the OSPF ASBR, however if you have that ASBR in an OSPF NSSA Area, the ABR can also summarize those external routes.  This is because summarization of external routes can occur on the OSPF router that originates the Type 5 or Type 7 LSAs and the ABR will convert Type 7s to Type 5s.

The demonstration topology, configuration and verification (using IOS first, with Junos following on)  is below:


R1 is an ASBR with Fa0/0 in Area 12 (NSSA)
R2 is an ABR with Fa0/0 in Area 12 (NSSA) and S0/0.23 in Area 0 (Backbone)
R3 is a Regular OSPF Router with S0/0.32 in Area 0

R1
hostname R1
!
interface FastEthernet0/0
 ip address 10.1.12.1 255.255.255.0
 ip ospf 1 area 12
!
router ospf 1
 router-id 1.1.1.1
 area 12 nssa
 redistribute static metric 100 subnets
!
ip route 1.1.1.0 255.255.255.0 Null0

R2
hostname R2
!
interface FastEthernet0/0
 ip address 10.1.12.2 255.255.255.0
 ip ospf 1 area 12
 duplex auto
 speed auto
!
interface Serial0/0
 no ip address
 encapsulation frame-relay
 no frame-relay inverse-arp
!
interface Serial0/0.23 point-to-point
 ip address 10.1.23.2 255.255.255.0
 ip ospf 1 area 0
 frame-relay interface-dlci 203
!
router ospf 1
 router-id 2.2.2.2
 area 12 nssa

R3
hostname R3
!
interface Serial0/0
 no ip address
 encapsulation frame-relay
 clock rate 2000000
 no frame-relay inverse-arp
!
interface Serial0/0.32 point-to-point
 ip address 10.1.23.3 255.255.255.0
 ip ospf 1 area 0
 frame-relay interface-dlci 302
!
router ospf 1
 router-id 3.3.3.3

We'll take a baseline verification to make sure we can see 1.1.1.0/24

R2#sh ip route ospf
     1.0.0.0/24 is subnetted, 1 subnets
O N2    1.1.1.0 [110/100] via 10.1.12.1, 00:01:25, FastEthernet0/0


R3#sh ip route ospf
     1.0.0.0/24 is subnetted, 1 subnets
O E2    1.1.1.0 [110/100] via 10.1.23.2, 00:01:14, Serial0/0.32
     10.0.0.0/24 is subnetted, 2 subnets
O IA    10.1.12.0 [110/74] via 10.1.23.2, 00:19:39, Serial0/0.32

All good and we can see that R2 is performing the Type 7 (N2) to Type 5 (E2) conversion.


Let's summarize R1

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#router ospf 1
R1(config-router)#summary-address 1.1.0.0 255.255.0.0
R1(config-router)#end

R2#sh ip route ospf
     1.0.0.0/16 is subnetted, 1 subnets
O N2    1.1.0.0 [110/100] via 10.1.12.1, 00:00:31, FastEthernet0/0


R3#sh ip route ospf
     1.0.0.0/16 is subnetted, 1 subnets
O E2    1.1.0.0 [110/100] via 10.1.23.2, 00:00:35, Serial0/0.32
     10.0.0.0/24 is subnetted, 2 subnets
O IA    10.1.12.0 [110/74] via 10.1.23.2, 00:20:57, Serial0/0.32

So the point of the exercise is to demonstrate summarization on R2, so let's do it

R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#router ospf 1
R2(config-router)#summary-address 1.0.0.0 255.0.0.0
R2(config-router)#end

R3#sh ip route ospf
O E2 1.0.0.0/8 [110/100] via 10.1.23.2, 00:00:10, Serial0/0.32
     10.0.0.0/24 is subnetted, 2 subnets
O IA    10.1.12.0 [110/74] via 10.1.23.2, 00:22:29, Serial0/0.32

Yes it does - R2 is not an ABR but it is originating Type 5 LSAs (when it converts the Type 7s from R1) Therefore we have verified that summarization can occur on OSPF routers that originates Type 5 or Type 7 LSAs


We can demonstrate the same thing using Junos but it is somewhat different in the method execution

R1 is an ASBR with em1.12 in Area 12 (NSSA)
R2 is an ABR with em1.12 in Area 12 (NSSA) and em1.23 in Area 0 (Backbone)
R3 is a Regular OSPF Router with em1.23 in Area 0

Unlike IOS, we need to specifically create a policy to redistribute static routes into OSPF, below are our baseline configurations

root@R1> show configuration | display set
set system host-name R1
set interfaces em1 vlan-tagging
set interfaces em1 unit 12 vlan-id 12
set interfaces em1 unit 12 family inet address 10.1.12.1/24
set routing-options static route 1.1.1.0/24 discard
set routing-options router-id 1.1.1.1
set protocols ospf export ExternalToOSPF
set protocols ospf area 0.0.0.12 nssa
set protocols ospf area 0.0.0.12 interface em1.12
set policy-options policy-statement ExternalToOSPF term Static from protocol static
set policy-options policy-statement ExternalToOSPF term Static to protocol ospf
set policy-options policy-statement ExternalToOSPF term Static then metric 100
set policy-options policy-statement ExternalToOSPF term Static then accept

root@R2> show configuration | display set
set system host-name R2
set interfaces em1 vlan-tagging
set interfaces em1 unit 12 vlan-id 12
set interfaces em1 unit 12 family inet address 10.1.12.2/24
set interfaces em1 unit 23 vlan-id 23
set interfaces em1 unit 23 family inet address 10.1.23.2/24
set routing-options router-id 2.2.2.2
set protocols ospf area 0.0.0.12 nssa
set protocols ospf area 0.0.0.12 interface em1.12
set protocols ospf area 0.0.0.0 interface em1.23

root@R3> show configuration | display set
set system host-name R3
set interfaces em1 vlan-tagging
set interfaces em1 unit 23 vlan-id 23
set interfaces em1 unit 23 family inet address 10.1.23.3/24
set routing-options router-id 3.3.3.3
set protocols ospf area 0.0.0.0 interface em1.23

Lets verify the baseline routing table:

root@R2> show ospf route network
Topology default Route Table:

Prefix             Path  Route      NH       Metric NextHop       Nexthop
                   Type  Type       Type            Interface     Address/LSP
1.1.1.0/24         Ext2  Network    IP          100 em1.12        10.1.12.1
10.1.12.0/24       Intra Network    IP            1 em1.12
10.1.23.0/24       Intra Network    IP            1 em1.23

root@R2> show ospf route network 1.1.1.0/24 extensive
Topology default Route Table:

Prefix             Path  Route      NH       Metric NextHop       Nexthop
                   Type  Type       Type            Interface     Address/LSP
1.1.1.0/24         Ext2  Network    IP          100 em1.12        10.1.12.1
  area 0.0.0.12, origin 1.1.1.1, type 7, P-bit, fwd NZ, priority medium



root@R3> show ospf route network
Topology default Route Table:

Prefix             Path  Route      NH       Metric NextHop       Nexthop
                   Type  Type       Type            Interface     Address/LSP
1.1.1.0/24         Ext2  Network    IP          100 em1.23        10.1.23.2
10.1.12.0/24       Inter Network    IP            2 em1.23        10.1.23.2
10.1.23.0/24       Intra Network    IP            1 em1.23

root@R3> show ospf route network 1.1.1.0/24 extensive
Topology default Route Table:

Prefix             Path  Route      NH       Metric NextHop       Nexthop
                   Type  Type       Type            Interface     Address/LSP
1.1.1.0/24         Ext2  Network    IP          100 em1.23        10.1.23.2
  area 0.0.0.0, origin 2.2.2.2, fwd NZ, priority medium

Without examining the route in more detail we weren't able to determine as easily if the external route was from an NSSA area or not.

Summarization on R1 requires a bit more effort than what we used IOS as well - First we need to set up an aggregate route (in Junos, aggregate routes are considered their own protocol) and redistribute that into OSPF.

root@R1> configure
Entering configuration mode

[edit]
set routing-options aggregate route 1.1.0.0/16
set policy-options policy-statement ExternalToOSPF term Aggregate to protocol ospf
set policy-options policy-statement ExternalToOSPF term Aggregate then metric 100
set policy-options policy-statement ExternalToOSPF term Aggregate then accept

If we leave it like this, we'll find that the 1.1.1.0/24 static route will still be advertised, so we need a method to be able to remove that - In this example we will set up a prefix list that if matched will stop the route being advertised, while still letting other static routes through

[edit]
set policy-options prefix-list Drop 1.1.1.0/24
set policy-options policy-statement ExternalToOSPF term Drop from prefix-list Drop
set policy-options policy-statement ExternalToOSPF term Drop then reject

All that's left to do is to ensure the Drop term gets evaluated first

[edit]
root@R1# insert policy-options policy-statement ExternalToOSPF term Drop before term Static

Let's examine the complete policy

root@R1# show policy-options
prefix-list Drop {
    1.1.1.0/24;
}
policy-statement ExternalToOSPF {
    term Drop {
        from {
            prefix-list Drop;
        }
        then reject;
    }
    term Static {
        from protocol static;
        to protocol ospf;
        then {
            metric 100;
            accept;
        }
    }
    term Aggregate {
        from protocol aggregate;
        to protocol ospf;
        then {
            metric 100;
            accept;
        }
    }
}


looks good, so lets apply it.

[edit]
root@R1# commit and-quit
commit complete

Now to see if the aggregate is appearing beyond R1

root@R2> show ospf route network
Topology default Route Table:

Prefix             Path  Route      NH       Metric NextHop       Nexthop
                   Type  Type       Type            Interface     Address/LSP
1.1.0.0/16         Ext2  Network    IP          100 em1.12        10.1.12.1
10.1.12.0/24       Intra Network    IP            1 em1.12
10.1.23.0/24       Intra Network    IP            1 em1.23

root@R2> show ospf route network 1.1.0.0/16 extensive
Topology default Route Table:

Prefix             Path  Route      NH       Metric NextHop       Nexthop
                   Type  Type       Type            Interface     Address/LSP
1.1.0.0/16         Ext2  Network    IP          100 em1.12        10.1.12.1
  area 0.0.0.12, origin 1.1.1.1, type 7, P-bit, fwd NZ, priority medium


root@R3> show ospf route network
Topology default Route Table:

Prefix             Path  Route      NH       Metric NextHop       Nexthop
                   Type  Type       Type            Interface     Address/LSP
1.1.0.0/16         Ext2  Network    IP          100 em1.23        10.1.23.2
10.1.12.0/24       Inter Network    IP            2 em1.23        10.1.23.2
10.1.23.0/24       Intra Network    IP            1 em1.23

root@R3> show ospf route network 1.1.0.0/16 extensive
Topology default Route Table:

Prefix             Path  Route      NH       Metric NextHop       Nexthop
                   Type  Type       Type            Interface     Address/LSP
1.1.0.0/16         Ext2  Network    IP          100 em1.23        10.1.23.2
  area 0.0.0.0, origin 2.2.2.2, fwd NZ, priority medium

Believe it or not, performing the summarization on R2 for R3 is very simple.

root@R2> configure
Entering configuration mode

[edit]
root@R2# set protocols ospf area 12 nssa area-range 1.0.0.0/8

[edit]
root@R2# commit and-quit
commit complete
Exiting configuration mode

To verify:

root@R3> show ospf route network
Topology default Route Table:

Prefix             Path  Route      NH       Metric NextHop       Nexthop
                   Type  Type       Type            Interface     Address/LSP
1.0.0.0/8          Ext2  Network    IP          101 em1.23        10.1.23.2
10.1.12.0/24       Inter Network    IP            2 em1.23        10.1.23.2
10.1.23.0/24       Intra Network    IP            1 em1.23

root@R3> show ospf route network 1.0.0.0/8 extensive
Topology default Route Table:

Prefix             Path  Route      NH       Metric NextHop       Nexthop
                   Type  Type       Type            Interface     Address/LSP
1.0.0.0/8          Ext2  Network    IP          101 em1.23        10.1.23.2
  area 0.0.0.0, origin 2.2.2.2, priority medium

So there you go, I'm not sure how useful this actually is in a production environment but in a lab exam, it may be an extra tool to get out of a sticky situation...