Forwarding Equivalent Class

Forwarding Equivalent Class or FEC is a new term to me. It is a fancy term to describe the mapping between MPLS labels and IPv4 or IPv6 prefixes and is fundamental to understanding MPLS.

I first learned MPLS some years ago and this is the first time that I have come across this vocabulary. I guess i’ll start using it to sound super smart in my next bar conversation on MPLS…right

In any case, after enabling MPLS Label Distribution Protocol (LDP) and a LDP peer session is established to a neighbor, labels will begin to be associated to destination prefixes. Routers will use the MPLS LFIB instead of the IP routing table to “switch” traffic.

Label Distribution can be done in three ways

  • Label Distribution Protocol (LDP) – advertises labels for IGP learned routes
  • MP-BGP – Advertises labels for BGP learned routes
  • RSVP – Used for MPLS Traffic Engineering (MPLS TE)

It’s important to remember that LDP, MP-BGP, RSVP perform label distribution or in other words impose labels onto routes. They have advantages in their distribution of labels which is why there is more than one option but something to keep in mind when talking about Label Distribution.

So the term itself isn’t actually all that necessary to remember, which is in difference with in my opening comments but thought it was interesting vocabulary.

Mike

CCIE journey update

June 1, 2018 will mark two months into my CCIE studies. I thought I would share with you where I am and how I am feeling.

So after two months i’m feeling good. I’m somewhere around 50-55% through the written blue print and maybe a little less for the lab blue print.

I have banked 82 hours worth of theory and 78 hours worth of labs! This is only the beginning!

I currently sit nose deep in BGP. I have about 60 labs that I want to get through for this topic before I move on to VPN technologies.

So far so good. There are times of doubt however. Its almost inevitable, you look through the blueprint and its daunting. There is sooooo much information. I start to ask myself if this is something I can actually do? The answer is yes, it just takes time. I know this.

From the out side I feel like I’m making this look easy, my wife and others may object; yet inside, i’m tired, doubtful, excited, nervous. It’s overwhelming! My wife’s support along with co-workers, family and friends are helping me continue to push.  I am more confident than I have ever been talking about theory and technology with others. Its a great feeling.

I am still unsure when I will sit for the written portion. I am thinking some time in September.

I still have a ways to go but I am truly enjoying my studies so far!

Mike

 

 

EIGRP Floating Summarization

When you create summaries in EIGRP, the router automatically creates a route that points to a Null 0 interface.

This Null 0 interface serves as a bit bucket to prevent the router from forwarding traffic for destinations inside the summary address that it doesn’t have a longer match for. This is also known as Null routed.

This is true for OSPF and BGP summarization as well..

The administrative distance for summary routes have an AD of 5 by default. Knowing this we can configure a route with an AD of 1-4 to take precedence over our summary route.

Here is what I mean.

A simple EIGRP topology with R4, R5, and R8. Full EIGRP connectivity between nodes.

eigrp.summary0.PNG

Note: Lo1 has been created on R4 and R5 and advertised into the EIGRP process.

Lets configure a default route on R4 Ethernet segment towards R5.

eigrp.summary

On R5, let’s check for the route to R4 Lo1 – 160.1.4.4. R5s CEF table matches our summary route to reach 160.1.4.4

eigrp.summary1

Let’s check on R8. R8 just like R5 has a CEF entry for 160.1.4.4 that matches the summary route 0.0.0.0/0 that R4 generated. R8 and R5 don’t have a specific route for 160.1.4.4 because the summary route it suppressing the more specific route from being install into their routing tables, which is why we need to consult the CEF for the route.

eigrp.summary2.PNG

R8 can pint 160.1.4.4 as of now.

Let’s configure a summary address for the Lo1 prefix’s on R5 for R8 on the shared Ethernet segment between them.

eigrp.summary3.PNG

Below you can see that R8 received our new summary address for the Lo1 prefixes. We can see this in the out put 160.1.4.0/23. Lets try to ping 160.1.4.4 – R4s Lo1.

eigrp.summary4.PNG

eigrp.summary7

Pings to R4 – 160.1.4.4 fail. Pings to R5 – 160.1.5.5 are successful because R5 has this address locally configured.

Lets see what R5 has to say about the route to 160.1.4.4.

eigrp.summary5

We can see that R5 can reach 160.1.4.4 via Null 0. Lets ping 160.1.4.4.

eigrp.summary6.PNG

This can’t work! Our packets are Null routed!

So to get around this lets configure a static route on R5 to R4 for 160.1.4.4.

eigrp.summary8.PNG

R5 now knows about 160.1.4.4 with a AD of 1. Let’s see if this fixes R8s reachability.

eigrp.summary9.PNG

