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: http://www.ciscopress.com/articles/article.asp?p=24090&seqNum=4

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 224.0.0.6. 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 224.0.0.5 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.

Purpose:

  • 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 224.0.0.10. 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: 10.1.1.1/32

On R2, we will have loopback 1: 10.1.2.2/32

On R3, we will have loopback 1: 10.1.3.3/32

Below is the routing table of R1:

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

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 (130.1.0.0/16 and 172.16.0.0/16) 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 172.16.0.0/16

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

Explanation:

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 130.1.1.0/24. 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 192.168.12.10 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

References:

mmoizuddin(Feb 18, 2010),Cisco Router As A Vpn Server, Available: http://www.slideshare.net/mmoizuddin/cisco-router-as-a-vpn-server

NetworkersOnline (July 12th, 2008) What is a virtual template/access interface? Available: http://www.networkers-online.com/blog/2008/07/what-is-a-virtual-templateaccess-interface/

Cisco (Sep 09, 2005) Virtual Access PPP Features in Cisco IOS, Available: http://www.cisco.com/c/en/us/support/docs/wan/point-to-point-protocol-ppp/14943-4.html

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
map-name]

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 0.0.0.0/0

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

References:

Cisco: http://www.cisco.com/c/en/us/td/docs/ios/12_2/iproute/command/reference/fiprrp_r/1rfrip.html#wp1017420

Distance vector protocols: Filtering mechanisms

We have many options when it comes to filtering in EIGRP:

  • Distribute-list in conjunction with standard access-list
  • Distribute-list in conjunction with Extended access-list
  • Distribute-list in conjunction with prefix-list
  • Distribute-list using the gateway option
  • Offset-list-list in conjunction with standard access list
  • Distance command

To practice all this filter, I am going to use the following network diagram.

Overview of standard access-list

The way standard access-list operates in routes filtering is completely different with traffic filtering.

However the syntax is the same:

The syntax for the standard IP access list is shown here:

access-list
x {deny | permit} a.b.c.d wildcard mask {log}

Where a.b.c.d argument is the IP address where x is the access-list numbers which falls in the range 1 – 99 and 1300 -1999.

Let’s examine the routing table of R1 for EIGRP learned route

Task 1: using standard access-list, allow only 20.20.2.0/29 network from interface GigabitEthernet0/1.12

Solution:

Access-list 10 permit 20.20.2.0 0.0.0.0 (not 0.0.0.255 as wildcard mask)

Distribute-list 10 in GigabitEthernet0/1.12

Here is the result in the routing table:

If we had written our access-list like this Access-list 10 permit 20.20.2.0 0.0.0.255, we would have failed the task, because the wildcard mask 0.0.0.255 means match all network as long as the first three octets match exactly.

For example, network 20.20.2.128, 20.20.2.192, 20.20.2.224, 20.20.2.240…in a nutshell all 20.20.2.x network will fall in the access-list.

Standard access-list for network filtering does not take into account the subnet mask meaning that, for our access-list access-list 10 permit 20.20.2.0 0.0.0.0, all subnet mask would fit and the network going with would be permitted.

Task 2: Using extended access list, on R2 deny all route learned from R3

Below is the routing table of R2:

As we see, we have a bunch of routes learned from R3 (192.168.234.3) and from R4 (192.168.234.4) as well. We are going to filter all routes learned from R3, and allow only routes learned from R4 through R2 interface Fastethernet0/1.234.

Our extended access-list should look like this:

access-list 100 deny ip host 192.168.234.3 any

access-list 100 permit ip any any

When using extended access-list within the distribute-list command, the source field in our extended access-list represents the ip address of the router send the network we want to filter in (or out) whereas the destination field is the exact network we are preventing from getting into our network.

As we see, we now have only routes learned from R4 (192.168.234.4).

Task 3: On R2, Using extended access-list filter all network coming from R3 and R4 and having odd number in their second octet.

Solution:

Extended access-list:

  • Source field: 192.168.234.0 wildcard mask: 0.0.0.7
  • Destination field: 0.1.0.0 wildcard mask: 255.254.255.255

Access-list 100 deny ip 192.168.234.0 0.0.0.7 0.1.0.0 255.254.255.255

Task 4: on R2, Using Prefix list permit only routes having 195 in their first octet and having also /27 as a mask

Solution: Ip prefix-list PL1 seq 10 permit 195.0.0.0/8 ge 27 le 27

