BGP Influencing Inbound Routing – AS Path

One of the items to remember with BGP is setting outbound attributes will influence inbound traffic. For instance, if you want the traffic into your AS to enter a specific router, you can do accomplish this by setting an outbound attribute. In this post I’ll do AP Path manipulation example.

AS Path is a well known mandatory BGP attribute and is included in all BGP updates. In BGP’s best path selection, it is the 5th attribute compared and is treated like a hop count. The lower the number of AS paths in the list, the more preferred the path.

The following topology will be used.

Each router has a loopback in the format of 100.x.x.x where x.x.x = the routerID. All of the loopbacks are installed into BGP. Looking at R4 the networks from R1, R2 and R3 are installed.

R4#show ip bgp | b Network

Network          Next Hop            Metric LocPrf Weight Path
*  100.1.1.1/32     10.1.34.3                              0 100 i
*>                  10.1.14.1                0             0 100 i
*  100.2.2.2/32     10.1.14.1                              0 100 i
*>                  10.1.34.3                              0 100 i
*  100.3.3.3/32     10.1.14.1                              0 100 i
*>                  10.1.34.3                0             0 100 i
*> 100.4.4.4/32     0.0.0.0                  0         32768 i

Lets say all routes from even routers (R2) should come in to R1, and from odd routers (R1, R3) should come in R3 from R4. Lets use AS path to accomplish this.

If we want R4 to use R1 to get to even routes, we’ll AS prepend the local AS for even routes from R3. Therefore, the path to R1 will have a shorter AS path (or hop count) and will prefer this path. For the odd router routes we just reverse the logic.

Let’s try setting up the configuration for this.

**** R1 Configuration

R1(config)#ip prefix-list ODD_ROUTER_ROUTES seq 10 permit 100.1.1.1/32
R1(config)#ip prefix-list ODD_ROUTER_ROUTES seq 20 permit 100.3.3.3/32

R1(config)#route-map TO_R4_OUT per 10
R1(config-route-map)#match ip add prefix-list ODD_ROUTER_ROUTES
R1(config-route-map)#set as-path prepend 100 100 100
R1(config-route-map)#route-map TO_R4_OUT per 100

R1(config-route-map)#router bgp 100
R1(config-router)#neighbor 10.1.14.4 route-map TO_R4_OUT out

***** R3 Configuration

R3(config)#ip prefix-list EVEN_ROUTER_ROUTES per 100.2.2.2/32

R3(config)#route-map TO_R4_OUT per 10
R3(config-route-map)#match ip address prefix-list EVEN_ROUTER_ROUTES
R3(config-route-map)#set as-path prepend 100 100 100
R3(config-route-map)#route-map TO_R4_OUT per 100

R3(config)#router bgp 100
R3(config-router)#neighbor 10.1.34.4 route-map TO_R4_OUT out

Check the results.

R4#show ip bgp | b Network
   Network          Next Hop            Metric LocPrf Weight Path
*> 100.1.1.1/32     10.1.34.3                              0 100 i
*                   10.1.14.1                0             0 100 100 100 100 i
*> 100.2.2.2/32     10.1.14.1                              0 100 i
*                   10.1.34.3                              0 100 100 100 100 i
*  100.3.3.3/32     10.1.14.1                              0 100 100 100 100 i
*>                  10.1.34.3                0             0 100 i
*> 100.4.4.4/32     0.0.0.0                  0         32768 i

All is working as expected. The even router routes prefer the next hop of 10.1.14.1 and the odd one prefer 10.1.34.3. The paths can be verified with the traceroute command if desired.

CCIE Lab attempt #2

After 18 months spending over 20 hours per week studying I took by first crack at the lab. I felt prepared and confident, but was rattled a little after the start. The TS was larger than I thought and struggled there. I got lost a few times in the topology looking at wrong routers and trying to fix issues I did not need to. The config section was a little better, but still my nerves got the best of me. Needless to say I did not pass and took that as a huge lesson learned.

I went back to the drawing board, and went through all INE’s WB IV and the TS sections of WBII (which I skipped before). I focused on TS for a good 4 weeks. With a month left, I started to work on full labs again.
I went into my second attempt feeling better. My first attempt I was maybe over confident. This one I had the attitude of let’s just see what they throw at me.

The TS section I finished quicker than I had thought I would (with about 45 minutes to spare), and had time to go over the tickets twice. I was relieved when I was able to complete this section early and was confident I had passed it.

