Tag Archives: OSPF

Segment Routed L2VPN TE – Cisco IOS-XR

27 Jun 2018CCIE, CCNP, Cisco, IOS-XR, MPLS, Networking, RSVP, SDNAutomation, Cisco, Controller, evpn, L2VPN, MPLS, Networking, OSPF, RSVP, SDN, segment routing, SPRING, TCP/IP, Traffic-EngineeringMohit

Hi All

Let’s see Segment routing in action in this blog particularly on IOS-XR. Segment routing is quite new concept which is picking pace these days. In my earlier blog I listed the differences between Segment routing and RSVP-TE and SR can replace it and there are certain areas where it may not be able to help however L3VPN and L2VPN Traffic Engineering is surely one area where it can be used and in this blog we will use SR as TE while configuring the L2VPN.

For this we will take NCS5508 as our router platform in below topology where we will configure the L2VPN SR-TE between NCS5508-1 to NCS5508-3 via NCS5508-8.

Let’s see the SR config first.

SR beauty is that there is no special protocol needed to run it. SR Labels will be advertised in OSPF/ISIS and these protocols have been uplifted to carry them. SR Labels are carried in Type 10 Opaque area LSA as TLV.

If you are familiar with OSPF config in IOS-XR, most of the config below looks similar to you as we have just enabled OSPF under area0 and added interfaces under it.

However there are 3 configs highlighted in RED which we have enabled for Segment routing.

RP/0/RP0/CPU0:ncs5508-1#show running-config router ospf
router ospf 1
 nsr
 distribute link-state
 segment-routing mpls
 nsf ietf
 segment-routing sr-prefer
 area 0
 mpls traffic-eng
 interface Loopback0
 passive enable
 prefix-sid index 1 explicit-null
 !
 interface HundredGigE0/1/0/0
 cost 1
 network point-to-point
 !
 interface FortyGigE0/2/0/8
 cost 4
 network point-to-point
 !
 interface FortyGigE0/2/0/10
 cost 4
 network point-to-point
 !
 interface FortyGigE0/2/0/18
 cost 4
 network point-to-point
 !
 !
 mpls traffic-eng router-id Loopback0
!

segment-routing mpls , this command causes OSPF to originate RI LSA, Extended Prefix and Extended Link LSAs. It enables MPLS on all interfaces in area(s) enabled for SR and programs SR MPLS labels for forwarding.

segment-routing sr-prefer is used to set the preference of segment routing (SR) labels over label distribution protocol (LDP) labels in case both are available towards destination in your network.

prefix-sid index 1 explicit-null — A prefix SID is associated with an IP prefix. The prefix SID is manually configured from the segment routing global block (SRGB) range of labels. The prefix segment steers the traffic along the shortest path to its destination. A node SID is a special type of prefix SID that identifies a specific node. It is configured under the loopback interface with the loopback address of the node as the prefix. The prefix SID is globally unique within the segment routing domain.

Let’s verify it

RP/0/RP0/CPU0:ncs5508-1#show ospf sid-database
SID Database for ospf 1 with ID 192.168.0.1

SID Prefix/Mask
-------- ------------------
1 192.168.0.1/32 (L)
2 192.168.0.2/32
3 192.168.0.3/32
4 192.168.0.4/32
5 192.168.0.5/32
6 192.168.0.6/32
7 192.168.0.7/32
8 192.168.0.8/32

In the same way we have configured the Node-SID as same index as last octet on lo0 interface.

RP/0/RP0/CPU0:ncs5508-1#show ospf database opaque-area 192.168.0.1/32
 OSPF Router with ID (192.168.0.1) (Process ID 1)
Type-10 Opaque Link Area Link States (Area 0)

LS age: 782
 Options: (No TOS-capability, DC)
 LS Type: Opaque Area Link
 Link State ID: 7.0.0.1
 Opaque Type: 7
 Opaque ID: 1
 Advertising Router: 192.168.0.1
 LS Seq Number: 800006fa
 Checksum: 0xed8b
 Length: 44
