CCIE Study : IGP Summary Default Metric

A lot of confusion arises from the default metric in OSPF when ABR summarizes the routes. Consolidating some documents I found on the internet in a single blogpost.






Accd to the above post, everything (by default) uses lowest IGP metric (of all the component/subordinate routes) except OSPFv3. This is what is the observed behavior on Cisco Routers by default. This is where the confusion arises. RFC 2328 says that OSPF should use the highest metric of all the component routes for the summary route. I found an explanation for this behavior (copied directly from Cisco's website):

 RFC 1583  called for calculating the metric for summary routes based on the minimum       metric of the component paths available.  RFC       2178  (now obsoleted by       RFC 2328 )       changed the specified method for calculating metrics for summary routes so the       component of the summary with the maximum (or largest) cost would determine the       cost of the summary.

Prior to IOS 12.0, Cisco was compliant with the then-current       RFC 1583 . As       of IOS 12.0, Cisco changed the behavior of OSPF to be compliant with the new       standard, RFC       2328 . This situation created the possibility of sub-optimal routing if       all of the ABRs in an area were not upgraded to the new code at the same time.       In order to address this potential problem, a command has been added to the       OSPF configuration of Cisco IOS that allows you to selectively disable       compatibility with RFC 2328 . The new configuration command is under       router ospf, and has the following syntax:

[no] compatible rfc1583 

So, in case of OSPFv2, Cisco follows the older RFC 1583 and not the latest RFC 2328.

CCIE Tricks : OSPF Key-Chain Authentication : OSPFv2 and OSPFv3 AF IPv4

I was studying for my CCIE lab and practising OSPF key-chain authentication. And well there was a time when both the routers exhibited an odd behavior where they were neighbors even when the authentication keys did not match. hmmm .

I configured two routers (Te0/1/0 connected to Te0/1/0 ) with the following configuration :

6RU-L-Standby# interface TenGigabitEthernet0/1/0  ip address 40.0.2.2 255.255.255.0  ip ospf authentication key-chain TEST  ip ospf 1 area 0 key chain TEST key 1    key-string cisco    accept-lifetime 03:10:00 Nov 15 2014 03:23:00 Nov 15 2014    send-lifetime 03:10:07 Nov 15 2014 03:23:00 Nov 15 2014    cryptographic-algorithm hmac-sha-256 key 2    key-string cisco2    accept-lifetime 03:21:00 Nov 15 2014 infinite    send-lifetime 03:21:00 Nov 15 2014 infinite    cryptographic-algorithm hmac-sha-384

6RU_R_ACTIVE# interface TenGigabitEthernet0/1/0  ip address 40.0.2.1 255.255.255.0  ip ospf authentication key-chain TEST  ip ospf 1 area 0 key chain TEST key 1    key-string cisco    accept-lifetime 03:10:00 Nov 15 2014 03:23:00 Nov 15 2014    send-lifetime 03:10:07 Nov 15 2014 03:23:00 Nov 15 2014    cryptographic-algorithm hmac-sha-256 key 2    key-string cisco2    accept-lifetime 03:14:07 Nov 15 2014 infinite    send-lifetime 03:14:07 Nov 15 2014 infinite    cryptographic-algorithm hmac-sha-384

After configuring both the routers (with mismatched key 2 timings), I enabled ‘debug ip ospf adj’ and checked ‘show key chain’ and ‘show ip ospf neighb’ regularly. The console logs showed that during the interval 03:14:07 and 03:21:00 , router 6RU-L-Standby was using KEY 1 and 6RU_R_Active was using key 2, but the adjacency did not drop. 

Here are the console logs for your reference.

6RU_R_ACTIVE#

Nov 15 03:14:36.290: OSPF-1 ADJ   Gi0/1/0: Send with youngest Key 2

6RU_R_ACTIVE#show ip ospf nei

Neighbor ID     Pri   State           Dead Time   Address         Interface

192.168.1.5       1   FULL/DR         00:00:35    101.101.101.102 GigabitEthernet0/1/0

6RU_R_ACTIVE#show ip ospf nei

Neighbor ID     Pri   State           Dead Time   Address         Interface

192.168.1.5       1   FULL/DR         00:00:38    101.101.101.102 GigabitEthernet0/1/0

6RU_R_ACTIVE#

Nov 15 03:14:45.722: OSPF-1 ADJ   Gi0/1/0: Send with youngest Key 2

6RU-L-Standby#

Nov 15 03:14:05.309: OSPF-1 ADJ   Gi0/1/0: Send with youngest Key 1

6RU-L-Standby#

Nov 15 03:14:07.794: %OSPF-5-EXPIREDKEY: Packet received on interface GigabitEthernet0/1/0 with expired Key ID 2.

6RU-L-Standby#show key chain

Key-chain TEST:

    key 1 -- text "cisco"

        accept lifetime (03:10:00 UTC Nov 15 2014) - (03:23:00 UTC Nov 15 2014) [valid now]

        send lifetime (03:10:07 UTC Nov 15 2014) - (03:23:00 UTC Nov 15 2014) [valid now]

    key 2 -- text "cisco2"

        accept lifetime (03:21:00 UTC Nov 15 2014) - (infinite)

        send lifetime (03:21:00 UTC Nov 15 2014) - (infinite)

6RU-L-Standby#show ip ospf nei

Neighbor ID     Pri   State           Dead Time   Address         Interface

192.168.1.1       1   FULL/BDR        00:00:31    101.101.101.101 GigabitEthernet0/1/0

6RU-L-Standby#show ip ospf nei

Neighbor ID     Pri   State           Dead Time   Address         Interface

192.168.1.1       1   FULL/BDR        00:00:35    101.101.101.101 GigabitEthernet0/1/0

Nov 15 03:14:24.809: OSPF-1 ADJ   Gi0/1/0: Send with youngest Key 1

Nov 15 03:15:13.870: %OSPF-5-EXPIREDKEY: Packet received on interface GigabitEthernet0/1/0 with expired Key ID 2.

Well, Good thing about working @ Cisco is : I dropped off a mail to the development engineer and went off to sleep rather than digging it up. I was studying very late night. Here is the reply I got :

The rfc 2328 says

 "Key storage should persist across a system restart, warm or

        cold, to avoid operational issues. In the event that the last

        key associated with an interface expires, it is unacceptable to

        revert to an unauthenticated condition, and not advisable to

        disrupt routing.  Therefore, the router should send a "last

        authentication key expiration" notification to the network

        manager and treat the key as having an infinite lifetime until

        the lifetime is extended, the key is deleted by network

        management, or a new key is configured."

For ospfv3 we don’t have this :)

So, my learning from this is : OSPF neighbors continue to be neighbors even if the keys expire or mismatch.

See the last line  'For OSPFv3 we don't have this :)' .. I removed OSPFv2 config and put OSPFv3 config and configured both the interfaces in OSPFv3 using address-family ipv4. Well, the IPv4 OSPFv3 neighborship went down during that time interval in which the keys did not match.