Re: [OSPF] I have a question regarding forwarding address

"Acee Lindem (acee)" <acee@cisco.com> Wed, 13 July 2016 15:29 UTC

Return-Path: <acee@cisco.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1133A12B011 for <ospf@ietfa.amsl.com>; Wed, 13 Jul 2016 08:29:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.806
X-Spam-Level:
X-Spam-Status: No, score=-15.806 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 wSjktnkZJfDa for <ospf@ietfa.amsl.com>; Wed, 13 Jul 2016 08:29:52 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04DDB12B00E for <ospf@ietf.org>; Wed, 13 Jul 2016 08:29:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=36113; q=dns/txt; s=iport; t=1468423791; x=1469633391; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=SA/wXoeLmgT2EfENvpkJyJPs+jqMNu9x5SirJXxVGyk=; b=AiF435HTDCb5c6JbFoD4uDGh5CtpVSQ/poQcZVzuyfY4MGCyuKsZZhlq 8q5MEuqWo9d27DTrvS/QkS9JDgpzXV1cAwROlyjwvS28nhOopoy1mzcKp B60MVApig1GIunm56UOh3Obicx08Y2BICPjOHwO6SsLOjJ1U2fnugw1wK k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AVBgCgXYZX/5JdJa1SCYJwTlZ6AganTIR/igiCD4F6GoV+AhwpaToSAQEBAQEBAWUnhFwBAQUjKS0QAgEGAhECAQECIQcDAgICHwQNFAkIAgQOBYgWAxIFlFydHYVJhQkNhB4BAQEBAQEBAwEBAQEBAQEBAQEBHIp3gkOBVwMBHyQWgkuCWgEEmGg0AYYQhjCCFoFrhFmIa4gfGAyHUwEPFQEvg3FuAYdyASUffwEBAQ
X-IronPort-AV: E=Sophos;i="5.28,357,1464652800"; d="scan'208,217";a="128333813"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Jul 2016 15:29:50 +0000
Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u6DFToB4023844 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 13 Jul 2016 15:29:50 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 13 Jul 2016 11:29:49 -0400
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Wed, 13 Jul 2016 11:29:49 -0400
From: "Acee Lindem (acee)" <acee@cisco.com>
To: Abhinay R <abhinay.is2006@gmail.com>
Thread-Topic: [OSPF] I have a question regarding forwarding address
Thread-Index: AQHR3P+rJceEXzopTEuIVn697hQTUKAWY4KAgABZMoD//8ASAA==
Date: Wed, 13 Jul 2016 15:29:49 +0000
Message-ID: <D3ABD4EB.6BA68%acee@cisco.com>
References: <CAHUNbhbyQH-ALAT7gx55yADsxk4P8v0ZSgiK0bONX=2bMNhSCA@mail.gmail.com> <D3ABBF93.6B96E%acee@cisco.com> <CAHUNbhbC0sq2O1XcqWDP-OoO41n8iNQW5OgrCvzgZ3BkNU+H-Q@mail.gmail.com>
In-Reply-To: <CAHUNbhbC0sq2O1XcqWDP-OoO41n8iNQW5OgrCvzgZ3BkNU+H-Q@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.196]
Content-Type: multipart/alternative; boundary="_000_D3ABD4EB6BA68aceeciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ospf/88yk_VrtyZP2M2REgH5ngs4mA5E>
Cc: "ospf@ietf.org" <ospf@ietf.org>
Subject: Re: [OSPF] I have a question regarding forwarding address
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Wed, 13 Jul 2016 15:29:55 -0000

Hi Abhinay,

From: Abhinay R <abhinay.is2006@gmail.com<mailto:abhinay.is2006@gmail.com>>
Date: Wednesday, July 13, 2016 at 11:18 AM
To: Acee Lindem <acee@cisco.com<mailto:acee@cisco.com>>
Cc: OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org>>
Subject: Re: [OSPF] I have a question regarding forwarding address