Moving on the config section was the same. Other than one task I struggled with, I finished the section with time to spare. Luckily I had this time to review the lab. As I went through it a second time I noticed I had swapped the IP addresses of R1 and R2. Wow, huge mental mistake. Could have failed due to something that simple. I reloaded my rack after this review, and after it came back up I now noticed the ADD/DEL flapping when I turned up debug ip routing. At this point it was about 45 minutes from the end of the lab. I really got nervous here thinking to myself I better find this. Luckily I had ran into this problem a lot of times working on practice labs, and was able to look at the debug and notice the config mistake I had.

I left the lab thinking I was close, but there were still doubts since there were a couple of items I was not sure if I really did what they wanted me to do. I would ask the proctor and would get the answer “what does it say?” I would answer with a couple of options I could do, showing I understand different ways to do it, then the proctor just read the task to me out loud word for word. Instead of being frustrated I laughed to myself and completed the task how I thought they wanted it (I guess I got it?) I felt better than my first attempt, as I had more time to review and did not lose time to self induced issues. Plus my overall stress level was lower during the exam (maybe since I had been in that seat before). I know I lost 2 points for an item which I was not sure how to do exactly. Well, I knew how to do most of that task but some odd ball request. Being only 2 points I decided to leave that alone until the last 10 minutes and go over the last 2 complete times, which I did.

Now it was the waiting game, and I got an email with my score report less than 2 hours after leaving. I thought “uh oh”. That had to be too quick. I logged in and saw PASS. I think I felt more relieved than excited. I was already looking at dates if I needed a third exam. Needless to say I logged in and looked at it about 12 times over the next couple of days.

CCIE lab attempt #1

My lab was booked months in advance for Jan 06 2011 in RTP. I spent over a year preparing and was thought ready for my first attempt at the notorious lab.

The day before I wanted to take an early flight to get to Raleigh early. I have been to Raleigh a few times before, but never to the Cisco RTP campus. Of course, my flight was delayed and I landed a couple of hours later than I wanted.

When I landed, I got the rental car without problems and got to the hotel. Before I ate or did anything else, I wanted to make a dry run or two to the RTP campus. Also, to make sure my GPS was took me there correctly. I made a couple of trips and made sure I knew exactly what building I needed to go to and where I would park. Next, I wanted to be sure I was set for the next day. Went to the local grocery store and bought some fruit and a couple of energy drinks. Now I was set for the lab.

The rest of the night was to relax. Went to the local steak house and got some steak and a couple of beers. I thought a drink or two might help me sleep. I finished up there, went back to my hotel, set the alarm clock, turned on ESPN, and went to sleep.

I did not sleep as well as I should have, the excitement was getting the best of me. Finally it was time to get up. Everything was ready so I hopped into the car and went to breakfast. Cracker Barrel was my choice. I wanted to be sure I got more than enough to eat early so I would not get hungry around 10am. The lab in RTP started at 7:15, and this is earlier then I usually woke up.

I got to RTP and was the first one in the parking lot around 6:50am. There I read through a couple of notes I made waiting for the doors to open. Around 7:05 there were a few people waiting at the doors, so I joined them. No one said anything to each other. Just a couple of head nods. Shortly we were all let in.

The proctor brought us into the room where we put our stuff away and went over the basic rules. Everything was set and we were seated at our racks. I took my rack number and wrote it on the top of my scratch paper. Yes, I know its on the monitor but I wanted to be sure I did not forget it. Rack 15.

After over a year of preparation and I was finally here, about to start the lab. I clicked “start lab” and I had opened up the TS section. First things first, I read over all the tickets and wrote down the ticket numbers and their point value one of my sheets of paper. When I complete a task, I can circle the points and keep a tally. I admit I was not ready for the topology of the TS section. The delivery was not difficult to deal with, but I was not use to it. There were times in this section where I lost track of what router my window was for, and also was looking across wrong VRFs. There had to be about 30 minutes I lost due to stupid mistakes like that. Finally, there was about 20 minutes left and I still had 3 tickets to resolve. Looking at the points, if I got two of them I should be okay. I finished two of the three with 2 minutes left, counted my points and had enough. Since I had verified each ticket twice, I was confident even though I did not complete one ticket. Now onto the config section.

I opened the config portion of the lab, read over all the restrictions (basic stuff), looked over the lab, diagrams, and dove into it.

After reading all the task this I thought to myself, this is not to bad. Jotted a couple of items I needed to be aware of and worked through the lab. Along the way I had a couple of questions which I verified with the proctor (who was a great help). Before I knew it, it was lunch time. Surprisingly I was not hungry at all. Thus, all I ate was a salad, bread, and some extra veggies. There was some fried chicken, but did not want that to sit in my stomach. Not only that, what would it do to my stomach.