Extended Prefix TLV: Length: 20
 Route-type: 1
 AF : 0
 Flags : 0x40
 Prefix : 192.168.0.1/32
SID sub-TLV: Length: 8
 Flags : 0x50
 MTID : 0
 Algo : 0
 SID Index : 1

RP/0/RP0/CPU0:ncs5508-1#show mpls forwarding

Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes

Label  Label       or ID              Interface                    Switched

—— ———– —————— ———— ————— ————

16002  Exp-Null-v4 SR Pfx (idx 2)     Hu0/1/0/0    50.50.50.30     0
16003  16003       SR Pfx (idx 3)     Hu0/1/0/0    50.50.50.30     0
16004  Exp-Null-v4 SR Pfx (idx 4)     Fo0/2/0/8    50.50.50.25     0
16005  16005       SR Pfx (idx 5)     Fo0/2/0/8    50.50.50.25     6421133
16006  16006       SR Pfx (idx 6)     Hu0/1/0/0    50.50.50.30     0
       16006       SR Pfx (idx 6)     Fo0/2/0/8    50.50.50.25     0
16007  16007       SR Pfx (idx 7)     Hu0/1/0/0    50.50.50.30     0
16008  Exp-Null-v4 SR Pfx (idx 8)     Fo0/2/0/18   50.50.50.38     0

Now let’s create a Segment routed TE EVPN based P2P L2 Circuit. 🙂

Ideally we know that Controller is needed to play with Segment routed labels and Controller can insert the appropriate labels required for TE however if you don’t have Controller, you can configure the path by explicitly giving the path through which traffic will be going.

So we will start with l2vpn xconnect taking edge interface on NCS5508-1 and assigning a EVPN EVI 1100 with source and target ac-id (attachment circuit id) and associate it with pw-class which we will define in next step.

RP/0/RP0/CPU0:ncs5508-1#show running-config l2vpn xconnect group evpn-vpws p2p vpws1
l2vpn
 xconnect group evpn-vpws
 p2p vpws1
 interface HundredGigE0/2/0/2.1100
 neighbor evpn evi 1100 target 11003 source 11001
 pw-class vpws1-class
 !
 !
 !
!

Pw-class is associated with sr-te policy to steer traffic through the network. An SR-TE policy path is expressed as a list of segments that specifies the path, called a segment ID (SID) list. Each segment is an end-to-end path from the source to the destination, and instructs the routers in the network to follow the specified path instead of the shortest path calculated by the IGP

RP/0/RP0/CPU0:ncs5508-1#show running-config l2vpn pw-class vpws1-class
l2vpn
 pw-class vpws1-class
 encapsulation mpls
 preferred-path sr-te policy vpws1-policy
 !
 !
!

RP/0/RP0/CPU0:ncs5508-1#show running-config segment-routing traffic-eng policy vpws1-policy
segment-routing
 traffic-eng
 policy vpws1-policy
 color 10 end-point ipv4 192.168.0.3
 candidate-paths
 preference 200
 dynamic
 metric
 type te
 !
 !
 !
 preference 300
 explicit segment-list vpws1-path
 !
 !
 !
 !
 !
!

So in our policy, we have defined one preferred path which is dynamic and if that fails it should failover to explicitly configured segment list defined via path vpws1-path.

RP/0/RP0/CPU0:ncs5508-1#show running-config segment-routing traffic-eng segment-list vpws1-path
segment-routing
 traffic-eng
 segment-list vpws1-path
 index 10 address ipv4 50.50.50.38
 index 20 address ipv4 50.50.50.21
 !
 !
!

So if we see currently the route towards NCS5508-3, it’s going via IGP Route and not taking our defined list which is expected.

RP/0/RP0/CPU0:ncs5508-1#show route 192.168.0.3
Wed Jun 27 14:49:59.487 UTC

