04-19-2010 08:23 PM - edited 04-19-2010 08:23 PM
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
04-20-2010 03:20 AM
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
02-08-2012 05:13 PM
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 -> 220.127.116.11 (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!
02-14-2012 12:32 PM
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
If this solution worked for you please flag my post as an "Accepted Solution" so others can benefit..]
03-07-2012 03:43 AM - edited 03-07-2012 03:52 AM
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: 18.104.22.168 (22.214.171.124) 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: 126.96.36.199 (188.8.131.52) 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!
03-23-2012 03:52 PM
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.
04-05-2012 02:33 AM - edited 04-05-2012 02:34 AM
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.
05-11-2012 08:07 AM
At least it's documented now: http://kb.juniper.net/InfoCenter/index?page=conten