Hi Acee,
        According to "12.4.4. AS-external-LSAs" where forwarding address example is given, I see that it states forwarding address will just help to skip a extra hop to destination.
And don't you think if forwarding address is set to inter area nexthop, then if that inter area route gets deleted. it will take time for that change to reach the ASBR and then ASBR to compute the change and originate new External LSA with no forwarding address.and this need to be flooded across the AS and new route need to be installed in them, which will be time consuming. So don't you think that forwarding address must be set if the next hop is part of connected network ?

No - the OSPF specification sets no such criteria. Although one might ask why a router in the area with the next-hop is not redistributing the route.


and is there any scenario where the nexthop will be intra or inter area route, until the nexthop is explicitly set with routemap.

I would not be a proponent of routing-policy which allows direct manipulation of the next-hop.

Note that the example you cite, is just an example. The specification doesn’t limit forwarding address advertisement to this use-case. Some implementations,  do limit advertisement to the most common use cases but this is not limited by the OSPF specification.

Thanks,
Acee
P.S. If I were to be designing OSPFv4, I would most likely omit the forwarding address feature (along with virtual links).




 12.4.4.1.  Examples of AS-external-LSAs

                Consider once again the AS pictured in Figure 6.  There
                are two AS boundary routers: RT5 and RT7.  Router RT5
                originates three AS-external-LSAs, for networks N12-N14.
                Router RT7 originates two AS-external-LSAs, for networks
                N12 and N15.  Assume that RT7 has learned its route to
                N12 via BGP, and that it wishes to advertise a Type 2
                metric to the AS.  RT7 would then originate the
                following LSA for N12:

        ; AS-external-LSA for Network N12,
        ; originated by Router RT7

        LS age = 0                  ;always true on origination
        Options = (E-bit)           ;
        LS type = 5                 ;AS-external-LSA
        Link State ID = N12's IP network number
        Advertising Router = Router RT7's ID
        bit E = 1                   ;Type 2 metric
        metric = 2
        Forwarding address = 0.0.0.0





Moy                         Standards Track                   [Page 140]
?
RFC 2328                     OSPF Version 2                   April 1998


                    In the above example, the forwarding address field
                    has been set to 0.0.0.0, indicating that packets for
                    the external destination should be forwarded to the
                    advertising OSPF router (RT7).  This is not always
                    desirable.  Consider the example pictured in Figure
                    16.  There are three OSPF routers (RTA, RTB and RTC)
                    connected to a common network.  Only one of these
                    routers, RTA, is exchanging BGP information with the
                    non-OSPF router RTX.  RTA must then originate AS-
                    external-LSAs for those destinations it has learned
                    from RTX.  By using the AS-external-LSA's forwarding
                    address field, RTA can specify that packets for
                    these destinations be forwarded directly to RTX.
                    Without this feature, Routers RTB and RTC would take
                    an extra hop to get to these destinations.

                    Note that when the forwarding address field is non-
                    zero, it should point to a router belonging to
                    another Autonomous System.

                    A forwarding address can also be specified for the
                    default route.  For example, in figure 16 RTA may
                    want to specify that all externally-destined packets
                    should by default be forwarded to its BGP peer RTX.
                    The resulting AS-external-LSA is pictured below.
                    Note that the Link State ID is set to
                    DefaultDestination.

        ; Default route, originated by Router RTA
        ; Packets forwarded through RTX

        LS age = 0                  ;always true on origination
        Options = (E-bit)           ;
        LS type = 5                 ;AS-external-LSA
        Link State ID = DefaultDestination  ; default route
        Advertising Router = Router RTA's ID
        bit E = 1                   ;Type 2 metric
        metric = 1
        Forwarding address = RTX's IP address

                    In figure 16, suppose instead that both RTA and RTB
                    exchange BGP information with RTX.  In this case,