Lunch time was over and back to the lab. By this time I was starting the BGP section of my lab (with about 3 hours left). My pace was a little slower than I thought, but again I was going over each task twice to verify along the way. This was my strategy in case I ran out of time at the end. With about 1 hour left I had finished the lab. With the time left I went over all the task again and asked the proctor if there were any doubts. During this look over, I found one issue mistake. I corrected it, saved all my configs and my lab was done.

I left and as soon as I started driving I was questioning myself. Going over everything in my head I started to think “did I do this right”. Then it hit me, I thought of 2 task I did not completed correctly. DAMN. Now I thought I did not pass the config section. Called my wife and taked to her, then went out to drink.

I had dinner and had quite a few drinks while talking sports with a couple of cool guys at the bar. It was about 10pm and I wondered why I did not have my score report yet. Looking back from emails earlier in the day I saw I did indeed get my report, about 2 hours after my lab.

After getting back to the hotel I logged into the Cisco site and saw “FAIL”. Looking at the score report I was stunned. The config section I had passed but I failed the TS. I thought to myself how did I fail the TS? All the task but one were verified working, and looking at the percentage it appears I missed it by 1 task.

With nothing left to loose I went for the re-read. Of course, it came back with no change. Guess it back to labbing for my second attempt. Now I know better what to expect.

Using non default telnet port for telnet

For security reasons it might be desirable not to use the tell known port for telneting into Cisco devices. In this post we’ll go over how to do change that.

To lab this up two routers R1 and R3 are directly connected via the 10.13.1.0/24 network.

First lets make sure regular telnet is working fine.

R1#telnet 10.13.1.3
Trying 10.13.1.3 ... Open

User Access Verification

Password:
R3>exit

[Connection to 10.13.1.3 closed by foreign host]

In this lab lets use port 3011 to telnet into the route and close port 23.  To do this, the rotary command will be used under the vty lines. For telnet protocols, the remote hosts would connect to port number 3000 plus the rotary group number.

Therefore, to perform this we’ll build an ACL to only allow TCP port 3011 into the VTY (thus blocking port 23). Then we will add the rotary 11 under the vty line.

R3(config)#access-list 123 permit tcp any any eq 3011

R3(config)#line vty 0 15
R3(config-line)#rotary 11
R3(config-line)#access-class 123 in

Now lets test.

R1#telnet 10.13.1.3
Trying 10.13.1.3 ...
% Connection refused by remote host

R1#telnet 10.13.1.3 3011
Trying 10.13.1.3, 3011 ... Open

User Access Verification

Password:
R3>

Everything is working as expected.

Using ACLs to filter debug messages

One powerful tool when learning new topics is to lab them up and look at detailed debug output. Debug ip packet is a VERY intensive debug command (NEVER TURN ON IN PRODUCTION NETWORKS), but if used in a lab environment with some filtering can be a great tool.

In this example R1 10.13.1.1 and R3 10.13.1.3 are connected. We will turn on debug ip packet detail and look the TCP handshake for a telnet sessions establishment.

First create an ACL to match the telnet traffic. In this example we will telnet from R1->R3

R1(config)#access-list 101 permit tcp any host 10.13.1.3 eq 23
R1(config)#access-list 101 permit tcp host 10.13.1.3 eq 23 any
Below I suggest to turn of console logging and write all the debug messages to the buffer. This way you do not accidentally override the console and lock yourself out.
R1(config)#no logging console
R1(config)#logging buffered 100000 debug
Turn on debug and establish a telnet session.
R1#debug ip packet detail 101
R1#telnet 10.13.1.3
Trying 10.13.1.3 ... Open

 User Access Verification

 Password:
R3>exit
Looking at the buffered log file on R1, the TCP handshake can be see in the first 3 packets.
R1#show logg
<omitted>
*Jun 23 14:30:56.467: IP: tableid=0, s=10.13.1.1 (local), d=10.13.1.3 (FastEthernet0/0), routed via FIB
*Jun 23 14:30:56.467: IP: s=10.13.1.1 (local), d=10.13.1.3 (FastEthernet0/0), len 44, sending
*Jun 23 14:30:56.467:     TCP src=56601, dst=23, seq=3868846431, ack=0, win=4128 SYN
*Jun 23 14:30:56.475: IP: tableid=0, s=10.13.1.3 (FastEthernet0/0), d=10.13.1.1 (FastEthernet0/0), routed via RIB
*Jun 23 14:30:56.475: IP: s=10.13.1.3 (FastEthernet0/0), d=10.13.1.1 (FastEthernet0/0), len 44, rcvd 3
*Jun 23 14:30:56.475:     TCP src=23, dst=56601, seq=1283492712, ack=3868846432, win=4128 ACK SYN
*Jun 23 14:30:56.479: IP: tableid=0, s=10.13.1.1 (local), d=10.13.1.3 (FastEthernet0/0), routed via FIB
*Jun 23 14:30:56.479: IP: s=10.13.1.1 (local), d=10.13.1.3 (FastEthernet0/0), len 40, sending
*Jun 23 14:30:56.479:     TCP src=56601, dst=23, seq=3868846432, ack=1283492713, win=4128 ACK
In this example we used telnet, but you can use this to see why items such as BGP peering is not working, LDP peering, etc.

