Subject: Re: Network Mask 0 for Summary Net LSAs

From: John Pecola <[email-masked]>
Date: Thu, 1 Sep 2005 18:08:13 -0700

Acee

Thanks for all the input.

My confusion was because of receiving a bad mask of
0.0.0.0 instead of 255.255.255.0 for network A.B.C.0.
In this case the LSA is installed with LSId A.B.C.0
but the route should be installed as 0.0.0.0/0.
Interestingly, testing this case with two vendors gave
different results. One installed the default route and
the other did not!

Regards
John

Acee Lindem wrote:

> Acee Lindem wrote:
>
>> John Pecola wrote:
>>
>>> Acee,
>>>
>>> If a type 3 LSA with LSId A.B.C.0 is received but
with
>>> the network mask of 0.0.0.0, shouldn't it be
>>> considered a bad prefix-mask combination?
Otherwise, a 0.0.0.0/0 
>>> route will be added corresponding to this LSA.
>>>
>>> Or, is appendix E applicable in this case also?
>>>  
>>>
>> Yes. In fact, there was a gated derivative that
always advertised an 
>> LSID of 255.255.255.255 for default.
>
>
> Actually, I looked at RFC 2328 and there are a
couple places where it 
> explicitly states  that the default destination will
have an LSID of 
> DefaultDestination. Also, I can see some advantage
to NOT allowing a 
> non-zero LSID for default (irrespective of the
version of gated that 
> advertised 255.255.255.255).
>
> From section 12.1.4:
>
>            When an AS-external-LSA (LS Type = 5) is
describing a
>            default route, its Link State ID is set
to
>            DefaultDestination (0.0.0.0).
>
> From section 12.4.3.1:
>
>                In a stub area, instead of importing
external routes
>                each area border router originates a
"default summary-
>                LSA" into the area. The Link State ID
for the default
>                summary-LSA is set to
DefaultDestination, and the metric
>                set to the (per-area) configurable
parameter
>                StubDefaultCost.  Note that
StubDefaultCost need not be
>                configured identically in all of the
stub area's area
>                border routers.
>
>> From section  12.4.4
>
>
>            AS-external-LSAs describe routes to
destinations external to
>            the Autonomous System.  Most
AS-external-LSAs describe
>            routes to specific external destinations;
in these cases the
>            LSA's Link State ID is set to the
destination network's IP
>            address (if necessary, the Link State ID
can also have one
>            or more of the network's "host" bits set;
see Appendix E for
>            details).  However, a default route for
the Autonomous
>            System can be described in an
AS-external-LSA by setting the
>            LSA's Link State ID to DefaultDestination
(0.0.0.0).   
> The main impetus for not allowing it is that one
would not have to
> walk the
> whole summary database for an summary or AS
calculation for default 
> (since
> any LSID could be a valid candidate with one or more
host bits set). 
> Hence,
> it seems to me we would be better off not allowing
this case.

If it isn't apparent, the above argument applies to
incremental SPF 
calculation as
described in sections 16.5 and 16.6 of RFC 2328.

> Acee
>
>>
>> Acee
>>
>>
>>> John
>>>
>>>  
>>>
>>>> Hi
>>>>
>>>> What should ospf do if it receives a type 3
summary
>>>> LSA with a non-zero link-state id but a zero
network
>>>> mask? Should it be considered an invalid LSA or
>>>>   
>>>
>>>
>>> should
>>>  
>>>
>>>> it be stored in the database but not used in
route
>>>>   
>>>
>>>
>>> calculation.
>>>  
>>>
>>>>
>>>>
>>>> Hi John,
>>>>
>>>> OSPF allows the setting of the host bits in type
3
>>>> LSIDs. What makes
>>>>   
>>>
>>>
>>> you think the above is invalid?
>>>  
>>>
>>>> Thanks,
>>>> Acee
>>>>   

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com