[OSPF] Cisco OSPF implementation - Different networks on serial links

Vlad Olariu <florinvlad.olariu@gmail.com> Sat, 06 June 2015 17:40 UTC

Return-Path: <ilcon7e@gmail.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E95D1A9029 for <ospf@ietfa.amsl.com>; Sat, 6 Jun 2015 10:40:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.601
X-Spam-Level: ***
X-Spam-Status: No, score=3.601 tagged_above=-999 required=5 tests=[BAYES_99=3.5, BAYES_999=0.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w29sMIKB5tGK for <ospf@ietfa.amsl.com>; Sat, 6 Jun 2015 10:40:37 -0700 (PDT)
Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 713E31A9028 for <ospf@ietf.org>; Sat, 6 Jun 2015 10:40:37 -0700 (PDT)
Received: by wigg3 with SMTP id g3so14131658wig.1 for <ospf@ietf.org>; Sat, 06 Jun 2015 10:40:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=B5IpY2BKziiZIwpCVFeuRE6NEcecnMuiOx3r73dIm8E=; b=w9AQmLKzeIefpCzQXjUvDgaLp90PNdW5iun01G2gvhNzWKWN09/clzoiAS6hnHprhU 6gkBovFscfOkMtlP5WzrxLREihDvJfeCWiYP/9S9Hv/y1J+498QrEiX/apdgSjaZ1Hqp 3NwnBdf0iO0FzZ1kfKahMh5zsxUOF7KiMCnmRnevSXIZfuia+lOqUzphOyA9vhZ8HPgW 3+A8Kk11bwLKbRDK5Vo+v5NWblHYGKs2CHsJc59Eo4tAE1DG/cmBIxMN6THspRkBcub/ q8FwA1HKhjz5wTs7rf036chiSl2eocP8FFenD+J/x4tIh6TiKET05jMn06Hj+zZBUP/E LMIA==
MIME-Version: 1.0
X-Received: by 10.194.122.168 with SMTP id lt8mr16488236wjb.77.1433612435962; Sat, 06 Jun 2015 10:40:35 -0700 (PDT)
Sender: ilcon7e@gmail.com
Received: by 10.180.19.197 with HTTP; Sat, 6 Jun 2015 10:40:35 -0700 (PDT)
Date: Sat, 6 Jun 2015 19:40:35 +0200
X-Google-Sender-Auth: wWVJb5GIrA9fhtp0xOgfMuaRUYM
Message-ID: <CABE=0MXU949V0x2aNHV1fJxD8XPufwnHoGQ1seY3ENC7cnCP_w@mail.gmail.com>
From: Vlad Olariu <florinvlad.olariu@gmail.com>
To: ospf@ietf.org
Content-Type: multipart/alternative; boundary=089e011777affdc36c0517dce74c
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/Q09dPI10wAgCy_-0IUOlU-OJcZY>
Subject: [OSPF] Cisco OSPF implementation - Different networks on serial links
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ospf/>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 06 Jun 2015 17:45:34 -0000

Hello,

I was reading the OSPFv2 RFC, namely, from page 62:

The Area ID specified in the header must either:
            (1) Match the Area ID of the receiving interface.  In this
                case, the packet has been sent over a single hop.
                Therefore, the packet’s IP source address is required to
                be on the same network as the receiving interface.  This
                can be verified by comparing the packet’s IP source
                address to the interface’s IP address, after masking
                both addresses with the interface mask.  *This comparison*
*                should not be performed on point-to-point networks*. On
                point-to-point networks, the interface addresses of each
                end of the link are assigned independently, if they are
                assigned at all.

I have tried this on various Cisco routers and it doesn't work. It
complains about the interfaces being in a different network.

Is this an implementation flaw?