BGP Best Path Selection Brief Overview

Cisco’s BGP best path selection algorithm is a 13 step process. In this post, I will go briefly over the 13 steps and in the subsequent post we’ll lab up an example for most of them.

This is a summary from Cisco BGP Best Path Selection Algorithm. Please refer to it for greater detail.

1 – Prefer the path with the highest weight.
Weight is a Cisco propitiatory value and is only locally significant to the router is was configured on. The higher the weight, the more preferred. The default from neighbor is a weight of 0, and routes generated by the local router are 32,768. The range of the value is between 0 – 32,768.

2 – Prefer the path with the highest Local Preference value.
Local Pref is only used between IGP peers and is not passed between to other autonomous systems. Like weight, the higher the Local pref the more preferred the route. The default value is 100.

3 – Prefer a path which was locally originated with the network or aggregate BGP command. Or a path which is redistributed into BGP.
If a BGP path has all three, the order of preference is the network command, redistributed route, then aggregate route.

4 – Prefer the path with the shortest AS_PATH
This step can be skipped with the hidden command bgp bestpath as-path ignore. Think of AS path as a hop count, the shortest path will be preferred.

5 – Prefer the path with the lowest origin type.
IGP (i) is lower than EGP (e), which is lower than incomplete (?).

6 – Prefer the path with the lowest multi-exit discriminator (MED)
This comparison is only if the neighboring AS is the same for both paths. This can be changed by using the command bgp always-compare-med. MED is an BGP optional-nontransitive attribute and is not always known by peers. In fact, peers can ignore updates which it is included, and not pass it along to peers. The lower MED value is preferred.

7 – Prefer eBGP paths over iBGP paths

8 – Prefer the path with the lowest IGP metric to the BGP next hop.

9 – Determine if more than one path is required in the routing table (BGP Multipath)
If there is only to be one path, continue.

10 – If both paths are external, choose the oldest path.
This step is used to minimize route flapping.

11 – Prefer the path with the with the lowest router-ID

12 – If the router ID is the same for more than 1 path, use the path with the shortest cluster length list.

13- Prefer the that comes from the lowest neighbor address

BGP Next Hop

One of the basic rules of BGP is for a route to be installed into the routing table, its must be able to reach the next hop. In this post, we will see an example where the route is not installed into the routing table due to this situation. Then, there are two common ways to resolve it.

First, here is the topology which I will be working from.

The loopbacks for each router are 100.x.x.x where x.x.x is the router ID.

Within AS100, OSPF is used to connect R1, R2, and R3. OSPF is not enabled in the link between R1 and R4.

Also withing AS100, iBGP peers are set up in full mesh.

R1#show ip bgp summary | b Neighbor
Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.1.14.4       4   200      20      24        7    0    0 00:16:45        1
100.2.2.2       4   100      19      25        7    0    0 00:16:17        0
100.3.3.3       4   100      19      25        7    0    0 00:16:18        0

Summary:
R2#show ip bgp sum | b Neighbor
Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
100.1.1.1       4   100      25      19        7    0    0 00:16:37        2
100.3.3.3       4   100      19      19        7    0    0 00:16:37        0

R3#show ip bgp sum | b  Neighbor
Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
100.1.1.1       4   100      25      19        7    0    0 00:16:55        2
100.2.2.2       4   100      19      19        7    0    0 00:16:54        0

On R4, a loopback with the address of 4.4.4.4 is created and placed into BGP. Let’s verify its in the BGP table of R4.

R4#show ip bgp regexp ^$
BGP table version is 2, local router ID is 4.4.4.4
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network          Next Hop            Metric LocPrf Weight Path
*> 4.4.4.4/32       0.0.0.0                  0         32768 i

The route should be advertised to R1.

R1#show ip bgp 4.4.4.4 255.255.255.255
BGP routing table entry for 4.4.4.4/32, version 2
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Advertised to update-groups:
1
200
10.1.14.4 from 10.1.14.4 (4.4.4.4)
Origin IGP, metric 0, localpref 100, valid, external, best

Notice that it is best, so it should be in the routing table and should have reachability it.

R1#ping 4.4.4.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/38/60 ms

One R1, we bring the network for connected interface fa0/0 into BGP, and create a summary for 192.168.0.0/16 so R4 has reachability for any test.