R8 can reach 160.1.4.4!

This could have also been solved by poisoning the Null 0 interface from R5s RIB with an AD of 255.

eigrp.summary10.PNG

The difference here is that the Null 0 interface found on R5 is completely removed from the routing table.

Credit: INE

Mike

EIGRP Wide Metrics

EIGRP Classic metrics couldn’t differentiate between anything faster than 10 Gigabit Ethernet interfaces.

Below is the EIGRP classic composite metric

EIGRP composite cost metric = 256*((K1*Scaled Bw) + (K2*Scaled Bw)/(256 – Load) + (K3*Scaled Delay)*(K5/(Reliability + K4)))

This can be simplified to 256*(Scaled Bw + Scaled Delay)

Here is a break down of what this means

EIGRP uses one or more vector metrics in the calculation of the composite cost metric (the formula above), here they are.

Bandwidth
Delay
Load
Reliability

Out of these vector metrics Bandwidth and Delay are the most commonly used to produce the composite cost metric.

Metric weights are monitored by K values. The K values are integers from 0 to 128. The integers and the vector metrics, most commonly (bandwidth and delay) are used to calculate the overall EIGRP composite cost metric.

K1 and K3 are the only default constants used in the composite formula. (There are 5 K values) – K1,K3 = 1 K2,K4,K5 = 0

Here’s an example

eigrp.metric1

We want to find the composite metric between R1 and R2s lo100 – 100.0.0.1/32

First we need to get the Scaled Bandwidth with the below formula. The bandwidth of the link is 1G.

Scaled Bw = 10^7 / Interface Bandwidth

We have to express the 1G interface in Kilobits. Formula would look like this.

Scaled Bw = 10^7 / 1000000
Scaled Bw = 10000000 / 1000000
Scaled Bw = 10

Second we need to find the Scaled Delay with the below formula. The Delay is 5010 microseconds.

Scaled Delay = (Delay/10)
Scaled Delay = (5010/10)
Scaled Delay = 501

Note: Delay is cumulative along the path to the destination prefix.

Now we can fill in our simplified composite formula

256*(10 + 501) = 130861

Composite metric is 130861

eigrp.metric1

 

EIGRP wide metrics were introduced to assist in scaling for high bandwidth interfaces. EIGRP wide metrics offer the following:

  • 64 – bit metric calculation (compared to the 32 – bit metric of Classic EIGRP)
  • 128 – bit metric for the RIB
  • 65536 – Base Metric (compared to 256)
  • Bandwidth express in picoseconds (compared to tens of microseconds)
  • K6 ( reserved for future use and are known as “Extended Metrics”)
    • Jitter
    • Energy
    • Quiescent

Here is the wide metric formula

Metric = [(K1*Minimum Throughput + {K2*Minimum Throughput} / 256-Load) + (K3*Total Latency) + (K6*Extended Attributes)]* [K5/(K4 + Reliability)]

Bandwidth is now Throughput
Delay is now Latency.

Because we now have a larger base metric (65536) we can now account for higher speed links and because we use picoseconds this fixes delay issues.

Here are the simplified formulas for computing the composite cost metric. The vector metrics we care about are Throughput and Latency.

Composite Cost Metric = (K1*Minimum Throughput) + (K3*Total Latency)

To find Minimum Throughput use

Minimum Throughput = (107* 65536)/Bw)

For Total Latency interfaces under 1 Gigabit use

Total Latency for bandwidths below 1 gigabit  = (Delay*65536)/10

For Total Latency interfaces above 1 Gigabit use

Total Latency for bandwidths above 1 gigabit = (107* 65536/10)/ Bw

Lastly once you have your Composite cost metric divide it by the RIB metric of 128. This is so that the 64-bit metric calculation can fit into the RIB.

1392640 / 128 = 10880 – This is what will be installed into the RIB

eigrp.metric2

Some take aways

Although you can configure K values to produce varying routing behaviors, most configurations use only the delay/latency and bandwidth/throughput metrics by default so its best to keep K values to their defaults. Changing these could have a larger affect on more than just the EIGRP metric, for exmaple QoS will use these K values and if changed could have undesirable results.

It’s best to change the delay of the link to influence path selection, rather than changing the bandwidth. Changing the bandwidth could have a larger affect on more than just the EIGRP metrics.

K values still need to match between routers to form adjacency.

Mike

RIPv2 Route Filtering Methods

Today we ill be providing route filtering examples for RIPv2 with the below methods.

  • Passive Interfaces
  • Distribute-Lists
  • Offset-Lists
  • Administrative Distance

Passive Interface

Configure a passive interface so that R8 receives routes from R10 but does not advertise routes to R10.

rip.passive.PNG