Task 5: On R2, using prefix-list allow only network coming from R3 and having /26, /27 and /28 as subnet mask:

Solution:

Network: ip prefix-list PL2 seq 10 permit 0.0.0.0/0 ge 26 le 28

Advertising source: ip prefix-list PL3 seq 10 permit 192.168.234.3/32

Task 6: On R2, using offset-list filter all 195.X.X.X:

Solution: we all know that 195.X.X.X routes learned Aare coming from R5 and will have hop count of 2 in the routing table of R2, meaning that, if increase the hop count by 14, none of the routes from R5 will be installed in the routing table.

Below is the output of the debug ip rip command issue on R2, and we can notice that all 195.X.X.X routes have a hop count of 16 therefore are allowed by RIP process on R2, they are marked inaccessible.

Task 7: On R2, using distance command, allow only route having only numbers 1 to 4 in their second octet


.

That are all for filtering, I hope these have been informative.

Blaise Annesti NGADJUI

Rip protocol: prefix-list using the “gateway” option

I was working to solve one task from the INE workbook that I found pretty difficult because I did not know the option gateway while writing down a prefix list.

Here was the question: Using prefix list, filter all routes from a particular neighbor.

Again let’s consider the topology below

I am going to add couple of loopback to R2:

Lo1: 192.168.1.2

Lo2: 192.168.2.2

Lo3: 192.168.3.2

These loopback should be advertised to R1 via RIP.

Here is our R2 routing table:

Task1: using access list, on R1 filter 150.1.4.4 route coming from R2

access-list 10 deny host 150.1.4.4

access-list 10 permit any

distribute-list 10 in GigabitEthernet0/1.12

Here is our configuration on router R1:

The case above is simple because R1 and R2 are only both routers sharing the link.

Let’s examine the second task:

Task 2: on R4, using the prefix list, filter the route 150.1.1.1 coming from R2. (150.1.1.1 Should be advertised only by R3):

Let’s confirm first that R4 is learning 150.1.1.1 from R2 and R3:

Let’s create our prefix list:

ip prefix-list deny_R2 seq 10 deny 150.1.1.1/32

ip prefix-list deny_R2 seq 20 permit 0.0.0.0/0 le 32

If we apply this prefix list on R4, it is going to filter all 150.1.1.1 routes, even those coming from R3. Let’s verify:

As we see, we just failed the task, we do not longer have route 150.1.1.1 in our routing table.

Let’s fix the problem using the gateway option to specify the neighbor from which we want to filter the route.

First let’s create a prefix list to match only R2 interface ip address:

Ip prefix-list No_R2_Neighbor seq 10 deny 150.1.234.2/32

Ip prefix-list No_R2_Neighbor seq 20 permit 0.0.0.0/0 le 32 (permit all other neighbors)

Second, let’s consider our first prefix-list:

ip prefix-list deny_R1L0_from_R2 seq 10 deny 150.1.1.1/32

ip prefix-list deny_R1L0_from_R2 seq 20 permit 0.0.0.0/0 le 32

Routing table of R4:

From the output above, instead of filtering only 150.1.1.1 from R2, we did filter all routes from R2. If We were asked to filter all routes from R2 using prefix list, we would not have written our second prefix with two sequences, we would simply have:

ip prefix-list deny_R1L0_from_R2 seq 10 permit 0.0.0.0/0 le 32 and the result would be the same.

Let’s rewrite the prefix list to filter all route coming from R2, (don’t forget, this is not the task we have been asked to do)

This is our initial routing table from R4:

Let’s apply our distribute-list with our prefix-list rewritten

And here is the output of our R4 routing table:

It looks much better, we have now route 150.1.1.1 in our routing table coming from R3, we did filter 150.1.1.1 coming from R2 but, not only that we have filtered all route coming from R2.

The task was asking to filter only 150.1.1.1 coming from R2.

I don’t know if it is possible using the prefix list on R4 to filter only that specific route while allowing other routes from R2. We can filter that prefix on R2 from being advertised to R4.

Let’s do it on R2:

First let’s bring back our initial routing table on R4

Now we are going to solve the task on R2 router as if it was asked to do that way.

Above, using prefix list, we have filtered 150.1.1.1 from being advertised out R2 interface F0/1.234.

Check the output of R4 routing table.

That’s all our experience with Prefix list using gateway option.

Thank you for reading.

Blaise Annesti NGADJUI