router bgp 100
network 192.168.12.0
aggregate-address 192.168.0.0 255.255.0.0 summary-only

This can be tested by pinging 4.4.4.4 and changing the source address to fa0/0.

R1#ping 4.4.4.4 so fa0/0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
Packet sent with a source address of 192.168.12.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/32/84 ms

With the system as is, try to ping the route from R2.

R2#ping 4.4.4.4

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

Not good. Check to see if the route is in the BGP table.

R2#show ip bgp 4.4.4.4 255.255.255.255
BGP routing table entry for 4.4.4.4/32, version 0
Paths: (1 available, no best path)
Not advertised to any peer
200
10.1.14.4 (inaccessible) from 100.1.1.1 (100.1.1.1)
Origin IGP, metric 0, localpref 100, valid, internal

Its there, but notice it is NOT marked as best. Another way to check this out is with the show ip bgp command.

R2#show ip bgp | i 4.4.4.4
* i4.4.4.4/32       10.1.14.4                0    100      0 200 i

There is no “>” by 4.4.4.4. Therefor it will not be installed into the routing table.

Remember for BGP, the next hop must be reachable. See if there is a route to 10.1.14.4.

R2#show ip route 10.1.14.4
% Network not in table

That’s the problem. As I stated before there are two ways to fix it. The first was we will look at is to install 10.1.14.0/24 network into the IGP domain. Lets do this be redistributing the connected interface into OSPF.

R1(config-router)#redistribute connected subnets route-map CONNECTED->OSPF

After this is done, look at R2 and we now see the network there.

R2#show ip route 10.1.14.4
Routing entry for 10.1.14.0/24
Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 10
Last update from 192.168.12.1 on FastEthernet0/0, 00:00:09 ago
Routing Descriptor Blocks:
* 192.168.12.1, from 100.1.1.1, 00:00:09 ago, via FastEthernet0/0
Route metric is 20, traffic share count is 1

The route is not marked as best.

R2#show ip bgp | i 4.4.4.4
*>i4.4.4.4/32       10.1.14.4                0    100      0 200 i

And reachability is obtained.

R2#ping 4.4.4.4

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/40/92 ms

Now, remove the network from OSPF.

If bringing in the network into the IGP domain is not an option, the next-hop address can be changed between BGP peers. Remember if a packet is passed between eBGP peers, the next-hop address is changed to the sending router’s interface. This can be changed be using the next-help command on R1 to change the next address from the subnet between R1->R4 and itself.

R1(config)#router bgp 100
R1(config-router)#neighbor 100.2.2.2 next-hop-self
R1(config-router)#neighbor 100.3.3.3 next-hop-self

Check R2 and see the next hop is no longer 10.1.14.1, but now 100.1.1.1.

R2#show ip bgp | i 4.4.4.4
*>i4.4.4.4/32       100.1.1.1                0    100      0 200 i

And we can reach R4

R2#ping 4.4.4.4

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/54/112 ms

Just for completeness, ensure R3 can ping 4.4.4.4 as well.

R3#ping 4.4.4.4

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/40/92 ms

To summarize. If a route is in the BGP table but not in the routing table, ensure the next hope is reachable.

OSPF Path Selection

In this post I will go over the basics of OSPF path selection. OSPF path selection in one in the following manor.

1 – Pick the longest match route. This is same for any routing protocol, always using the longest match route.

2 – Use the most preferred path type. If two routes are the same longest match, OSPF will chose the most perferred path type.

The order of path types from Most to Least preferred are as follows.
O – Intra Area routes
O IA – Inter Area routes
O E1 / O N1 – External or NSSA routes with a metric-type of 1
O E2 / O N2 – External or NSSA routes with a metric-type of 2

3 – If the longest match route and path type match. The route with the lowest metric will be used.

Now, a couple of items to note. If the ospf has both a E1 route with a metric of 2500 and a E2 route with a metric of 20, the E1 route will always be inserted into the routing table do to the path selection. The question comes up what is there is a O E1 and a O N1 (the same for O E2 and 0 N2) routes sent to the routing table. For this situation, the one with the lowest cost will be inserted into the routing table. What if these routes have the same cost?

Lets look to RFC 3101 for the answer.

(e) If the current LSA is functionally the same as an installed LSA (i.e., same destination, cost and non-zero forwarding address) then apply the following priorities in deciding which LSA is preferred:

1. A Type-7 LSA with the P-bit set.

2. A Type-5 LSA.

3. The LSA with the higher router ID. [NSSA]

If the P-bit (pass-bit) is set the type-7 will be used, and if not the type-5.

In another post I’ll lab this up with some examples.

 

 

Filtering routes using ip prefix-list.

