show ip route longer-prefixes

daudparvez · ‎09-11-2011

Hi All,

Can someone please explain what the command "show ip route longer-prefixes" does?

The CISCO documentation writes following detail, but i am unable to understand it.

The following is sample output using the longer-prefixes keyword. When the longer-prefixes keyword is included, the address and mask pair becomes the prefix, and any address that matches that prefix is displayed. Therefore, multiple addresses are displayed.

In the following example, the logical AND operation is performed on the source address 10.0.0.0 and the mask 10.0.0.0, resulting in 10.0.0.0. Each destination in the routing table is also logically ANDed with the mask and compared to that result of 10.0.0.0. Any destinations that fall into that range are displayed in the output.

Router# show ip route 10.0.0.0 10.0.0.0 longer-prefixes

Codes: I - IGRP derived, R - RIP derived, O - OSPF derived,

       C - connected, S - static, E - EGP derived, B - BGP derived,

       * - candidate default route, IA - OSPF inter area route,

       i - IS-IS derived, ia - IS-IS, U - per-user static route,

       o - on-demand routing, M - mobile, P - periodic downloaded static route,

       D - EIGRP, EX - EIGRP external, E1 - OSPF external type 1 route,

       E2 - OSPF external type 2 route, N1 - OSPF NSSA external type 1 route,

       N2 - OSPF NSSA external type 2 route

Gateway of last resort is not set

S    10.134.0.0 is directly connected, Ethernet0

S    10.10.0.0 is directly connected, Ethernet0

S    10.129.0.0 is directly connected, Ethernet0

S    10.128.0.0 is directly connected, Ethernet0

S    10.49.246.0 is directly connected, Ethernet0

S    10.160.97.0 is directly connected, Ethernet0

S    10.153.88.0 is directly connected, Ethernet0

S    10.76.141.0 is directly connected, Ethernet0

S    10.75.138.0 is directly connected, Ethernet0

S    10.44.237.0 is directly connected, Ethernet0

S    10.31.222.0 is directly connected, Ethernet0

S    10.16.209.0 is directly connected, Ethernet0

S    10.145.0.0 is directly connected, Ethernet0

S    10.141.0.0 is directly connected, Ethernet0

S    10.138.0.0 is directly connected, Ethernet0

S    10.128.0.0 is directly connected, Ethernet0

     10.19.0.0 255.255.255.0 is subnetted, 1 subnets

C       10.19.64.0 is directly connected, Ethernet0

     10.69.0.0 is variably subnetted, 2 subnets, 2 masks

C       10.69.232.32 255.255.255.240 is directly connected, Ethernet0

S       10.69.0.0 255.255.0.0 is directly connected, Ethernet0

Best Regards,

Daud Parvez

Peter Paluch · ‎09-11-2011

Hello Daud,

The show ip route longer-prefixes allows you to see any subnets of the network you specified if they are present in the routing table.

For example, assume that you have assigned an IP block of 172.16.0.0/15 to your customer. You do not know about the way your customer further subnetted this IP block, nor do you care about it. However, for some reason, you now need to check if there are any subnets from this IP block learned in your routing table. So the command would be:

show ip route 172.16.0.0 255.254.0.0 longer-prefixes

This command will then display all known subnets of the network 172.16.0.0/15 learned in your routing table.

Please feel to ask further!

Best regards,

Peter

milan.kulik · ‎09-12-2011

Hi Peter,

so an analogy of sh ip bgp 172.16.0.0/17 longer-pref?

But why does

Router1#sh ip route 10.200.0.0 255.255.252.0 lon

...

Gateway of last resort is not set

10.0.0.0/8 is variably subnetted, 1704 subnets, 19 masks

B 10.200.0.0/22 [20/10] via 10.123.0.1, 4w2d

B 10.200.0.0/17 [20/10] via 10.123.0.1, 4w2d

show the /17 prefix on my router then?

I'm afraid the IOS logic is more fuzzy here :-(

BR,

Milan

Peter Paluch · ‎09-12-2011

Hello Milan,

Thank you for joining this thread!

Hmmm, this output is interesting. The 10.200.0.0/17 network certainly isn't a subnet of the 10.200.0.0/22.

I guess I now understand why is it called longer-prefixes instead of subnets. The command

show ip route 10.200.0.0 255.255.252.0 longer-prefixes

displays each network N from your routing table for which N && 255.255.252.0 == 10.200.0.0. The netmask of the network N is ignored and not evaluated.

