Category: CCIE

RIPv2 Route Filtering Methods

On By MikeIn CCIELeave a comment

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

On By MikeIn CCIELeave a comment

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

 

CCIE, is it time?

On By MikeIn CCIELeave a comment

I have always had a dream to one day become CCIE certified and it has always been just that, a dream. It has always been unclear on how I would do this. There is no road map to becoming a CCIE. So when I sit and dream about becoming a CCIE it makes me a bit anxious. My blood pressure starts to rise, my palms get sweaty, my stomach starts to hurt. I can’t help but be anxious.

I started to groom my conscious thoughts about becoming a CCIE for a few months  hoping to set ease by Googling things like, “How to become a CCIE?”, or “What does it take to be a CCIE?” (this really didn’t help). The overwhelming response was, be ready to sacrifice a lot and that it is expensive..great thanks for stating the obvious.

Unfortunately I wouldn’t have a “sponsor” for this journey, which is fine but having an employer assist me in my efforts would be great (This changed July 26th 2018, when I was hired by Cisco). I also didn’t have peers that were of the CCIE status. It wasn’t like I was sitting in a room of other CCIEs that I could ask questions to. So it was hard for me to understand things like, how to start?, where to start?, what are the best resources?

I started to curate a list of resources that I would use for my studies, I even created a work/study schedule that I could use as sort of a soft opening to my studies. I started reading Routing TCP/IP Volume I and II by Jeff Doyle for my soft opening studies as I called it. I would tweak the schedule based on how I felt and after a few months had a good plan in place that compliments work, family, and pleasures.

What did turn out to be useful from my Google searches was that many CCIE achievers started with ensuring that their spouse, family, friends, and others understood the sacrifices and what it would take to achieve their CCIE. Many of them stated that this was key to their success. So for that reason and after a few months I sat to discuss my CCIE aspiration with my wife. My wife already knew about this CCIE dream, so it wasn’t a surprise to her when I brought this up. I was fully transparent about my studies, the cost and the marathon I was about to start. She was fully supporting, and couldn’t have asked for a better support system than her. I then included my friends, family and my employer in my efforts.

As of today April 2, 2018 I will be starting my CCIE journey. I plan to fall in love with the process of becoming great. This journey will be about becoming an expert in my field and as a byproduct achieve my CCIE. I hope to share as much as I can with all of you during this time. I appreciate any and all support.

Mike

 

 

BGP Peer Templates

On By MikeIn BGP, CCIELeave a comment

Today we’re diving into BGP peer templates.

Peer templates are an evolution to BGP peer groups and serves to address some of the limitations that BGP peers groups carried.

BGP peer groups were used to reducing the number of configurations on a router with many BGP neighbors. In addition to reducing the routers configuration it also offered performance gains by adding the members of a BGP peer group to an update-group. BGP updates are then performed on the group rather than the individual neighbors.

The limitations to BGP peer groups:

  • All neighbors in a group had to share the same outbound routing policies.
  • All neighbors in a group had to be of the same address family.

The answer to the first limitation came from a feature call ‘BGP Dynamic Update Peer-Groups’

Dynamic update Peer-Groups dynamically assigns neighbors to a BGP update-group that is subject to the same outbound routing policies. This meant that you didn’t need to configure a Peer-Group for performance gains.

To address the second limitation, peer templates were introduced.

Peer Templates as did BGP peers groups were created to simplify the configuration of BGP neighbors but carried more power and less limitations.

There are two types of peer templates:

  • Session templates group and apply configurations statements for the BGP session.
  • Policy templates group policy configurations that can be applied to multiple neighbors.

Here is a basic configuration for both

Configure policy template called ibgp_policy

bgp_tem1

Configure session template called ibgp_session

bgp_tem2

Apply templates to IBGP neighbors

bgp_tem3

Templates support something call inheritance. Inheritance allows one template to inherit characteristics from another template. For instance you could have a high level template that defined BGP keepalives and hold down timers for all of your sessoins.

Here I configure a session template called bgp_top. I then have my ibgp_session inherit bgp_top.

bgp_tem4

There are some limitations around how many inheritance a template can inherit. It’s unlikely that you run into them unless, say you are a large transient ISP.

That’s all for BGP peer templates.

Mike