There are two ways which routes can be filtered. First, an access-list can be built and used for route filtering. Second, a prefix list can be created. In general, I use a access-list to filter traffic and a prefix-list to filter routes.

A prefix list is made of up of two sections. The first part defines which bits of the route to match, and the second part is the subnet mask length to match. For the subnet length, the ge (greater than or equal to) and the le (less than and equal to) operators are used. Just like an access-list, there can be multiple entries to a prefix list to match many routes. Let’s examine a couple of prefix list.

ip prefix-list TEST1 permit 10.0.0.0/8 <<– Matches only the exact 10.0.0.0 255.0.0.0 route.
ip prefix-list TEST2 permit 10.0.0.0/8 ge 16 <<– Matches any route starting with 10.x.x.x and having a subnet mask greater or equal to 255.255.0.0 (ie 255.255.0.0, 255.255.255.0.0, etc)
ip prefix-list TEST3 permit 10.0.0.0/8 le 32 <<– Matches any route starting with 10.x.x.x subnet can be any length.
ip prefix-list TEST4 permit 10.0.0.0/4 ge 16 le 24 <<– Matches any route starting with 10.x.x.x but the subnet mask need to be between a 255.255.0.0 and 255.255.255.0

A couple of common prefix-list seen are the ones matching only the default route, and one match all host routes.

ip prefix-list DEFAULT permit 0.0.0.0/0
ip prefix-list ALL_ROUTES permit 0.0.0.0/0 le 32

Looking at the logic, prefix-list DEFAULT matches the exact 0.0.0.0/0 route. Nothing more. The ALL_ROUTES prefix-list matches everything. The 0.0.0.0/0 portions matches all routes and the le 32 means any subnet mask length.

To make sure we have a full understanding lets lab this up. What I will do is use two routers sharing routes via OSPF. In R2 some loopbacks will be added, and in R1 we will use a distribute-list, using a prefix-list for matching, and filter the OSPF routes from the routing table.

R1 and R3 are connected via the 10.13.1.0/24 network. R1 will be .1 and R3 will be .3.

In R3, the following loopback have been added.

R3#show ip int | i Loop|Internet
<..omitted..>
Loopback100 is up, line protocol is up
Internet address is 10.0.0.1/16
Loopback101 is up, line protocol is up
Internet address is 10.1.1.1/16
Loopback102 is up, line protocol is up
Internet address is 10.2.2.2/24
Loopback103 is up, line protocol is up
Internet address is 10.3.3.3/24
Loopback104 is up, line protocol is up
Internet address is 10.4.4.4/27
Loopback105 is up, line protocol is up
Internet address is 10.5.5.5/27
Loopback106 is up, line protocol is up
Internet address is 106.0.0.6/8
Loopback107 is up, line protocol is up
Internet address is 107.0.0.7/8
Loopback108 is up, line protocol is up
Internet address is 108.8.0.8/17
Loopback109 is up, line protocol is up
Internet address is 109.9.0.9/19
Loopback110 is up, line protocol is up
Internet address is 172.16.10.10/32
Loopback111 is up, line protocol is up
Internet address is 172.16.12.12/32
Loopback112 is up, line protocol is up
Internet address is 192.168.112.112/24
Loopback113 is up, line protocol is up
Internet address is 192.168.113.113/24
Loopback114 is up, line protocol is up
Internet address is 192.168.114.114/24

All the routes are in area 0 via the network 0.0.0.0 0.0.0.0 area 0 command. Look at R1 and ensure all the routes are in the routing table before any filtering. Also, let’s have R3 inject a default route with the default-information originate always command under the ospf process. NOTE: Don’t forget to change the network type to point-to-point for the loopbacks, otherwise all will be advertised into OSPF as stub host.

With ospf neighbors up check the routing table in R1, everything is there as expected.

