Proposed Network for Capstone Project 2016

  • DMVPN cloud between the branch office and the main office
  • Cisco ASA is used for the firewall and they provide high availability and failover (main Office)
  • Two distributions switches providing routing between vlans and high availability for end users
  • Cisco ASA provide secure remote access using SSL to mobile (remote users)
  • DMZ network for service like WWW, FTP, Non-ADS DN, Exchange edge server
  • Server LAN for ADS DC, DNS, File servers, Exchange mail server, Certificate Authority Server

SAIT – Capstone Project 2016

  1. Project Requirements


Upgrade network services for a natural resource company (Black Gold Resources Ltd.) with operations across Alberta ( 500 at Calgary head office, 2 regional offices {Medicine Hat, High Level}with 10 – 15 staff at each regional office. Availability, performance, and security are the important project drivers. Cost is a secondary consideration but all costs must be justified. The existing network needs to be upgraded with little or no disruption to daily operations. Current users, groups, data, and access must be preserved.


Vendors will upgrade the existing services which include :

  • Windows Server 2008 AD Domain to Windows 2012 R2
  • Website running SugarCRM 7.6 ( A customer relationship management platform ) on CentOS Linux to IIS on Windows 2012 R2
  • Upgrades of the Head office network:
    • Core, distribution and access layers
      • asset refresh of access layer switches for 1 Gbps connectivity for end stations
    • Internet edge with proper DMZ technologies and redundancy considerations for branch office connectivity
    • Data center with high throughput capacity
    • Implement standard redundancy technologies to ensure highest availability
    • Proper security and access controls for departments and resources
  • Upgrade of Branch office network
    • asset refresh of branch switches for 1 Gbps connectivity for end stations
    • asset refresh of edge router for connectivity back to head office
    • deploy new wireless technology to each branch

Vendors will provide the installation, configuration, and testing for the following new services :

  • Email server (Exchange 2013)
  • Remote access to email (ie: OWA)
  • Microsoft Lync
  • Secure Cisco edge device for head office and branch offices
  • All network devices will be virtual for the project
  • All servers will be virtual, including the existing Windows 2008 R2 servers.
  • The virtualization platform will be VMWare ESXi, Microsoft Hyper-V, or OpenStack Juno. Combinations of the above may be used as well. You will be told more about the virtualization platform in January.
  • Secure wide-area links between head office and branch offices (Microsoft Lync will be used as the main voice communication system within the company. Recommendations for bandwidth requirements should be included)
  • Windows Domain design, upgrade, and installation
  • Server installation, configuration, and testing
  • Workstation software recommendations and cost estimates (Operating system and Office software only)
  • Remote access to network resources (VPN : IPSec or SSL/TLS)
  • Internal (AD) and external (Non-AD) DNS services (Do not underestimate the time required to implement this properly. It is trickier than it appears)
  • Development and implementation of appropriate Domain security and health policies
  • Redundant configurations (as required)
  • Automated deployment of workstations (as needed)
  • Recommendations for printer models along with approximate costs
  • Software licenses and CAL’s (as needed)

OSPF: The Flooding Mechanism – concept of identical databases within the area

There is a misunderstanding when it comes to ospf flooding mechanism. This concept is not only applicable to ospf, it is used by all link state protocol like IS-IS. To better understand ospf, we should first get a good understanding of the flooding mechanism and the flooding scope of different type of ospf LSA.

Flooding means take from one interface and send out to others interfaces. Sounds strange because we all know that this is somehow the behavior of the broadcasting when we talk about the layer two network.

In ospf, we do have the same type of behavior when it comes to lsa flooding. We must pay carefully attention that without the flooding mechanism in the ospf process, we would not have databases synchronized in the entire area, especially when our area is running multiple types of ospf network.

This link helps on understanding the process:

Information exchange between ospf neighbors are contain within ospf packet, (Hello. DBD, LSR, LSU, LSAk).

In a shared segment (with ospf network type broadcast), if a router has a link failure, it will notice this state to the DR using the multicast address This information is communicate via a LSU which contains the “Type one LSA” describing each link of the router. The DR, upon received the LSU, is going to unpack it, process it and send a new LSU which now contain the same “LSA type 1″ previously learned and a new ” lsa Type 2 describing the relationship between ospf routers on the segment. This new Type 2 Lsu is sent on the segment using the multicast address Because this address is a link local address, every packet sent to this address ends up into the receiving router and cannot go further, but thank to flooding mechanism and thank to the fact that databases in the area must be the same, information contained inside the LSA can be flooded if the receiving router is sitting between two segments in the same area. If this is the case, the router will process the lsu by sending it out others interfaces. Having said that, the origination LSA from one segment just crossed the router: that is the flooding.

It is very important to understand that, especially when it comes to designing, where some questions need to be addressed first:

How many area do we need?

How important is the numbers of the adjacencies within the area?

Do we need to create multiple segments and keep a small size of packets or it is better to have only one DR in a single area which might cause some problems relate to ospf MTU.

I hope this helps.

Blaise Annesti NGADJUI

EIGRP unicast and multicast updates are mutually exclusive

EIGRP send its routing updates in multicast or unicast depending on how it was configured. Unlike RIP which can support both unicast and multicast at the same time through its interface, EIGRP does not. Unicast update configuration automatically disable the multicast feature on the interface.


  • One of the reasons to run unicast update might be the requirement of the layer two topology like NMBA (non broadcast multi access) therefore we need to specify the neighbor requirement.
  • Other reason is for security, since we know that multicast packet can be intercepted in the broadcast environment if authentication has not been set between neighbors

Recall that eigrp multicast address is Using the network below, we are going to take a look to eigrp multicast routing updates and how configuring the unicast update automatically disables the multicast update from being sent, more than that the IOS will completely ignore all received multicast updates coming into the interface. We are going to take a look to the output of “debug eigrp packet” and observe how packets are ignored.

Below are the basic configurations of DMVPN on routers R1, R2 and R3:

Let’s enable EIGRP on all routers through interface tunnel 0, below is the sample configuration applied on all routers:

We also need to disable split horizon on R1 tunnel interface In order to allow communication between spokes.

Let’s create some loopbacks interface on each routers and advertise them into EIGRP.

On R1, we will have loopback 1:

On R2, we will have loopback 1:

On R3, we will have loopback 1:

Below is the routing table of R1:

At this stage, routing update between neighbors are done using multicast address

Now if we enable unicast on tunnel 0 of Router R1, IOS is going tear down the adjacencies between neighbor because, R1 would not process any multicast update or multicast hello packet.

Let’s do that.

Now let’s enable unicast on R2 as well

Because we have enable EIGRP unicast update on R1 and R2 only, there will adjacency forming only on both routers.

EIGRP is accepting packets from R2 but not from R3 because R3 still multicasting.

To have a fully adjacency, we need make a choice between forming adjacencies via unicast or multicast.

In case of unicast updates, we need to enable neighbor’s relationships with all routers within the network.

These are all. I hope it was informative.

Thank for reading

Blaise Annesti NGADJUI

Understanding auto summarization with EIGRP

Auto summarization is a feature which allows Enhanced Interior Gateway Routing Protocol (EIGRP) to summarize its routes to their classful networks automatically.

EIGRP performs an auto-summarization whenever it crosses a border between two different major networks but there is a caveat here, when summarizing, VLSM is applied only for subnets that are within the same major network boundary: we are going to proof that using the network below.

The network above is consisted of fours routers running EIGRP over DMVPN cloud. I am not going spend time showing how to build the DMVPN cloud. This is another topic coming soon, however below are the DMVN configuration of for the HUB and Spoke_1 (for others spoke, the same configuration should be applied with ip addresses changed accordingly).

Let enable EIGRP on all routers (the configuration applied to the HUB is the same for spoke routers as well)

By default split horizon is enable on all interfaces running EIGRP to prevent looping. This is the case for the tunnel interface of the HUB

Let’s disable split horizon of the HUB tunnel interface otherwise we won’t have spoke to spoke communication.

Routing table of HUB and all others spokes.

We have disabled auto summarization yet, all router are learning all loopback interface and can successfully all of them.

We have fully connectivity within our network. Every router can ping every router’s addresses.

Let’s enable auto summarization and see the result.

Let’s check HUB routing table:

Two summary addresses to the classful boundaries have been created ( and and also we now have a route to null0 for each summary addresses.

The good news is we can still ping all addresses within the network

The bad news is none of the loopback addresses is reachable from others routers. In order words, addresses of the classful network are not reachable from other routers.


During the summarization process, IOS does support VLSM on the networks used to connect routers which mean while summarization of these networks is performing, IOS advertises and accepts routing update for subnetworks connecting routers. This is not the case for others subnetworks that are not in the networks boundary between routers like Routing updates for this network won’t be sent.

I hope you have enjoyed.

Blaise Annesti NGADJUI

PPP encapsulation and RIPv2 source update validation

Core issue:

In the network design perspective, there might be a situation where we have different locations as clients  and a central location. Due to some requirements, clients location need to get connected to the central unit using dial up connection which means there is a need to run PPP or PPPoE encapsulation between the central office and those locations for the sake of security , authentication and so on. The design itself looks like an HUB and Spoke topology, where spokes have to authenticate to HUB. Sure there is a more advance technology like VPN or DMVPN to address this kind of issue but we are not running these advanced technologies, we want to build our core network using rip between HUB and spokes routers. In this post, we going to setup a basic PPPoE (without authentication) and test our RIP feature named source update validation.

There are some prerequisites like Virtual access interface and virtual-template interface that we need to understand before starting building our network and setting up our routers.

According to cisco:

A virtual-template interface is a logical entity that can be used to apply predefined interface configurations for virtual-access interfaces.

Virtual template interfaces is configured independently of any physical interface and applied dynamically, as needed, to create virtual access interfaces.

Virtual access interface is a virtual interface that is created, configured dynamically, used, and then freed when no longer needed.The virtual Access interface is not configured manually it gains its configuration via the Virtual Template interface and/or RADIUS and TACAC+ authentication servers.

A Virtual Access interface is a Cisco IOS interface, just like physical interfaces such as a Serial Interface. A serial interface configuration resides in the serial interface configuration.

Now let’s dive into our task with only two routers (HUB and one Spoke).

First, let’s test our basic connectivity between the HUB and the spoke routers.

Interfaces ip address were manually configure just to test our basic connectivity. We are now going to get rid of these ip address.

Going to the HUB, under the configuration mode, let’s define our bba group and bind it to a virtual template.

Now let’s create our virtual template and assign to it its proper address as required by the task, also we need to bind to this virtual template a pool need to assign ip address to the client when required.

Let’s create our pool Client-Pool

The last step is to bind our Physical interface to our bba-group.

As me might notice, one virtual access interface has been created from the Virtual-template interface which is down now waiting for the client to initiate the connection.

Let’s move the Spoke router and setup our dialer interface.

Now it is time to bind the dialer interface with the physical interface.

Once the dialer has been linked to the physical interface, our virtual interface automatically comes up, and we can notice that the ip address has been negotiated through our PPPoE connection and we can now ping the HUB

Now that we have our PPPoE link up and running, we can enable RIP on both router and run out all interfaces including loopbacks already created.

Let’s enable RIP on all interfaces.

Here is where the feature RIPv2 source update validation comes into play.

Routing table of HUB and Spoke.

By looking carefully both routing table, we can notice that one side has received RIP update but this is not the case for the other side. The problem is, PPP does advertise peer neighbor route with a /32 mask regardless of what has been configure as a mask address. RIP unlike other protocol like OSPF and EIGRP (who ignore advertised mask on point-to-point link), does check the mask addresses, and if this do not match on both ends, routing updates are completely ignored. The debug ip rip events output
confirm this:

To fix this problem, we need to tell the IOS under the rip process to not check the mask address from a peer neighbor, using the command no-validate-update source on both routers.

That are all, I hope these have been informative.

Blaise Annesti NGADJUI


mmoizuddin(Feb 18, 2010),Cisco Router As A Vpn Server, Available:

NetworkersOnline (July 12th, 2008) What is a virtual template/access interface? Available:

Cisco (Sep 09, 2005) Virtual Access PPP Features in Cisco IOS, Available:

Conditional default origination with RIP

Within the cisco infrastructure, there is a special command to generate a default route in the entire RIP domain, not only with RIP protocol this feature exist, it does exist also with other routing protocol like ospf, but the behavior is different.

With RIP protocol, using the default information originate under the routing process will generate automatically a default route even if the route is not present in the routing table. Unlike ospf where the route has to exist in the routing before being propagated using the default information originate, RIP does not take into account that condition, it automatically generate the default if this exist or not in its routing table.

Below is the syntax of the command.

Default-information originate

To generate a default route into Routing Information Protocol (RIP), use the default-information originate command in router configuration mode. To disable this feature, use the no form of this command.

default-information originate [route-map

no default-information originate

Syntax Description

route-map map-name

(Optional) Routing process will generate the default route if the route map is satisfied.

Let’s build a simple scenario to test this feature

First step: Checking our basic connectivity between routers.

R2 routing table:

R2 is running RIP version 2 with R1, also R2 has two links to the internet, one through R3 and another one through R4.

R1 routing table:

NB: we don’t have access to R3 and R4 routing table, those routers belong to the service provider.

Task1: On R2 using ip sla, enable a conditional static default route pointing to R3 and R4, this route should only be present in the routing of R2 if R3 interface or R4 interface is reachable.

Default static routes created:

Routing table of R2 having static routes:

At this point R1 does not have a default route.

Task2: configure R2 so that it generate a default route which should be propagated with the rip domain.

On R1, we now have the default route learned via rip:

At this stage, the default route is injected within the domain without being relied on a particular condition, which means if we disable static routing on R2, we will still have default route installed on the R1 routing table.

Let’s do that:

However, R1 still have the default route in its routing table and subsequently, traffic sending to R2 using the default route will be black hole on R2. This is something that we can prevent using the Conditional default Origination.

R1 routing table

Task 3: Using the conditional default origination, ensure that default route is propagated within the domain only if upstream routers interfaces (R3 and R4) are reachable.

We have already created our ip sla and tracker, let’s re-enable our default routes on R2 and create a route-map to satisfy our condition when enable default-information originate under the RIP configuration mode. The route-map we are going to create will be applied with a standard access list matching the default route.

Now the existence of the default route within the RIP domain rely on the presence of default static route on R2’s routing table.

If unfortunately those two static routes were to disappear in the routing table of R2, this one would cease to announce default route to R1 or to the entire domain.

Let’s examine by disabling one by one R3 and R4 interface.

R2 routing table:

R2 has two paths to the default route

Let’s disable R3 interface and observe the routing table of R2

The first line indicates that R3 interface went down and consequently R2 has now only one path through the internet. However R1 still have the default route through R2.

Now let’s disable the last interface connecting R2 to the internet and observe the result on R2 and R1 routing tables.

R1 has lost the default route entry in its routing table due to the fact that R2 has stopped announce this route because of the conditional default origination that has taken effect. When at least one of the upstream links will be back, R2 would start announce the default route.

That are all for the Conditional default Origination.

I hope these have been informative.

Blaise Annesti NGADJUI