Routing entry for 192.168.0.3/32
 Known via "ospf 1", distance 110, metric 3, labeled SR, type intra area
 Installed Jun 27 14:47:18.930 for 00:02:40
 Routing Descriptor Blocks
 50.50.50.30, from 192.168.0.3, via HundredGigE0/1/0/0
 Route metric is 3
 No advertising protos.

So let’s see our L2VPN status.

RP/0/RP0/CPU0:ncs5508-1#show l2vpn xconnect group evpn-vpws detail

Group evpn-vpws, XC vpws1, state is up; Interworking none
 AC: HundredGigE0/2/0/2.1100, state is up
 Type VLAN; Num Ranges: 1
 Rewrite Tags: []
 VLAN ranges: [1100, 1100]
 MTU 9016; XC ID 0x1000001; interworking none
 Statistics:
 packets: received 157064234, sent 157063216
 bytes: received 234968088320, sent 234966565392
 drops: illegal VLAN 0, illegal length 0
 EVPN: neighbor 192.168.0.3, PW ID: evi 1100, ac-id 11003, state is up ( established )
 XC ID 0xc0000001
 Encapsulation MPLS
 Source address 192.168.0.1
 Encap type Ethernet, control word disabled
 Sequencing not set
 Preferred path Active : SR TE vpws1-policy, Statically configured, fallback enabled
 Tunnel : Up

 EVPN  Local Remote
 ------------ ------------------------------ -----------------------------
 Label 64007 64006
 MTU   9016  9016
 Control word disabled disabled
 AC ID 11001 11003
 EVPN type Ethernet Ethernet

So if we go n shut the primary dynamic path we can see the forwarding table moves over to our segment-list defined for label 16003 which is for NCS5508-3.

RP/0/RP0/CPU0:ncs5508-1#config t
Wed Jun 27 14:58:04.096 UTC
RP/0/RP0/CPU0:ncs5508-1(config)#int HundredGigE0/1/0/0
RP/0/RP0/CPU0:ncs5508-1(config-if)#shutdown
RP/0/RP0/CPU0:ncs5508-1(config-if)#commit

RP/0/RP0/CPU0:ncs5508-1#show mpls forwarding
Local Outgoing Prefix Outgoing Next Hop Bytes
Label Label or ID Interface Switched
------ ----------- ------------------ ------------ --------------- ------------
16002 16002 SR Pfx (idx 2) Fo0/2/0/18 50.50.50.38 0
16003 16003 SR Pfx (idx 3) Fo0/2/0/18 50.50.50.38 0

So thats all, i hope you like the blog and let me know your feedback.

Regards

Mohit

PCEP Initiated LSP using OpenDayLight and Juniper vMX

24 May 2018Automation, BGP, JNCIP, JNCIS, Juniper, Junos, MPLS, Networking, NFV, OSPF, RSVP, SDNAutomation, BGP, Controller, Juniper, Junos, LSP, MPLS, Networking, Northstar, opendaylight, OSPF, PCEP, RSVP, SDN, TCP/IP, vMXMohit

Hi All

In this post, we will look at Open day light controller working with Juniper vMXs and how we can use the controller to get the BGP, BGP-LS and PCEP working. Once everything is up and running we will use the Controller to initiate the PCEP initiated MPLS LSPs between 2 VMXs.

Sounds interesting? Let’s see how we can achieve this.

Before I go further, if you want to check anything on PCEP and some of its concept, I did a post on Juniper Northstar Controller some time ago which you can check.

https://networkzblogger.com/2017/03/17/juniper-northstar-wan-sdn-controller/

Below is the topology we will be using where all Juniper VMXs are loaded in Virtual Control Plane mode and they have fxp0 interface in 192.168.71.x subnet. Open day light controller version is Nitrogen and we have booted it on CentOS 7.5 version.

There is Windows VM in same subnet also from where we will run the REST APIs calls to Open day light using POSTMAN App.

We will divide the post into 3 parts.