R1#show ip route ospf
172.16.0.0/32 is subnetted, 2 subnets
O       172.16.12.12 [110/2] via 10.13.1.3, 00:00:01, FastEthernet0/0
O       172.16.10.10 [110/2] via 10.13.1.3, 00:00:01, FastEthernet0/0
O    192.168.114.0/24 [110/2] via 10.13.1.3, 00:00:01, FastEthernet0/0
10.0.0.0/8 is variably subnetted, 7 subnets, 3 masks
O       10.5.5.0/27 [110/2] via 10.13.1.3, 00:00:01, FastEthernet0/0
O       10.4.4.0/27 [110/2] via 10.13.1.3, 00:00:01, FastEthernet0/0
O       10.3.3.0/24 [110/2] via 10.13.1.3, 00:00:01, FastEthernet0/0
O       10.2.2.0/24 [110/2] via 10.13.1.3, 00:00:01, FastEthernet0/0
O       10.0.0.0/16 [110/2] via 10.13.1.3, 00:00:01, FastEthernet0/0
O       10.1.0.0/16 [110/2] via 10.13.1.3, 00:00:01, FastEthernet0/0
O    192.168.113.0/24 [110/2] via 10.13.1.3, 00:00:01, FastEthernet0/0
108.0.0.0/17 is subnetted, 1 subnets
O       108.8.0.0 [110/2] via 10.13.1.3, 00:00:01, FastEthernet0/0
O    192.168.112.0/24 [110/2] via 10.13.1.3, 00:00:01, FastEthernet0/0
109.0.0.0/19 is subnetted, 1 subnets
O       109.9.0.0 [110/2] via 10.13.1.3, 00:00:02, FastEthernet0/0
O    106.0.0.0/8 [110/2] via 10.13.1.3, 00:00:02, FastEthernet0/0
O    107.0.0.0/8 [110/2] via 10.13.1.3, 00:00:02, FastEthernet0/0
O*E2 0.0.0.0/0 [110/1] via 10.13.1.3, 00:00:02, FastEthernet0/0

The first example I will show the whole process. After this only the prefix-list and routing table results. Be sure to remove the distribute-list after each task.

Start by only allowing the default route in.

R1(config)#ip prefix-list DEFAULT per 0.0.0.0/0
R1(config)#router ospf 1
R1(config-router)#distribute-list prefix DEFAULT in fa0/0
R1#show ip route ospf
O*E2 0.0.0.0/0 [110/1] via 10.13.1.3, 00:00:10, FastEthernet0/0

Create a prefix list to only allow 10.x.x.x networks with any subnet mask length.

ip prefix-list NET_10 permit 10.0.0.0/8 le 32

R1(config-router)#do show ip route ospf
10.0.0.0/8 is variably subnetted, 7 subnets, 3 masks
O       10.5.5.0/27 [110/2] via 10.13.1.3, 00:00:12, FastEthernet0/0
O       10.4.4.0/27 [110/2] via 10.13.1.3, 00:00:12, FastEthernet0/0
O       10.3.3.0/24 [110/2] via 10.13.1.3, 00:00:12, FastEthernet0/0
O       10.2.2.0/24 [110/2] via 10.13.1.3, 00:00:12, FastEthernet0/0
O       10.0.0.0/16 [110/2] via 10.13.1.3, 00:00:12, FastEthernet0/0
O       10.1.0.0/16 [110/2] via 10.13.1.3, 00:00:12, FastEthernet0/0

Create a prefix list to only let it the /16 routes from the above output.

ip prefix-list NET_10.0.0.0/16_ONLY permit 10.0.0.0/8 ge 16 le 16

R1(config-router)#do show ip route ospf
10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
O       10.0.0.0/16 [110/2] via 10.13.1.3, 00:00:03, FastEthernet0/0
O       10.1.0.0/16 [110/2] via 10.13.1.3, 00:00:03, FastEthernet0/0

Create a prefix list to allow only host /32 routes (Loopback 110 and 111)

ip prefix-list ONLY/32_ROUTES permit 0.0.0.0/0 ge 32

R1(config-router)#do show ip route ospf
172.16.0.0/32 is subnetted, 2 subnets
O       172.16.12.12 [110/2] via 10.13.1.3, 00:00:05, FastEthernet0/0
O       172.16.10.10 [110/2] via 10.13.1.3, 00:00:05, FastEthernet0/0

Create a prefix list to match any Class A address with any mask. Remember a class A address will have a first bit set to 0.

ip prefix-list CLASS_A_ANY_MASK permit 0.0.0.0/1 le 32

R1(config-router)#do show ip route ospf
10.0.0.0/8 is variably subnetted, 7 subnets, 3 masks
O       10.5.5.0/27 [110/2] via 10.13.1.3, 00:00:48, FastEthernet0/0
O       10.4.4.0/27 [110/2] via 10.13.1.3, 00:00:48, FastEthernet0/0
O       10.3.3.0/24 [110/2] via 10.13.1.3, 00:00:48, FastEthernet0/0
O       10.2.2.0/24 [110/2] via 10.13.1.3, 00:00:48, FastEthernet0/0
O       10.0.0.0/16 [110/2] via 10.13.1.3, 00:00:48, FastEthernet0/0
O       10.1.0.0/16 [110/2] via 10.13.1.3, 00:00:48, FastEthernet0/0
108.0.0.0/17 is subnetted, 1 subnets
O       108.8.0.0 [110/2] via 10.13.1.3, 00:00:48, FastEthernet0/0
109.0.0.0/19 is subnetted, 1 subnets
O       109.9.0.0 [110/2] via 10.13.1.3, 00:00:48, FastEthernet0/0
O    106.0.0.0/8 [110/2] via 10.13.1.3, 00:00:48, FastEthernet0/0
O    107.0.0.0/8 [110/2] via 10.13.1.3, 00:00:48, FastEthernet0/0

