Junos OS

Hey Guys,

I was working on an issue today with some guys from our Cisco support team at work that have taken the stance to configure OSPF interfaces as point-to-point for all /30 Ethernet links when forming OSPF adjacencies.  I ran into an issue with this because I had my side configured as a traditional broadcast interface since everything I have ever read speaks to point-to-point only in Frame/ATM scenarios, not Ethernet (broadcast mediums).

Since I am going to be forming some OSPF adjacencies with these guys on my SRX 3400's I was wondering if anyone can comment on this practice?  I have been actively reading the new JUNOS for HA book that recently came out and there is no mention of this practice to minimize downtime, which was the reason I was given as to why they do this. 

After googling for all sorts of views on the matter the best I can see is that the lack of DR/BDR election allows the adjacency to form "quicker" so to speak, however I am not sure if there are any unforeseen issues with a multivendor implementation of this between IOS and JUNOS, I would expect as long as I setup the SRX's with a p2p interface it should work.

I am going to end up simply testing this myself one way or another to determine if this works, however I am really looking for user experiences and best practices around this type of configuration, is it really worth the extra line of config for the savings in election time between the neighbouring routers?  Anyone else follow this practice?

Since I am trying to maintain as many 9's as possible with full mesh and graceful restart I am not sure if this extra step is really worth it or not.

Thanks in advance for any insight you can provide

hi Jerrad_D,

I'm not aware of (and do not expect) any interoperability problem with Juniper-Cisco OSPF p2p Ethernet links. It's quite common practice in some network I build. Why ?

• as you mentioned, there is no DR/BDR election, no need for 40 seconds Wait phase (EXSTART to EXCHANGE) if there was no DR/BDR on the segment
• with OSPF p2p topology, there is no DR/BDR and thus no Type 3 LSA describing the multi-access segment 

Hi,

I think this thread can be an appropriate context for a post about the issue we just ran into.

There are router vendors implementing OSPF so that the netmask is set to 0.0.0.0 in Hello on a point-to-point interface.  Our example is Vyatta, apparently running Quagga as its OSPF process, so all Quaggas out there might be affected.

In its turn, JunOS (11.2 in our case) still tries to validate the Hello netmask if the interface is Ethernet notwithstanding its p2p mode in OSPF.  By the way, this is against the behavior RECOMMENDED by Section 10.5 of RFC 2328 that "on point-to-point networks and on virtual links, the Network Mask in the received Hello Packet should be ignored."

The end result is that adjacency fails to establish due to netmask mismatch in JunOS, e.g.:

Feb  8 22:39:17.458702 OSPF rcvd Hello 10.7.8.6 -> 224.0.0.5 (reth0.1 IFL 142 area 0.0.0.0)
Feb  8 22:39:17.458739   Version 2, length 48, ID 10.1.200.1, area 0.0.0.0
Feb  8 22:39:17.458768   checksum 0x0, authtype 0
Feb  8 22:39:17.458799   mask 0.0.0.0, hello_ivl 10, opts 0x2, prio 1
Feb  8 22:39:17.458828   dead_ivl 40, DR 0.0.0.0, BDR 0.0.0.0
Feb  8 22:39:17.458856   neighbor 10.1.252.1
Feb  8 22:39:17.458893 OSPF packet ignored: netmask 0.0.0.0 mismatch from 10.7.8.6 on intf reth0.1 area 0.0.0.0

The workaround is just to fall back to broadcast mode on OSPF links backed by broadcast physical interfaces.

(No such problem on true p2p links such as VPN tunnels.)

Hoping this will save some of you some troubleshooting time some day!

Thanks!

Very intersting! I wish we could have seen a detailed trace log of this exchange and dig into it, along with the ospf configurations for both devices. I had to do a quick test (on my lower end devices that I have access to). But could not replicate it. Maybe oneday, if you get a chance you can post the config so someone could try ad reproduce the error. Juniper probably would find it useful. It could a "new or unknown" feature of the software:)

I'm confirming this behavior of JunOS and Quagga.

JunOS 10.4R9.2 at MX240

Quagga-re-0.99.17.6 on FreeBSD 9.0-STABLE

That's what I see on Quagga's interface:

# tshark -V -i em0 -f 'proto ospf' -O ospf
Capturing on em0
Frame 1: 78 bytes on wire (624 bits), 78 bytes captured (624 bits)
Ethernet II, Src: JuniperN_11:87:19 (80:71:1f:11:87:19), Dst: IPv4mcast_00:00:05 (01:00:5e:00:00:05)
Internet Protocol Version 4, Src: 10.78.76.237 (10.78.76.237), Dst: 224.0.0.5 (224.0.0.5)
Open Shortest Path First
    OSPF Header
        OSPF Version: 2
        Message Type: Hello Packet (1)
        Packet Length: 44
        Source OSPF Router: 10.78.76.233 (10.78.76.233)
        Area ID: 10.78.77.0
        Packet Checksum: 0x4624 [correct]
        Auth Type: Null
        Auth Data (none)
    OSPF Hello Packet
        Network Mask: 255.255.255.252
        Hello Interval: 10 seconds
        Options: 0x08 (NP)
            0... .... = DN: DN-bit is NOT set
            .0.. .... = O: O-bit is NOT set
            ..0. .... = DC: Demand Circuits are NOT supported
            ...0 .... = L: The packet does NOT contain LLS data block
            .... 1... = NP: NSSA is supported
            .... .0.. = MC: NOT Multicast Capable
            .... ..0. = E: NO External Routing Capability
            .... ...0 = MT: NO Multi-Topology Routing
        Router Priority: 250
        Router Dead Interval: 40 seconds
        Designated Router: 0.0.0.0
        Backup Designated Router: 0.0.0.0