Configuring BGP/BGP-Link state between ODL and 192.168.71.24 VMX-3.
Configuring PCEP session between all VMXs and ODL
Initiate MPLS LSP from ODL using PCEP

I am assuming that you already know how to start an ODL controller. However if you don’t know let me know and I can help you.

So lets start with 1) Configuring BGP/BGP-Link state between ODL and 192.168.71.24 VMX-3.

If you already don’t know, Open day light versions in recent times doesn’t come auto-installed with all the features. You have to manually add them. You don’t need to download them individually. It’s just you need to activate them.

We will be configure the BGP and BGP-LS on VMX-3 first

Standard BGP config with IPv4 Unicast address family however for BGP-LS we have to enable a separate family traffic-engineering additionally.

root@VMX-3> show configuration protocols bgp
group opendaylight {
 type internal;
 description Controller;
 local-address 192.168.71.24;
 family inet {
 unicast;
 }
 family traffic-engineering {
 unicast;
 }
 peer-as 2856;
 neighbor 192.168.71.22;
}

On ODL side, First install the BGP and restconf feature on karaf console using command

feature:install odl-restconf odl-bgpcep-bgp

Then using REST API we will enable the BGP Router-ID with Link State family

POST URL : 192.168.71.22:8181/restconf/config/openconfig-network-instance:network-instances/network-instance/global-bgp/openconfig-network-instance:protocols

Then Configure the peer 192.168.71.24 with specific BGP Parameters and families

POST URL: 192.168.71.22:8181/restconf/config/openconfig-network-instance:network-instances/network-instance/global-bgp/openconfig-network-instance:protocols/protocol/openconfig-policy-types:BGP/bgp-test-odl/bgp/neighbors

We can check the status of BGP peering off course from VMX side but let’s see what comes up from ODL side

GET URL: 192.168.71.22:8181/restconf/operational/bgp-rib:bgp-rib/rib/bgp-test-odl/peer/bgp:%2F%2F3.3.3.3

From VMX side:

root@VMX-3> show bgp neighbor
Peer: 192.168.71.22+27755 AS 2856 Local: 192.168.71.24+179 AS 2856
 Description: Controller
 Group: opendaylight Routing-Instance: master
 Forwarding routing-instance: master
 Type: Internal State: Established Flags: <Sync>
 Last State: OpenConfirm Last Event: RecvKeepAlive
 Last Error: None
 Options: <Preference LocalAddress LogUpDown AddressFamily PeerAS Refresh>
 Options: <VpnApplyExport DropPathAttributes>
 Address families configured: inet-unicast te-unicast
 Path-attributes dropped: 128
 Local Address: 192.168.71.24 Holdtime: 90 Preference: 170
 Number of flaps: 2
 Last flap event: RecvNotify
 Error: 'Cease' Sent: 0 Recv: 33
 Peer ID: 192.168.71.22 Local ID: 3.3.3.3 Active Holdtime: 90
 Keepalive Interval: 30 Group index: 0 Peer index: 0 SNMP index: 0
 I/O Session Thread: bgpio-0 State: Enabled
 BFD: disabled, down
 NLRI for restart configured on peer: inet-unicast te-unicast

BGP-LS configuration we did will be used to advertise the Traffic Engineering database to Controller. You can see the routes advertised using lsdist.0 table in juniper.

Snippet below:

root@VMX-3> show route table lsdist.0
lsdist.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
NODE { AS:2856 Area:0.0.0.0 IPv4:2.2.2.2 OSPF:0 }/1152
 *[OSPF/10] 02:02:38
 Fictitious
NODE { AS:2856 Area:0.0.0.0 IPv4:3.3.3.3 OSPF:0 }/1152
 *[OSPF/10] 02:02:43
 Fictitious
NODE { AS:2856 Area:0.0.0.0 IPv4:4.4.4.4 OSPF:0 }/1152
 *[OSPF/10] 02:02:38
 Fictitious