Configure a passive interface with the passive-interface interface command.

When configuring a passive interface RIPv2 updates are no longer sent out of that interface but RIPv2 updates are still received. We can see this to be true by viewing the rip database for R8 and R10.

rip.passive1

R10 last received and update from R8 two minutes and 35 seconds ago 02:35. Based on this value we know that the routes are on their way to be withdrawn from R10s RIP database and RIB when it meets the default RIP flush timer of 240.

Distribute-Lists 

Distribute-List with prefix-list

On R5, prevent R8 from receiving R6 and R7 Loopback addresses while permitting everything else.

On R5, Prevent R4 from sending IPv4 updates in through Tun 0 while permitting everything else

Here we configured prefix-list R5_STOP_R6R7R8 to prevent R6 Loopback 150.1.6.6 and R7 Lookback 150.1.7.7 and permit everything else. Then applied to the interface leading to R8.

rip.prefix1.PNG

The second prefix-list R5_STOP_R4 will prevent R4 from sending IPv4 updates in through Tun 0 while permitting everything else. We need a “permit any” in our prefix just as you saw int the last one, 0.0.0.0/0 le 32 will accomplish this.

The PERMIT_ALL prefix-list is needed because we are applying this to all interfaces.

This line distribute-list prefix PERMIT_ALL gateway R5_STOP_R4 in is saying permit all routes on all interfaces as long as it didn’t come from R4 155.1.0.4.

Distribute-List with standard access-list

Here is how we can filter the IPv4 prefixes with an even number in the third octet with a one line standard access-list.

rip.access3

Distribute-List with extended access-list

When an extended access-list is used as a distributed-list in IGP application, it is important to remember that the behavior of the access-list changes. Instead of the source representing the network address and the destination representing subnetmask.

The source field in the ACL matches the update source of the route (who is sending us the route), and the destination field represents the network address.

access-list 100 deny ip host 155.1.0.3 host 155.1.7.0
access-list 100 deny ip host 155.1.0.3 host 155.1.9.0
access-list 100 deny ip host 155.1.0.1 host 155.1.146.0
access-list 100 deny ip host 155.1.0.1 host 150.1.1.1
access-list 100 permit ip any any

Offset-list

An offset-list was configured to prevent R9 from installing 150.1.5.5. Hop count was set to 16 to poison R9 and have it remove it from it routing table and to prevent R9 from installing it in the future.

rip.offset

You can see that R9 won’t install the route because of 150.1.5.5 having a hop count of infinite (16). The off-set list  worked.

rip.offset2

Administrative Distance

I want to configure an administrative distance so that hosts in the network cannot reach R4s Loopback.

The first is to create an access-list for R4s Lookback address. Then to apply it under the routing process.

rip.ad

These scenarios were curated by INE. Thank you to them.

Mike

RIPv2 Authentication

RIP is an old distance vector routing protocol. I wanted to give a quick over view of a potential problem when using authentication with RIP.

Below is the topology that we will be using.

rip.auth1

RIPv2 has been enable on R1,R2, and R3. We have full reachability between our nodes. I have enabled plain text authentication on each link. Here is R2s output.

rip.auth2

Key Chain = PASSWORD_TEXT
Key Number = 1
Key String = CCIE

I am going to setup a packet capture so we can view our RIP packets.

rip.auth3

Notice that R2 10.0.12.2 is sending updates to the Multicast address for RIP 224.0.0.9. Authentication type: Simple password. Our password is CCIE. One thing in particular is that the Key identifier or our key number in our case 1 is arbitrary.

RIP plain text authentication doesn’t transmit the key identifier so you could have different key numbers on each of our routers. Say R1 = Key 1, R2 = Key 2, R3 = Key 3 and authentication would succeed as long as the password matches.

Lets switch our plain text authentication to use MD5 authentication between R1 and R2.

rip.auth4

I created a new key chain and used MD5 authentication between R1 and R2. The link between R2 and R3 are still using plain text authentication.

Key Chain = PASSWORD_MD5
Key Number = 2
Key String = CCIE

I’ll setup a new packet capture between R1 and R2.

rip.auth5

We have the same information as our last capture with two slight differences. We are using Authentication type: MD5 and now have a Key identifier field Key ID: 2

I’m going to change the Key ID on R1 to 1. Let’s see what happens when we have two different Key IDs.

rip.auth6

R1 is now using Key ID of 1. And below you see R1 ignoring RIP updates from R2 because authentication failed.

rip.auth7

The point here is that when using RIP authentication with MD5 the Key identifier needs to match between routers. You see this in the packet capture, the Key identifier field is transmitted in the RIP payload. If Key ID differs, authentication will fail.

Mike