Frame 2: 82 bytes on wire (656 bits), 82 bytes captured (656 bits)
Ethernet II, Src: Supermic_63:da:c6 (00:30:48:63:da:c6), Dst: IPv4mcast_00:00:05 (01:00:5e:00:00:05)
Internet Protocol Version 4, Src: 10.78.76.238 (10.78.76.238), Dst: 224.0.0.5 (224.0.0.5)
Open Shortest Path First
    OSPF Header
        OSPF Version: 2
        Message Type: Hello Packet (1)
        Packet Length: 48
        Source OSPF Router: 10.78.76.238 (10.78.76.238)
        Area ID: 10.78.77.0
        Packet Checksum: 0xefd9 [correct]
        Auth Type: Null
        Auth Data (none)
    OSPF Hello Packet
        Network Mask: 0.0.0.0
        Hello Interval: 10 seconds
        Options: 0x08 (NP)
            0... .... = DN: DN-bit is NOT set
            .0.. .... = O: O-bit is NOT set
            ..0. .... = DC: Demand Circuits are NOT supported
            ...0 .... = L: The packet does NOT contain LLS data block
            .... 1... = NP: NSSA is supported
            .... .0.. = MC: NOT Multicast Capable
            .... ..0. = E: NO External Routing Capability
            .... ...0 = MT: NO Multi-Topology Routing
        Router Priority: 1
        Router Dead Interval: 40 seconds
        Designated Router: 0.0.0.0
        Backup Designated Router: 0.0.0.0
        Active Neighbor: 10.78.76.233

And so neighbors are stuck on INIT state:

quagga-re# show ip ospf
 OSPF Routing Process, Router ID: 10.78.76.238
 Supports only single TOS (TOS0) routes
 This implementation conforms to RFC2328
 RFC1583Compatibility flag is enabled
 Initial SPF scheduling delay 200 millisec(s)
 Minimum hold time between consecutive SPFs 1000 millisec(s)
 Maximum hold time between consecutive SPFs 10000 millisec(s)
 Hold time multiplier is currently 1
 SPF algorithm last executed 5m28s ago
 SPF timer is inactive
 Refresh timer 10 secs
 This router is an ASBR (injecting external routing information)
 Number of external LSA 270. Checksum Sum 0x008602fd
 Number of areas attached to this router: 1
 Adjacency changes are logged

 Area ID: 10.78.77.0 (NSSA, no summary)
   Shortcutting mode: Default, S-bit consensus: ok
   Number of interfaces in this area: Total: 1, Active: 1
   It is an NSSA configuration.
   Elected NSSA/ABR performs type-7/type-5 LSA translation.
   It is not ABR, therefore not Translator.
   Number of fully adjacent neighbors in this area: 0
   Area has no authentication
   Number of full virtual adjacencies going through this area: 0
   SPF algorithm executed 372 times
   Number of LSA 291
   Number of router LSA 17. Checksum Sum 0x000a0cd7
   Number of network LSA 2. Checksum Sum 0x0000b721
   Number of summary LSA 0. Checksum Sum 0x00000000
   Number of ASBR summary LSA 0. Checksum Sum 0x00000000
   Number of NSSA LSA 272. Checksum Sum 0x008c9ed8

quagga-re# show ip ospf neighbor detail
  Neighbor 10.78.76.233, interface address 10.78.76.237
    In the area 10.78.77.0 [NSSA] via interface em0
    Neighbor priority is 250, State is Init, 6 state changes
    Most recent state change statistics:
      Progressive change 12m10s ago
      Regressive change 11m41s ago, due to 1-WayReceived
    DR is 0.0.0.0, BDR is 0.0.0.0
    Options 72 *|O|-|-|N/P|-|-|*
    Dead timer due in 34.193s
    Database Summary List 0
    Link State Request List 0
    Link State Retransmission List 0
    Thread Inactivity Timer on
    Thread Database Description Retransmision off
    Thread Link State Request Retransmission off
    Thread Link State Update Retransmission off

quagga-re# show ip ospf neighbor 
     Neighbor ID Pri State           Dead Time Address         Interface            RXmtL RqstL DBsmL
10.78.76.233    250 Init/DROther      33.963s 10.78.76.237    em0:10.78.76.238         0     0     0 

Definitly a bug!

Does anybody know, how to submit bug report? We doesn't have support for our Juniper equipment.

I can confirm this is expected Junos behavior.  There are subnet checks on Ethernet interfaces, operating in p2p mode, if they are non /32 mask (i.e. subnetted).  This behavior has not changed since the feature was added.

It could be argued that operating in P2P mode, on a broadcast medium, where subnet masks exist (i.e. potential for multiple hosts on the lan) is already outside the scope of the RFC/STD. The network mask exception in RFC2328 (Section 10.5) might have been intended for "real" point-to-point network interface types, where there is no chance of a mismatch.

I don't understand, why Juniper call it "feature" and trying to check network mask even when RFC, actually, doesn't required it. Moreover, it, as you see, incorrectly works (or even not works) in multivendor networks.

So I'm do still thinking that it's a really annoiyng bug.

At least it's documented now: http://kb.juniper.net/InfoCenter/index?page=content&id=KB23533