NODE { AS:2856 Area:0.0.0.0 IPv4:4.4.4.4-192.168.71.26 OSPF:0 }/1152
 *[OSPF/10] 02:02:31
 Fictitious
LINK { Local { AS:2856 Area:0.0.0.0 IPv4:2.2.2.2 }.{ IPv4:192.168.71.23 } Remote { AS:2856 Area:0.0.0.0 IPv4:4.4.4.4-192.168.71.26 }.{ } OSPF:0 }/1152
 *[OSPF/10] 02:02:31
 Fictitious
..
…
…

2) Now let’s configure the PCEP

On VMX (This will be repeated on all with change in local address)

root@VMX-3> show configuration protocols pcep
pce odl {
 local-address 192.168.71.24;
 destination-ipv4-address 192.168.71.22;
 destination-port 4189;
 pce-type active stateful;
 lsp-provisioning;
 p2mp-lsp-report-capability;
}

If you have any firewall, make sure to allow port 4189 between Controller and VMXs.

On ODL, we need to install odl-bgpcep-pcep feature

There is no other config to do. As soon as you install this feature, you should see PCEP status up.

Let’s see it from VMX-4

root@VMX-4> show path-computation-client status
Session Type            Provisioning Status
odl     Stateful Active On           Up

LSP Summary
 Total number of LSPs : 0
 Static LSPs : 0
 Externally controlled LSPs : 0
 Externally provisioned LSPs : 0/16000 (current/limit)
 Orphaned LSPs : 0

odl (main)
 Delegated : 0
 Externally provisioned : 0

From ODL side:

3) PCEP Initiated LSP

Now, we will configure the LSP from VMX-3 to VMX-4 between their Loopback IPs.

POST URL: 192.168.71.22:8181/restconf/operations/network-topology-pcep:add-lsp

You can see we haven’t given any ERO while provisioning the LSP. ODL has auto calculated the path and you can verify in VMX-3

root@VMX-3> show mpls lsp name test-pcep-2 extensive
Ingress LSP: 1 sessions

4.4.4.4
 From: 3.3.3.3, State: Up, ActiveRoute: 0, LSPname: test-pcep-2
 ActivePath: (primary)
 LSPtype: Externally provisioned, Penultimate hop popping
 LSP Control Status: Externally controlled
 LoadBalance: Random
 Encoding type: Packet, Switching type: Packet, GPID: IPv4
 LSP Self-ping Status : Enabled
 *Primary State: Up, Preference: 200
 Priorities: 0 0
 External Path CSPF Status: external
 SmartOptimizeTimer: 180
 Flap Count: 0
 MBB Count: 0
 Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
 192.168.71.26(Label=0)
 12 May 24 12:10:08.334 Self-ping ended successfully
 11 May 24 12:10:07.830 EXTCTRL LSP: Sent Path computation request and LSP status
 10 May 24 12:10:07.830 EXTCTRL_LSP: Computation request/lsp status contains: signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0) priority setup 0 hold 0
 9 May 24 12:10:07.829 Selected as active path
 8 May 24 12:10:07.828 EXTCTRL LSP: Sent Path computation request and LSP status
 7 May 24 12:10:07.828 EXTCTRL_LSP: Computation request/lsp status contains: signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0) priority setup 0 hold 0
 6 May 24 12:10:07.828 Up
 5 May 24 12:10:07.828 Self-ping started
 4 May 24 12:10:07.828 Self-ping enqueued
 3 May 24 12:10:07.828 Record Route: 192.168.71.26(Label=0)
 2 May 24 12:10:07.824 Originate Call
 1 May 24 12:10:07.824 EXTCTRL_LSP: Received setup parameters ::
 Created: Thu May 24 12:10:07 2018
Total 1 displayed, Up 1, Down 0

You can do various operations like Deleting LSP, Modifying LSP etc from REST API.

One thing which we can’t do at the moment using PCEP is configuring Point to Multipoint LSP as standard is still being drafted for this but I hope it will come out soon.

So that’s all for now, I hope you enjoyed it and let me know your feedback.

