Understanding and Configuring the ip unnumbered Command
Notice the topology for this lab is very simple.
There will only be 1 single ip address ever configured on either router.
We will configure 1.1.1.1/30 on R1 and 2.2.2.2/30 on R2.
There will only be 2 scenarios.
Scenario 1 is when the ip address is configured on the loopback with ip unnumbered on the serial interface.
Scenario 2 is when the ip address is configured on the physical interface and there is no loopback.
Both scenarios are the same prior to configuring the ip address.
In both scenarios we have the good layer 2 datalink over the hdlc serial connection.
R1#sho ip int brief | exclude administratively down
Interface IP-Address OK? Method Status Protocol
Serial1/2 unassigned YES manual up up
We can see our CDP neighbor so we know we have the good layer 2 datalink.
R1#show cdp neighbors
!
Device ID Local Intrfce Holdtme Capability Platform Port ID
R2 Ser 1/2 120 R B 7206VXR Ser 1/1
Now we configure the ip address.
R1#
!
interface Loopback0
ip address 1.1.1.1 255.255.255.252
!
interface Serial1/2ip unnumbered Loopback0
!
R1#sho ip int brief | exclude unass
Interface IP-Address OK? Method Status Protocol
Serial1/2 1.1.1.1 YES TFTP up up
Loopback0 1.1.1.1 YES manual up up
Interestingly the routing table does not show that as a connected route on the serial interface, but only as a connected route on the loopback interface.
R1#sho ip route
Gateway of last resort is not set
1.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 1.1.1.0/30 is directly connected, Loopback0
L 1.1.1.1/32 is directly connected, Loopback0
R1#
We do the same thing on R2.
So we can see r2 as our cdp neighbor and now we can even see his ip address in show cdp neighbor detail.
R1#sho cdp neighbors detail
!
Management address(es):
IP address: 2.2.2.2
!
R1#sho ip route 2.2.2.2
% Network not in table
I'll try it anyway.
an attempt to ping unicast fails......
R1#debug ip icmp
ICMP packet debugging is on
R1#
R1#
R1#ping 2.2.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R1#
R1#
R1#
R1#
R1#
R1#
no debug ip icmp syslog messages are generated.....
but are the echo requests being sent out on to the wire?....
debug ip packet detail should tell us....
let's take a look....
debug ip packet detail shows that the packet is generated
but with no ethernet header and is never sent on to the wire.....
R1#debug ip packet detail dump
IP packet debugging is on (detailed) (dump)
R1#
R1#
R1#show debugging
Generic IP:
IP packet debugging is on (detailed) (dump)
R1#ping 2.2.2.2 repeat 1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
even though it says sending the packet is never sent out on to the wire...
*Apr 8 01:05:45.559: FIBfwd-proc: Default:0.0.0.0/0 not enough info to forward via fib (none none)
*Apr 8 01:05:45.559: FIBipv4-packet-proc: packet routing failed
*Apr 8 01:05:45.563: IP: s=1.1.1.1 (local), d=2.2.2.2, len 100, unroutable
no ethernet header is generated....
0E1FBA90: 45000064 001F0000 E..d....
0E1FBAA0: FF010000 01010101 02020202 0800D579 ..............Uy
0E1FBAB0: 00070000 00000000 0029A8A0 ABCDABCD .........)( +M+M
0E1FBAC0: ABCDABCD ABCDABCD ABCDABCD ABCDABCD +M+M+M+M+M+M+M+M
0E1FBAD0: ABCDABCD ABCDABCD ABCDABCD ABCDABCD +M+M+M+M+M+M+M+M
0E1FBAE0: ABCDABCD ABCDABCD ABCDABCD ABCDABCD +M+M+M+M+M+M+M+M
0E1FBAF0: ABCDABCD ABCDABCD ABCDABCD +M+M+M+M+M+M .
what about a broadcast ping?....
let's give it a whirl.....
the attempt to ping broadcast fails....
R1#sho debugging
Generic IP:
ICMP packet debugging is on
R1#
R1#
R1#ping 255.255.255.255
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 255.255.255.255, timeout is 2 seconds:
.....
R1#
R1#
R1#
no debug ip icmp syslog messages are generated.....
but are the echo requests being sent out on to the wire?....
debug ip packet detail should tell us....
let's take a look....
debug ip packet detail shows that the packet is generated
but this time the ethernet type code of 0x0800 is also generated
and the packet is sent out on to the wire...
R1#debug ip packet detail dump
IP packet debugging is on (detailed) (dump)
R1#
R1#
R1#
R1#show debu
R1#show debugging
Generic IP:
IP packet debugging is on (detailed) (dump)
R1#
R1#
R1#ping 255.255.255.255 rep
R1#ping 255.255.255.255 repeat 1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 255.255.255.255, timeout is 2 seconds:
this time when it says sending, it means it....
but first he generates a packet that does not get sent just for fun...
he lies one more time here and says he's sending when he's really not sending anything...
maybe he's sending it to the next process...
but there is no ethernet header generated so this thing is not going out on to the wire....
and wireshark confirms that this packet is not being seen on the wire....
*Apr 8 01:39:41.103: IP: s=1.1.1.1 (local), d=255.255.255.255 (Serial1/2), len 100, sending broad/multicast
*Apr 8 01:39:41.103: ICMP type=8, code=0
0E013290: 45000064 00440000 E..d.D..
0E0132A0: FF01B953 01010101 FFFFFFFF 080041F5 ..9S..........Au
0E0132B0: 00130000 00000000 00723BD0 ABCDABCD .........r;P+M+M
0E0132C0: ABCDABCD ABCDABCD ABCDABCD ABCDABCD +M+M+M+M+M+M+M+M
0E0132D0: ABCDABCD ABCDABCD ABCDABCD ABCDABCD +M+M+M+M+M+M+M+M
0E0132E0: ABCDABCD ABCDABCD ABCDABCD ABCDABCD +M+M+M+M+M+M+M+M
0E0132F0: ABCDABCD ABCDABCD ABCDABCD +M+M+M+M+M+M
but then he says oh what the hell and goes ahead and generates another one....
this time also generating an ethernet type code 0x0800 and sending it on its merry way out on to the wire....
*Apr 8 01:39:41.119: IP: s=1.1.1.1 (local), d=255.255.255.255 (Serial1/2), len 100, sending full packet
*Apr 8 01:39:41.123: ICMP type=8, code=0
0E1FAE10: 8F000800 45000064 00450000 ....E..d.E..
0E1FAE20: FF01B952 01010101 FFFFFFFF 08000B16 ..9R............
0E1FAE30: 00140000 00000000 007872A8 ABCDABCD .........xr(+M+M
0E1FAE40: ABCDABCD ABCDABCD ABCDABCD ABCDABCD +M+M+M+M+M+M+M+M
0E1FAE50: ABCDABCD ABCDABCD ABCDABCD ABCDABCD +M+M+M+M+M+M+M+M
0E1FAE60: ABCDABCD ABCDABCD ABCDABCD ABCDABCD +M+M+M+M+M+M+M+M
0E1FAE70: ABCDABCD ABCDABCD ABCDABCD +M+M+M+M+M+M .
and wireshark confirms this packet is being sent out on to the wire....
Frame 2113: 104 bytes on wire (832 bits), 104 bytes captured (832 bits) on interface 0
Cisco HDLC
Internet Protocol Version 4, Src: 1.1.1.1, Dst: 255.255.255.255
Internet Control Message Protocol
Type: 8 (Echo (ping) request)
Code: 0
Checksum: 0xce0f [correct]
[Checksum Status: Good]
Identifier (BE): 22 (0x0016)
Identifier (LE): 5632 (0x1600)
Sequence number (BE): 0 (0x0000)
Sequence number (LE): 0 (0x0000)
[No response seen]
[Expert Info (Warning/Sequence): No response seen to ICMP request]
Data (72 bytes)
Data: 00000000007cafa8abcdabcdabcdabcdabcdabcdabcdabcd...
[Length: 72]
the far end confirms the echo request is being received...
however, because he has no route back to the source
the packet is dropped and on echo reply is sent back out on to the wire...
R2#
*Apr 8 01:56:04.531: ICMP: echo reply sent, src 2.2.2.2, dst 1.1.1.1, topology BASE, dscp 0 topoid 0
R2#
*Apr 8 01:51:06.067: FIBfwd-proc: Default:0.0.0.0/0 not enough info to forward via fib (none none)
*Apr 8 01:51:06.067: FIBipv4-packet-proc: packet routing failed
debug back at the source confirm no echo reply is being received...
ok so at this point there is no difference between scenario 1 and scenario 2...
your sitting here thinking ok so this doesn't look all that good....
because I can't ping unicast...
and get no reply to my broadcast ping....
show how the heck am I ever going to get my ospf neighbors to come up?.....
well the ospf hello is sent to a multicast address 224.0.0.5....
and my broadcast ping did at least go out on to the wire and got received by the far end router...
so what the heck....let's go ahead and slap on the ospf configs and see what happens....
ospf cares not about any unicast route....
he goes ahead and transmits the packet right out onto that damn wire regardless....
router ospf 1
network 0.0.0.0 255.255.255.255 area 0
as soon as he has an ospf interface that is up he's going to send out that hello..
he could not care less about not having any unicast route
because this packet will be sent to a mulitcast destination
so the unicast routing table is not part of the equation here....
and this is not icmp so debug ip icmp will not be any help to us here...
R1#debug ip icmp
ICMP packet debugging is on
R1#
R1#
nothing....
how about debug ip ospf hello?...
R1#debug ip ospf hello
OSPF hello debugging is on
R1#
*Apr 8 02:17:30.127: OSPF-1 HELLO Se1/2: Send hello to 224.0.0.5 area 0 from 1.1.1.1
R1#
R1#
what about debug ip packet detail?....
R1#debug ip packet detail dump
IP packet debugging is on (detailed) (dump)
*Apr 8 02:18:45.491: IP: s=1.1.1.1 (local), d=224.0.0.5 (Serial1/2), len 76, sending full packet, proto=89
0E013010: 0F000800 45C0004C 01400000 ....E@.L.@..
0E013020: 0159D552 01010101 E0000005 0201002C .YUR....`......,
0E013030: 01010101 00000000 E9A00000 00000000 ........i ......
0E013040: 00000000 FFFFFFFC 000A1201 00000028 .......|.......(
0E013050: 00000000 00000000 FFF60003 00010004 .........v......
0E013060: 00000001 ....
it has the ethernet header and it says it is being sent out on to the wire....
wireshark confirms the hello packet is going out on to the wire...
and if we check the router at the other end of the datalink we see that the hello packet is being received...
so if we go to the other end and enable ospf we should get our neighbor eh?...
let's give it a whirl.....
whereas in scenario 1 the ospf neighbor comes up
when ospf is configured on the far end router...
here in scenario 2 the ospf neighbor does not come up...
why is my ospf neigbor not coming up...
it is telling me that the received ospf hello packet
is not on the same common subnet
and therefore there will be no ospf neighbor
because ospf neighbors have to be on the same common subnet...
R1#debug ip ospf hello
OSPF hello debugging is on
R1#
R1#
*Apr 8 02:26:57.903: OSPF-1 HELLO Se1/2: Send hello to 224.0.0.5 area 0 from 1.1.1.1
R1#
both routers are sending out hellos...
but here in scenario 2 the subnet mask is also sent along in the ospf hello packet...
Frame 2794: 80 bytes on wire (640 bits), 80 bytes captured (640 bits) on interface 0
Cisco HDLC
Internet Protocol Version 4, Src: 1.1.1.1, Dst: 224.0.0.5
Open Shortest Path First
OSPF Header
Version: 2
Message Type: Hello Packet (1)
Packet Length: 44
Source OSPF Router: 1.1.1.1
Area ID: 0.0.0.0 (Backbone)
Checksum: 0xe9a0 [correct]
Auth Type: Null (0)
Auth Data (none): 0000000000000000
OSPF Hello Packet
Network Mask: 255.255.255.252
Hello Interval [sec]: 10
Options: 0x12 ((L) LLS Data block, (E) External Routing)
Router Priority: 1
Router Dead Interval [sec]: 40
Designated Router: 0.0.0.0
Backup Designated Router: 0.0.0.0
OSPF LLS Data Block
in scenario 1 where we use the ip unnumbered command...
the ospf hello packet does not send along the mask...
apparently when you use the ip unnumbered command...
the mask of the borrowed ip address is not sent along in the ospf hello packet...
instead a mask of 0.0.0.0 is sent in place of the actual configured subnet mask...
and a subnet mask of 0.0.0.0 would mean that every ip address in the world is in the same subnet...
it is the mother of all subnets...
just like the default route is the mother of all summary routes....
see scenario 1 packet capture showing actual configured subnet is replaced with /0 subnet....
I thing if I could spoof an ospf hello packet with mask of 0.0.0.0 the neighbors would come up eh?.....
so here in scenario 2 when the ospf hello packet is received
the router looks at the source ip address of the hello packet
along with the mask...
in scenario 2
where the mask is 255.255.255.252
1.1.1.1/30
is not on the same subnet as
2.2.2.2/30
R1#debug ip ospf adj
OSPF adjacency debugging is on
R1#
R1#
*Apr 8 02:35:23.343: OSPF-1 ADJ Se1/2: Rcv pkt from 2.2.2.2, area 0.0.0.0 : src not on the same network
R1#
R1#show ip ospf interface brief
Interface PID Area IP Address/Mask Cost State Nbrs F/C
Se1/2 1 0 1.1.1.1/30 64 P2P 0/0
R1#sho ip ospf neighbor
R1#
R1#
R1#
wheras in scenario 1
where the mask is 0.0.0.0
1.1.1.1/0
is in the same subnet as
2.2.2.2/0
and so since ospf router can become neighbors
with another router in the same subnet
the ospf adjacency is formed...
*Apr 7 23:52:50.055: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on Serial1/2 from LOADING to FULL, Loading Done
R1#show ip ospf interface brief
R1#sho ip ospf neighbor
============ everything below here is old ========
============ move up as needed =================
R1#show ip int brief | exclude unass
Interface IP-Address OK? Method Status Protocol
Loopback0 1.1.1.1 YES manual up up
R1#sho int ser 1/2 | include address
R1#
R1#conf t
R1(config)#int ser 1/2
R1(config-if)#ip unnumbered loopback 0
R1#sho int ser 1/2 | include address
Interface is unnumbered. Using address of Loopback0 (1.1.1.1)
R1#show ip int brief | exclude unass
Interface IP-Address OK? Method Status Protocol
Serial1/2 1.1.1.1 YES TFTP up up
Loopback0 1.1.1.1 YES manual up up
R1#sho ip route | begin Gateway
Gateway of last resort is not set
1.0.0.0/32 is subnetted, 1 subnets
C 1.1.1.1 is directly connected, Loopback0
R1#
Same thing on R2.
At this point you could hear a pin drop on the wire. No IP traffic whatsoever.
IP packet debugging is on (detailed) (dump)
R1#
R1#
R1#
R1#
R1#
R1#
R1#
R1#
The only thing of interest on the wire is that R1 and R2 are sending out layer 2 hdlc frames containing CDP interface id and ip address.
R1#show cdp neighbors
!
Device ID Local Intrfce Holdtme Capability Platform Port ID
R2 Ser 1/2 172 R B 7206VXR Ser 1/1
R1#
R1#
This doesn't work on ethernet datalinks so we don't have to worry about that.
R3(config)#int fastEthernet 0/0
R3(config-if)#ip unnumbered loopback 0
Point-to-point (non-multi-access) interfaces only
R3(config-if)#
R3(config-if)#
Neither router knows anything about the other ip address.
Oh sure, he knows that's his CDP neighbor. But what good does that do him if he has no route?
R1#sho cdp neighbors detail
-------------------------
Device ID: R2
Entry address(es):
IP address: 2.2.2.2
R1#show ip route 2.2.2.2
% Network not in table
R1#
R1#
R1#sho ip cef 2.2.2.2
0.0.0.0/0
no route
R1#
R1#
The router laughs at him for even trying.
R1#show debugging
Generic IP:
ICMP packet debugging is on
R1#
R1#
R1#ping 2.2.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R1#
Not a single icmp debug syslog message. The wire sees nothing.
Same thing on R2.
OSPF seems different than ICMP
OSPF on the other hand appears to be a different animal than ICMP.
Because even though I am not able to generate an icmp packet due to no route...
ospf could apparently not care less about not having any route......he's gonna shoot that hello out any ospf enabled interface he's got whether it has any neighbor or not...
remember there is no router ospf configuration on r2 at this time....
even though r1 has no ospf neighbor, and he is not able to generate an icmp echo request packet.......
regardless of that, he is still going forward with his crazy plan to transmit an ospf hello packet out on to the wire destined for 244.0.0.5............look at him go.....
R1#sh ip ospf interface
R1#
R1#
R1#
R1#show run | section router
R1#
R1#
R1#
R1(config)#router ospf 1
R1(config-router)#network 0.0.0.0 0.0.0.0 area 0
R1#
*Apr 7 15:00:04.579: OSPF-1 HELLO Se1/2: Send hello to 224.0.0.5 area 0 from 0.0.0.0
R1#
R1#sho ip ospf interface brief
Interface PID Area IP Address/Mask Cost State Nbrs F/C
Lo0 1 0 1.1.1.1/32 1 LOOP 0/0
Se1/2 1 0 Unnumbered Lo0 64 P2P 0/0
R1#
R1#sho ip ospf neighbor
R1#
R1#
R1#
So why don't I have an ospf neighbor?
R1#sho ip ospf neighbor
R1#
R1#
R1#
Is it because I can't ping across the hdlc serial datalink?
R1#ping 255.255.255.255
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 255.255.255.255, timeout is 2 seconds:
.....
R1#
The datalink is up/up and I have good CDP neighbor.
R1#sh int ser 1/2
Serial1/2 is up, line protocol is up
R1#sho cdp neighbors
!
Device ID Local Intrfce Holdtme Capability Platform Port ID
R2 Ser 1/2 134 R B 7206VXR Ser 1/1
R1#
Layer 2 CDP frames are being exchanged between R1 and R2.
So why no ospf neighbor.
Well obviously ospf is not even configured on R2 so that's a problem there eh?
So I go to R2 and go router ospf network 0.0.0.0 0.0.0.0 area 0.
R2 immediately begins to send ospf hellos out on to the wire just as R1 did.
Now both routers are exchanging ospf hello packets.
As soon as the ospf lsdb exchange has completed and the adjacency state has become full, and not before then, R1 learns of the 2.2.2.2 network from his new ospf neighbor.
Since he now has a route to 2.2.2.2 he is able to generate an icmp echo request message and send it out on to the wire. Since the same thing is going on over at R2, R2 will now have an ospf route back to the source of the echo request and he will be able to generate and icmp echco reply packet and send it out on to the wire towards R1. The ping is now successful.
R1#sho ip route
!
Gateway of last resort is not set
1.0.0.0/32 is subnetted, 1 subnets
C 1.1.1.1 is directly connected, Loopback0
2.0.0.0/32 is subnetted, 1 subnets
O 2.2.2.2 [110/65] via 2.2.2.2, 00:02:00, Serial1/2
R1#
R1#sho ip route 2.2.2.2
Routing entry for 2.2.2.2/32
Known via "ospf 1", distance 110, metric 65, type intra area
Last update from 2.2.2.2 on Serial1/2, 00:02:04 ago
Routing Descriptor Blocks:
* 2.2.2.2, from 2.2.2.2, 00:02:04 ago, via Serial1/2
Route metric is 65, traffic share count is 1
R1#
R1#ping 2.2.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/26/32 ms
R1#
R1#
The key here, and the thing that makes this ip unnumbered command interesting, is that we now have ospf neighbor between two routers who connecting interfaces are in uncommon subnets.
This breaks one of the rules for establishing ospf adjaceny. That rule being that the two connecting interfaces must be on the same subnet in order for adjacency to form.
Even though the network on the interface from which the point to point link borrows the IP address is different from the network on the interface of the other router, it still works fine because each router has the outgoing interface for the next-hop instead of the source address of the routing update.
For example I can make the borrowed loopback interface network to be anything and there is no uncommon subnet problem for ospf because the next hop is the outgoing interface. If you're not using ip unnumbered than the next hop will not be the outgoing interface but rather will be the source ip address of the routing update.
R2#sho int loopback 0
Loopback0 is up, line protocol is up
Internet address is 34.22.11.75/24
R1#sho ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
34.22.11.75 0 FULL/ - 00:00:32 34.22.11.75 Serial1/2
R1#
R1#sho ip route
!
Gateway of last resort is not set
1.0.0.0/32 is subnetted, 1 subnets
C 1.1.1.1 is directly connected, Loopback0
34.0.0.0/24 is subnetted, 1 subnets
O 34.22.11.0 [110/65] via 34.22.11.75, 00:01:22, Serial1/2
!
R1#sho ip route 34.22.11.75
Routing entry for 34.22.11.0/24
Known via "ospf 1", distance 110, metric 65, type intra area
Last update from 34.22.11.75 on Serial1/2, 00:03:29 ago
Routing Descriptor Blocks:
* 34.22.11.75, from 34.22.11.75, 00:03:29 ago, via Serial1/2
Route metric is 65, traffic share count is 1
R1#
R1#ping 34.22.11.75
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 34.22.11.75, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/31/40 ms
R1#
Because if we were to try that stunt without using ip unnumbered command we would be in a heap of hurt brother.
R2#show int ser 1/1
Serial1/1 is up, line protocol is up
Internet address is 34.22.11.75/24
R2#sho ip ospf interface brief
Interface PID Area IP Address/Mask Cost State Nbrs F/C
Se1/1 1 0 34.22.11.75/24 64 P2P 0/0
R2#
Both routers are sending hellos, but because R1