Last, lets create a prefix list to match the any 10.x.x.x network with a subnet mask between 255.255.255.0 and 255.255.255.224

ip prefix-list NET_10/24-27 permit 10.0.0.0/8 ge 24 le 27

R1(config-router)#do show ip route ospf
10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
O       10.5.5.0/27 [110/2] via 10.13.1.3, 00:00:04, FastEthernet0/0
O       10.4.4.0/27 [110/2] via 10.13.1.3, 00:00:04, FastEthernet0/0
O       10.3.3.0/24 [110/2] via 10.13.1.3, 00:00:04, FastEthernet0/0
O       10.2.2.0/24 [110/2] via 10.13.1.3, 00:00:04, FastEthernet0/0

That wraps it up. It can easy been seen how much more power and native it is using prefix-list for route filter versus access-list.

Different ways to enter OSPF Area ID

Most times when looking at a network diagrams, the ospf area IDs are simple. Some examples are 0, 1, 2, 51  I am sure we have all seen many times. However, have you ever ran into an area ID of183219713 ?

Remember, there are two ways to display the area ID for ospf. The first is in decimal, and the second is in dotted decimal. So area 1 can be both “area 1″ or “area 0.0.0.1″

To test this, I have configured two routers in serial using a 10.1.12.0/24 network (R1 is .1 and R2 is .2). Lets try using a few of the formats and check if ospf adjacency occurs.

Putting the interfaces into area 1.

R1(config)#int fa0/0
 R1(config-if)# ip ospf 1 area 1
 R1(config-if)#^Z
 R1#
R2(config)#int fa0/0
 R2(config-if)# ip ospf 1 area 0.0.0.1
 R2(config-if)#^Z
 R2#

We can check and see ospf is working by the state, verify the area, and check if there is a neighbor on the link.

R1#show ip ospf int fa0/0 | i State|Area|Neigh
 Internet Address 10.1.12.1/24, Area 1
 Transmit Delay is 1 sec, State BDR, Priority 1
 Neighbor Count is 1, Adjacent neighbor count is 1
R2#show ip ospf int fa0/0 | i State|Area|Neigh
 Internet Address 10.1.12.2/24, Area 0.0.0.1
 Transmit Delay is 1 sec, State DR, Priority 1
 Neighbor Count is 1, Adjacent neighbor count is 1

Great! Not only can it be entered both ways, we can now see they are interchangeable. Easy enough that area 1 can be entered as 0.0.0.1 as well.

Now what if one has a area of 183219713. This is where entering the area in dotted decimal can been a little easier on the eyes. To do so, convert 183219713 to binary.

183219713 decimal = 1010111010111011011000000001 binary.

Recall, dotted decmil is just 32 bits separate into 8 bit sections. Always start from the left most bit.

1010.11101011.10110110.00000001

or more commonly seen as…

10.235.182.1

Lets change the area on the two links to reflect this and verify they come up. R1 will be in decimal and R2 with be in dotted decimal.

Also, this time turn on debug ip ospf asj and look at the router type-1 LSA which is generated, and see the area ID in there.

R1(config)#do debug ip ospf adj
R1(config)#interface FastEthernet0/0
R1(config-if)# ip ospf 1 area 183219713
R1(config-if)#^Z
R1#

<output omitted for brevity>
*Mar  1 00:46:16.931: OSPF: Build router LSA for area 183219713, router ID 10.1.12.1, seq 0x80000005, process 1
R2(config)#do debug ip ospf adj
R2(config)#interface FastEthernet0/0
R2(config-if)# ip ospf 1 area 10.235.182.1
R2(config-if)#^Z
R2#
<output omitted for brevity>
*Mar  1 00:45:37.771: OSPF: Build router LSA for area 10.235.182.1, router ID 10.1.12.2, seq 0x80000005, process 1

Now verify like before.

R1#show ip ospf int fa0/0 | i State|Area|Neigh
 Internet Address 10.1.12.1/24, Area 183219713
 Transmit Delay is 1 sec, State DR, Priority 1
 Neighbor Count is 1, Adjacent neighbor count is 1
R2#show ip ospf int fa0/0 | i State|Area|Neigh
 Internet Address 10.1.12.2/24, Area 10.235.182.1
 Transmit Delay is 1 sec, State BDR, Priority 1
 Neighbor Count is 1, Adjacent neighbor count is 1

Everything worked as expected. Awesome!