Regards

Mohit

OSPFv3 for IPv6 alone or IPv4 as well?

1 Apr 2017Cisco, IPv6, Juniper, Networking, OSPFCisco, IPv6, Juniper, Networking, OSPFMohit

We know that OSPFv2 is Link state routing protocol developed by IETF as a robust IP routing protocol suitable for large networks and to carry Ipv4 addresses. OSPF was first documented as a standard by John Moy in RFC 1131 and further Improvements were made in OSPF version 2. OSPF was then extensively modified by IETF to support IPv6 and called OSPFv3. But do you know OSPFv3 can be used to carry IPv4 addresses as well?

Before going into it, let’s review some differences between OSPFv2 and OSPFv3

OSPFv3 introduces new LSA types
OSPFv3 has different packet format
OSPFv3 adjacencies are formed over link-local IPv6 communications
OSPFv3 runs per-link rather than per-subnet
OSPFv3 supports multiple instances on a single link, Interfaces can have multiple IPv6 addresses
OSPFv3 uses multicast addresses FF02::5 (all OSPF routers), FF02::6 (all OSPF DRs)
OSPFv3 Neighbor Authentication done with IPsec (AH)
OSPFv2 Router ID (RID) must be manually configured, still a 32-bit number

Ok, now coming back to original question. If an organization wanted to use OSPF for both their IPv4 and IPv6 routing protocol, then they would likely use OSPFv2 for their IPv4 routing and OSPFv3 for their IPv6 routing. This would give the organization dual control planes for dual forwarding protocols. In this configuration, if there was a problem with either routing domain then it would not affect the other IP version. The same separation could also be achieved by running two completely different routing protocols. For instance, an organization could use OSPFv2 for IPv4 and IS-IS in single-protocol single-topology mode for IPv6. The IETF has continued to develop OSPFv3 so that it is now capable of working with multiple address families. In much the same way as Multi Protocol Border Gateway Protocol (MP-BGP) can function as an IPv4 and IPv6 routing protocol.

Once again, Cisco changed the IOS configuration commands required for OSPFv3 configuration. The new OSPFv3 configuration uses the “ospfv3” keyword instead of the earlier “ipv6 router ospf” routing process command and “ipv6 ospf” interface commands. OSPFv3 is still configured on the interfaces similarly to how the previous OSPFv3 commands were used. However, the biggest change is in the configuration of the routing process. This new syntax is more like multi-Address Family configuration of BGP and you have both an IPv4 and an IPv6 address family configuration section under “router ospfv3 “. New OSPFv3 syntax is used to configure a dual-protocol interface and for multi-address-family configuration under the OSPFv3 routing process is:

ipv6 unicast-routing
ipv6 cef
!
router ospfv3 <process-id>
router-id <router-id>
auto-cost reference-bandwidth 1000
address-family ipv6 unicast
area 0 range <range>
area 1 range <range>
address-family ipv4 unicast
area 0 range <Ipv4 range>
area 1 range <Ipv4 range>

So, OSPF is now evolved into a fully dual-protocol multi-AF routing protocol. Organizations now have multiple options for deploying OSPF. Organizations can stick with OSPFv2 for IPv4, and then use OSPFv3 for IPv6-only for a configuration that separates the control planes and the forwarding planes. Organizations can now combine the configuration of IPv4 and IPv6 into a single OSPFv3 process that can work equally well for both IP protocols.

Regards

Mohit Mittal

OSPF Special Area Types!!

8 Mar 2017Cisco, Juniper, NetworkingAreas, Cisco, Juniper, Networking, NSSA, OSPFMohit

The topic which I have chosen for today is special area types in OSPF. I have seen that people ((I was one of them ;)) find it hard to grasp these area types.

We know that OSPF is Link State Interior Gateway Protocol which works by advertising Link State Advertisements (LSA) to its neighbours. LSA are nothing but state of router Interface. More neighbors in Autonomous System means more LSA you need to share with your neighbours and more processing in terms of Power, Memory, CPU is needed on routers to process those incoming LSAs.

