Challenge: Establish OSPF Adjacency on a LAN Interface

You could get something like this only in a CCIE lab (I would hope): R1 and R2 should establish OSPF adjacency, but you cannot change or remove any of the existing configuration commands (you can add new commands).

R1 configuration
hostname R1
!
interface FastEthernet 0/0
 ip address 192.168.1.17 255.255.255.0
 ip ospf 1 area 1
!
router ospf 1
R2 configuration
hostname R1
!
interface FastEthernet 0/0
 ip address 192.168.1.18 255.255.255.252
 ip ospf 1 area 1
!
router ospf 1

You can find the solution here.

8 comments:

  1. Change both interface OSPF network type from Broadcast to Point-to-Point, it will ignore the mask mismatch when established OSPF adjacency.

    Johnson
    CCIE#11440
  2. I guess I would work without any changes of the configuration (which can't do anyway) because R1 has the IP address 192.168.1.17 on Fa0/0 which is included in the network 192.168.1.18/30 on interface Fa0/0 of R2.
    I didn't test it in a Lab but I guess OSPF does not check if the subnet masks are matching. In this case it would work (but it's really dirty...).

    Regards
    Christoph
  3. I think that CCIE#11440 has already spoiled the fun, so there is nothing wrong in writing this post.

    The solution is quite easy if we refer to the previous post on OSPF subnet mask ignoring. It paid attention to the possible strange results, which might happen on the point-to-point links. But referring to RFC states that this behaviour doesn't really rely on the link type, but rather on the network type, though in normal cases they are just the same. But in some weird situations we are allowed tune this parameter (in fact we are lying to the router and it might have not very pleasant consequences). So it is necessary to issue the

    ip ospf network point-to-point

    command under each interface and the routers will establish OSPF adjacency. After that the routing table looks like that:

    192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks

    O 192.168.1.0/24 [110/20] via 192.168.1.17, 00:25:14, FastEthernet0/0

    C 192.168.1.16/30 is directly connected, FastEthernet0/0

    which is quite unnatural for me as I am far away from CCIE.

    But after all, if we think about it, such thing as network mask is almost nonsense in the point-to-point world. There is only this side and that side and the way we get to any of these is obvious after we have discovered all the necessary information during IPCP.
  4. OSPF neighborship works on multicast. So during neighborship it will not check the subnets.
  5. I tested but it works only on serial interfaces not on fe or broadcast media.
  6. RFC 2328 say:
    " The Hello packet also contains the IP address
    mask of the attached network (Network Mask). On unnumbered
    point-to-point networks and on virtual links this field should be set to 0.0.0.0."

    But... I have try with dynamips/gns3: 2 cisco 36xx 12.4 ios.

    Using point-to-point command under fastethernet the netmask in the ospf hellos is always present and the adjacency came up.
    So i think that there is an algoritm inside ios that make the router do not consider the netmask when, in a broadcast network, you simulate a point to point link.
    From cisco website: " When you configure the command on the Multiaccess interface (that is, Ethernet) or the loopback interface, the following messages are displayed:

    RouterA(config)# int e0
    RouterA(config-if)# ip unnumbered serial 0
    Point-to-point (non-multi-access) interfaces only
    RouterA(config-if)# ip unnumbered loopback 0
    Point-to-point (non-multi-access) interfaces only IP and IP Unnumbered"

    So...
    I' ve tested the serial connections:
    I've set the ip address under the serial. The netmask is always present in the ospf hellos, but the adjancency is done.

    Then I have configured the serial interface as unnumbered...finally as rfc say... the netmask in the ospf hellos is 0.0.0.0 and the adjacency came up.


    Note: on gns3 you can sniff the serial interfaces. See gns3 documentation


    Thanks

    Alessandro
  7. Did you intentionally put the same hostname on both routers or was it just a typo? :)

    I have to admit I had to look for the OSPF packet header as I got confused and thought that the hostname might influence OSPF adjacency.

    I remembered later that ppp chap is where hostname is important.
  8. @Gabriel: oops :( That was a typo.
Add comment
Sidebar