Moy                         Standards Track                   [Page 141]
?
RFC 2328                     OSPF Version 2                   April 1998


                    RTA and RTB would originate the same set of AS-
                    external-LSAs.  These LSAs, if they specify the same
                    metric, would be functionally equivalent since they
                    would specify the same destination and forwarding
                    address (RTX).  This leads to a clear duplication of
                    effort.  If only one of RTA or RTB originated the
                    set of AS-external-LSAs, the routing would remain
                    the same, and the size of the link state database
                    would decrease.  However, it must be unambiguously
                    defined as to which router originates the LSAs
                    (otherwise neither may, or the identity of the
                    originator may oscillate).  The following rule is
                    thereby established: if two routers, both reachable
                    from one another, originate functionally equivalent
                    AS-external-LSAs (i.e., same destination, cost and
                    non-zero forwarding address), then the LSA
                    originated by the router having the highest OSPF
                    Router ID is used.  The router having the lower OSPF
                    Router ID can then flush its LSA.  Flushing an LSA
                    is discussed in Section 14.1.


                                +
                                |
                      +---+.....|.BGP
                      |RTA|-----|.....+---+
                      +---+     |-----|RTX|
                                |     +---+
                      +---+     |
                      |RTB|-----|
                      +---+     |
                                |
                      +---+     |
                      |RTC|-----|
                      +---+     |
                                |
                                +


               Figure 16: Forwarding address example



Thanks & Regards,

Abhinay R

On Wed, Jul 13, 2016 at 7:29 PM, Acee Lindem (acee) <acee@cisco.com<mailto:acee@cisco.com>> wrote:
Hi Abhinay,

Your questions are very implementation specific but since I’m a good guy…

From: OSPF <ospf-bounces@ietf.org<mailto:ospf-bounces@ietf.org>> on behalf of Abhinay R <abhinay.is2006@gmail.com<mailto:abhinay.is2006@gmail.com>>
Date: Wednesday, July 13, 2016 at 8:11 AM
To: OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org>>
Subject: [OSPF] I have a question regarding forwarding address

Hi All,
        I have a question on when forwarding address is set in external LSA?

Suppose I have a route from RIP say 100.1.1.0/24<http://100.1.1.0/24> with nexthop 10.1.1.1 in routing table and I want to redistribute that route into OSPF, then I feel below conditions must be vaild to set 10.1.1.1 as forwarding address in the external LSA that OSPF originates for 100.1.1.0/24<http://100.1.1.0/24> network.


These conditions set the forwarding address field to a non-zero address:

    OSPF is enabled on the ASBR's next hop interface AND

Although, it would be a strange topology where it weren’t enabled, it only has to be reachable within the OSPF routing domain as an intra or inter area route.




    ASBR's next hop interface is non-passive under OSPF AND

This should have no bearing on whether the forwarding address is advertised. There could be a better path through the OSPF routing domain independent of whether the interface is passive.



    ASBR's next hop interface is not point-to-point AND

    ASBR's next hop interface is not point-to-multipoint AND

Although the likelihood of the forwarding address providing a better path is increased for multi-access networks, it is not necessary.




    ASBR's next hop interface address falls under the network range specified in the router ospf command.

Again, the next hop only has to be reachable within the OSPF routing domain as an intra or inter area route.

Hope the Helps,
Acee






Any other conditions besides these set the forwarding address to 0.0.0.0.

If I have 10.1.1.0/24<http://10.1.1.0/24> network as intra or inter route in OSPF routing table at the router that imported RIP route, do I originate External LSA with 10.1.1.1 set as forwarding address ?


There is a confusion that if the redistributed network nexthop is present in routing table as intra inter or connected route, we need to set it as forwarding address. Please clarify.


While we receive a External LSA with forwarding address set, then we see if there is a connected, intra or inter route to that nexthop and then use it to compute the route nexthop. This is clear.

Thanks & Regards,
Abhinay R



--
~♥~♫AbHiNaY♫~♥~∞