What is the solution?

To divide the whole autonomous system into different Areas with Area 0 or Back bone area being at the centre or you can say all other areas connects to Area 0.

What is the Benefit?

With division of whole autonomous system into different Areas, routers have to send the LSAs only to its neighbors inside that particular area and not with all OSPF routers of autonomous system.

Then how the information flows outside the Area?

This is with the help of OSPF Area Border Routers (ABRs) which summarizes the LSAs from One area and send it to another area in Type 3 LSA which is also called Summary LSA.

Till this point we have not introduced any special area types. Everything I have mentioned till now is mostly about Area 0 (Backbone Area) and any other area which is connected to Area 0. Let’s say that another area as Area 1 and common point among both of these areas is ABR which is at the border between these 2 areas.

Before learning Special area types you have to understand one type of LSA which is called “External LSAs or Type 5 LSAs”. These LSAs advertises external connectivity. External connectivity could be from some other Autonomous system or if redistribution is happening from any other IGP, Static protocol into OSPF.

Now, Special Areas are listed as:

1) Stub Area

2) Totally Stubby Area

3) Not-so-Stubby Area

4) Totally Not-so Stubby Area

:S… What is this all about? Ok, I will try to explain in simple terms 😀

As I discussed above that we have divided the Autonomous systems into Areas to restrict the flow of LSAs however there can be situations that you have some router in your network which is of very low memory or very old legacy router which can’t take all the routes in its routing table but instead of replacing it you want to keep it in your network and serve customers via it. You don’t want to bombard that router will extern LSAs to reach those external prefixes instead you can configure that router as Stub router.

With Stub router configuration all External LSA gets suppressed. But then how that router reaches External prefixes. That is via Default route. As soon as you configure Stub ABR router and other Internal routers as stub router, ABR will automatically advertises a default route towards Internal stub routers which is only information Internal stub routers needs in order to reach External prefixes.

Now in Stub routing, routers will still have Type 3 Summary LSAs, Type 1 Router LSA and default route in their database however why you even want Type 3 Summary LSA when you have default route. This is achieved via configuring the router as Totally Stubby Area where summary LSA even will be suppressed.

People think that apart from Stub area, all other area types are Cisco proprietary however if you look at the original OSPF RFC, Not so Stubby Area has been defined over there so it’s not exactly a Cisco Proprietary feature and has been implemented by other Vendors. Totally Stub Area and Totally Not-so Stubby Area are not defined in RFC.

There are many instances in which companies want to connect to another company or 2 companies gets merged and they want to share any information with each other but in limited fashion. This can be achieved by NSSA (Not-So-Stuby Area) in which router which connects to other’s company network becomes NSSA ASBR (Autonomous System Boundary Router) and router which is connected to Backbone Area 0 Router becomes NSSA ABR.

Redistribution into an NSSA area creates a special type of link-state advertisement (LSA) known as Type 7 LSA, which can only exist in an NSSA area. An NSSA autonomous system boundary router (ASBR) generates this LSA and an NSSA area border router (ABR) translates it into a type 5 LSA, which gets propagated into the OSPF domain i.e Area 0. However one thing to note is that External routes i.e. Type 5 LSAs coming via NSSA ABR is still not allowed into NSSA as normal Stub area rules still apply.

Like for Stub area we have Totally Stubby Area, for NSSA we have Totally NSSA which is same as before that NSSA doesn’t allow Type 5 LSA however it allow Type 3 Summary LSA’s , with Totally NSSA, we are suppressing this summary LSA even.. 🙂

Note: When you configure an area as NSSA, by default the NSSA ABR does not generate a default summary route. In the case of a stub area or an NSSA totally stub area, the NSSA ABR does generate a default summary route.

I know text has become lengthy but I didn’t want to stop abruptly to add to more confusion 🙂 . If you have any doubts, please let me know.

Mohit