In essence, in this example, it displays all networks whose prefix in the first 22 bits (255.255.252.0) is equal to the first 22 bits of the address 10.200.0.0 - truly, all prefixes equal and longer. They are not true subnets because their mask is not compared to the mask given on the command line.

So no real subnets. Just routes of any netmask whose prefix happens to be identical to the prefix indicated by the show ip route longer-prefixes command.

Thank you for pointing this out!

Best regards,

Peter

milan.kulik · ‎09-12-2011

Hi Peter,

excellent answer, as usually!

What makes this command even more confusing is the fact the mask used does not have to be a standard subnet mask, as shown in the command reference (see the original question).

The results are even more strange then.

I used

Router1#sh ip route 10.200.0.0 10.0.0.0 longer-prefixes

on my router and the output was including not only 10.x.x.x prefixes but also some public IP addresses then!?

BR,

Milan

Peter Paluch · ‎09-12-2011

Milan,

Thank you for your kind words!

A mask of 10.0.0.0??? This has left me slack-jawed

I guess what is being done here is indeed a blind, senseless binary AND between the "mask" in the show ip route longer-prefixes command and the network address from a routing table entry, and the result is simply compared to the network address specified in the same command. In this case, the "mask" argument in the show ip route longer-prefixes should better be called a bitmask rather than netmask. Using arbitrary numbers instead of netmasks probably does not make much sense, though.

Thank you again for pointing out these peculiarities!

Best regards,

Peter

milan.kulik · ‎09-12-2011

Hi Peter,

yes, I agree a general bitmask used as an argument for a binary AND has no practical sense.

The more it should not be used in command reference examples :-(

And I definitely don't understand how the binary AND used in my

Router1#sh ip route 10.200.0.0 10.0.0.0 longer-prefixes

command could result in a public subnet listed in the command output?

BR,

Milan

Peter Paluch · ‎09-12-2011

Hi Milan,

And I definitely don't understand  how the binary AND used in my
Router1#sh ip route 10.200.0.0 10.0.0.0 longer-prefixes
command could result in a public subnet listed in the command output?

Actually, quite easily. I've concocted a small and ugly C code to print out all numbers from 0 to 255 for which N & 10 == 10 which is exactly what your router probably displayed. The code is:

#include 
int main(void)
{
  int i = 0;
  int j = 0;
  for (i = 0; i < 256; i++)
    if ((i & 10) == 10) {
      printf ("%d%s", i, (((j++)%4)==3)?"\n":"\t");
    }
  return 0;
}

The variable i runs from 0 to 255. The variable j just helps me to tab the output by 4 columns. After running this program, the following numbers produce the value 10 after bitmasking them with the value 10:

10 11 14 15

26 27 30 31

42 43 46 47

58 59 62 63

74 75 78 79

90 91 94 95

106 107 110 111

122 123 126 127

138 139 142 143

154 155 158 159

170 171 174 175

186 187 190 191

202 203 206 207

218 219 222 223

234 235 238 239

250 251 254 255

As you can see, it is quite a lot of numbers satisfying the condition N & 10 == 10. The public networks you saw in the output must have had their first octet from this set of numbers.

Best regards,

Peter

milan.kulik · ‎09-12-2011

Hi Peter,

now I understand!

The logic is following:

Using binary conding:

10.0.0.0 is 00001010.00000000.00000000.00000000

10.200.0.0 is 00001010.11001000.00000000.00000000

So any prefix xxxx1010.xxxxxxxx.xxxxxxxx.xxxxxxxx

gives the same result as 10.200.0.0 when binary AND with 10.0.0.0 is applied.

I'm even starting to understand the stupid confusing example used in the command reference now :-)

Thanks again,

Milan

Kishore Chennupati · ‎10-28-2011

Good ol' C programming. I miss it

fedya · ‎06-25-2016

Five years late to the discussion, but I think it's important to add that noncontiguous subnet masks were valid at the early days of the Internet. In fact, a mask, true to its definition, could be at any form, including 10.0.0.0. For example it was allowed to use the last octet of a class B IP address for a subnet ID, and next to the last as a host ID (see Stevens, p. 508). Such implementations of subnet masks were discouraged by later RFCs, but probably Cisco IOS command syntax still keeps functionality of the early definition.

Peter Paluch · ‎06-25-2016

Hello fedya,

This is certainly a very reasonable comment. Yes, it is true that in the very beginnings of IP subnetting, the mask was just an arbitrary 32-bit number with no additional requirements. That would explain the behavior of the longer-prefixes.

Thank you for sharing your insight!

Best regards,
Peter