Thursday, December 4, 2014

OSPFv2 Demand Circuit

I recently wrote a post on Paranoid Updates in OSPFv2, which is kind of a "lite" version of the Demand Circuit feature. The topology used in the aforementioned post is reused for this example as well and is pictured below.
OSPFv2 Two Node Topology
The previously mentioned post describes how to reduce LSA reflooding, which will reduce the OSPF control traffic, but not significantly. Reducing the half-hour reflooding of LSAs will not do much on a line with a traffic cap (3G/4G links for example) or maybe a pay-per-use type of line. We may have a 3G uplink for backup purposes and running OSPF over such a link will make it send data constantly with the Hello packets to keep the adjacencies alive. Here is where the demand circuit feature comes into play. The demand circuit is an extension of OSPF and is described in RFC 1793. So, not all devices may support this feature and therefore if only one neighbor supports the feature the benefits will not be seen from configuring it.

This feature, when enabled, will pause all OSPF communication for as long as the network is stable. This includes the paranoid updates as well as Hello packets. The adjacency will form initially and enter a stable state - after which the neighbors stay mute until a change occurs.

This is how to turn it on and verify the configuration.

R1(config)interface gigabitethernet1.255
R1(config-subif)#ip ospf demand-circuit

R1#sh ip ospf int gi1.255
GigabitEthernet1.255 is up, line protocol is up
  Internet Address 130.1.255.1/24, Area 0, Attached via Network Statement
  Process ID 1, Router ID 1.1.1.1, Network Type POINT_TO_POINT, Cost: 1
  Topology-MTID    Cost    Disabled    Shutdown      Topology Name
        0           1         no          no            Base
  Configured as demand circuit
  Run as demand circuit
  DoNotAge LSA allowed
  Transmit Delay is 1 sec, State POINT_TO_POINT
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    oob-resync timeout 40
    Hello due in 00:00:02
  Supports Link-local Signaling (LLS)
  Cisco NSF helper support enabled
  IETF NSF helper support enabled
  Can be protected by per-prefix Loop-Free FastReroute
  Can be used for per-prefix Loop-Free FastReroute repair paths
  Index 1/1, flood queue length 0
  Next 0x0(0)/0x0(0)
  Last flood scan length is 1, maximum is 1
  Last flood scan time is 0 msec, maximum is 1 msec
  Neighbor Count is 1, Adjacent neighbor count is 1
    Adjacent with neighbor 2.2.2.2  (Hello suppressed)
  Suppress hello for 1 neighbor(s)

Note that the command is only needed on one end as the feature will be negotiated with the neighboring router (unless negotiation is disabled). So, the output below is from router R2.

R2#sh run int gigabitethernet1.255
Building configuration...

Current configuration : 133 bytes
!
interface GigabitEthernet1.255
 encapsulation dot1Q 255
 ip address 130.1.255.2 255.255.255.0
 ip ospf network point-to-point
end

R2#sh ip ospf interface gigabitethernet1.255
GigabitEthernet1.255 is up, line protocol is up
  Internet Address 130.1.255.2/24, Area 0, Attached via Network Statement
  Process ID 1, Router ID 2.2.2.2, Network Type POINT_TO_POINT, Cost: 1
  Topology-MTID    Cost    Disabled    Shutdown      Topology Name
        0           1         no          no            Base
  Run as demand circuit
  DoNotAge LSA allowed
  Transmit Delay is 1 sec, State POINT_TO_POINT
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    oob-resync timeout 40
    Hello due in 00:00:02
  Supports Link-local Signaling (LLS)
  Cisco NSF helper support enabled
  IETF NSF helper support enabled
  Can be protected by per-prefix Loop-Free FastReroute
  Can be used for per-prefix Loop-Free FastReroute repair paths
  Index 1/1, flood queue length 0
  Next 0x0(0)/0x0(0)
  Last flood scan length is 1, maximum is 2
  Last flood scan time is 0 msec, maximum is 0 msec
  Neighbor Count is 1, Adjacent neighbor count is 1
    Adjacent with neighbor 1.1.1.1  (Hello suppressed)
  Suppress hello for 1 neighbor(s)

Notice that the ip ospf demand-circuit command is not entered under router R2's interface, but it is still running as a demand circuit because it is negotiated with router R1.

No comments:

Post a Comment