Dell OS10 OSPF Configuration: Interfaces and Areas - 夜莺博客

Dell OS10 OSPF Configuration: Interfaces and Areas

Dell PowerSwitch OS10 is an interface-based OSPF implementation: instead of a single network statement, you enable OSPF directly on each Layer 3 interface and bind it to a process ID and area. This design maps cleanly to modern leaf-spine fabrics, where spine and leaf switches run OSPF between loopbacks and point-to-point links. In this step-by-step guide you will learn the exact OS10 commands to build an OSPFv2 configuration, how to attach interfaces to areas, what to do when OSPF runs inside a non-default VRF, and which show commands prove the adjacency is healthy.

Background: Why OS10 OSPF Config Looks Different

If you learned OSPF on Cisco IOS, the first surprise is the missing network statement. IOS asks you to declare a range of addresses and a wildcard mask, then matches interfaces into the process automatically. OS10 does the opposite: you walk to the interface, type ip ospf <process-id> area <area-id>, and that interface is now in the process. Interfaces you never touch are never advertised.

That is a better fit for spine-leaf for three reasons:

  • The intent is local. Reading an interface's configuration tells you whether it participates in OSPF and in which area. There is no hidden matching logic to trace.
  • No accidental advertisement. A new management or storage VLAN cannot silently join the routing domain because it happens to fall inside a network range.
  • It maps to automation. Each interface block is self-contained, so a template renders one interface at a time instead of computing wildcard masks for a whole process.

The trade-off is that you must remember to attach every interface you want advertised — including loopbacks, which matter because they carry the router ID and give the fabric a stable address to target.

Prerequisites Before Enabling OSPF

Work through this checklist first; most broken OS10 OSPF configurations fail here rather than in the OSPF process itself.

  • An OSPF-capable OS10 release and a planned process ID. Process IDs are local to the switch (1–65535) and do not have to match the neighbor — but choose one convention and keep it, because interfaces reference the process ID when OSPF is attached.
  • Layer 3 interfaces. OS10 ports are switchports by default. A port must be converted with no switchport, or be a VLAN interface or loopback, before it can hold an IP address or an OSPF attachment.
  • Interface addressing. Point-to-point fabric links are normally /30 or /31. Both sides must agree on the subnet.
  • A loopback for the router ID. Create it, address it /32, and attach it to the same process and area. Then set router-id explicitly so the ID never depends on which interface came up first.
  • An area plan. Every interface goes into an area or it is not advertised. In a leaf-spine fabric, area 0 everywhere is the common choice; use additional areas only when you have a deliberate reason and an ABR to connect them.
  • Unused ports. Interfaces facing servers or storage should be ip ospf passive or simply never attached to OSPF.

OS10 OSPF Basics: Process, Area, Interface

Every OSPFv2 instance in OS10 is identified by a process ID (1-65535). Interfaces are attached to the process with ip ospf <process-id> area <area-id>, where the area can be given in dotted-decimal (0.0.0.0) or numeric form. There is no OSPF network command - an interface is only advertised if OSPF is explicitly enabled on it.

Three levels are worth keeping straight:

  • Process — router ospf 1: the routing instance that owns the RIB, the LSDB and the router ID.
  • Area — the scope in which LSAs are flooded. A switch with interfaces in two areas is an ABR.
  • Interface — where hello packets are actually sent and where timers, cost and authentication live.

Step-by-Step OSPF Configuration on OS10

Start in configuration mode, disable the default L2 switchport behavior, assign an IP, and attach the interface to the OSPF process and area:

OS10(config)# interface ethernet 1/1/1
OS10(conf-if-eth1/1/1)# no shutdown
OS10(conf-if-eth1/1/1)# no switchport
OS10(conf-if-eth1/1/1)# ip address 10.0.0.1/30
OS10(conf-if-eth1/1/1)# ip ospf 1 area 0
OS10(conf-if-eth1/1/1)# exit

Then create the OSPF process and give it a stable router ID, and add any loopback used as the router ID source:

OS10(config)# router ospf 1
OS10(conf-router-ospf-1)# router-id 1.1.1.1
OS10(conf-router-ospf-1)# exit
OS10(config)# interface loopback 0
OS10(conf-if-lo-0)# ip address 1.1.1.1/32
OS10(conf-if-lo-0)# ip ospf 1 area 0

VLAN interfaces work the same way - enable OSPF on the SVI with ip ospf in the interface VLAN configuration mode:

OS10(conf-if-vl-10)# ip ospf 10 area 5

A complete point-to-point fabric link, with the knobs that actually matter in production, looks like this:

OS10(config)# interface ethernet 1/1/1
OS10(conf-if-eth1/1/1)# no switchport
OS10(conf-if-eth1/1/1)# ip address 10.0.0.1/31
OS10(conf-if-eth1/1/1)# ip ospf 1 area 0
OS10(conf-if-eth1/1/1)# ip ospf network point-to-point
OS10(conf-if-eth1/1/1)# ip ospf cost 10
OS10(conf-if-eth1/1/1)# ip ospf hello-interval 3
OS10(conf-if-eth1/1/1)# ip ospf dead-interval 9
OS10(conf-if-eth1/1/1)# no shutdown
OS10(conf-if-eth1/1/1)# exit

OS10(config)# router ospf 1
OS10(conf-router-ospf-1)# router-id 1.1.1.1
OS10(conf-router-ospf-1)# redistribute connected
OS10(conf-router-ospf-1)# default-information originate
OS10(conf-router-ospf-1)# exit

Notes on the parameters above:

  • ip ospf network point-to-point skips DR/BDR election on a link that will never have a third speaker. On a /31 link it is effectively mandatory, and it speeds up adjacency formation.
  • ip ospf cost is the tiebreaker in a leaf-spine fabric where every link is the same speed. If you want traffic to prefer one spine for a given prefix, this is where you express it.
  • Hello and dead timers must match on both ends. 3/9 gives a sub-second failure detection floor without going to BFD; the default is 10/40.
  • Redistribution is explicit. Connected networks, static routes and BGP prefixes do not leak into OSPF unless you say so — and default-information originate is only meaningful if a default route exists in the RIB.
  • Save the configuration with copy running-configuration startup-configuration; OS10 uses the full word, not the IOS write memory shortcut.

Areas, ABRs and Summarisation

An interface that is attached to area 5 while another interface sits in area 0 makes the switch an ABR. In a small fabric, put everything in area 0 and stop there. When you do split areas, summarise at the boundary so the backbone does not carry every leaf prefix:

OS10(config)# router ospf 1
OS10(conf-router-ospf-1)# area 5 range 10.10.0.0/16
OS10(conf-router-ospf-1)# delay 100

Use the same area plan for every device of a given role. The most common OS10 OSPF error is not a syntax mistake but a design drift: one leaf configured for area 0.0.0.0 while its neighbour expects area 5, which produces neighbours stuck in EXSTART rather than an obvious error message.

Running OSPF in a Non-Default VRF

OS10 supports OSPFv2 inside a VRF instance. Create the VRF, start the OSPF process bound to that VRF, and associate the interface with the VRF before enabling OSPF on it:

OS10(config)# ip vrf vrf-blue
OS10(config-vrf-blue)# router ospf 100 vrf vrf-blue
OS10(config)# interface ethernet 1/1/2
OS10(conf-if-eth1/1/2)# no switchport
OS10(conf-if-eth1/1/2)# ip vrf forwarding vrf-blue
OS10(conf-if-eth1/1/2)# ip address 11.1.1.1/24
OS10(conf-if-eth1/1/2)# ip ospf 100 area 0.0.0.0

If you move an interface between VRFs, remove its existing Layer 3 and OSPF configuration first - otherwise those settings silently do not take effect in the new VRF.

Two further VRF rules are worth remembering:

  • The process ID is scoped to the switch, so the same ID can be reused in different VRFs, and neighbours in different VRFs never form adjacencies even when they share a subnet.
  • Verify per-VRF state with the VRF-qualified form of the show commands: show ip ospf vrf vrf-blue and show ip ospf neighbor vrf vrf-blue. Reading the default VRF table when the process lives in vrf-blue is the second most common cause of "OSPF is not running" tickets.

Verifying the OSPF Neighbor and Routes

OS10# show ip ospf
OS10# show ip ospf neighbor
OS10# show ip ospf interface
OS10# show ip route ospf

The neighbor table should show a FULL state on point-to-point links and the OSPF routes should appear in the routing table before you check end-to-end reachability with ping.

A fuller verification pass, in the order you should run it:

OS10# show ip ospf interface ethernet 1/1/1
! area, network type, cost, timers, state
OS10# show ip ospf neighbor
! expected: FULL/ - on a point-to-point link
OS10# show ip ospf database
! self-originated LSAs present for every attached interface
OS10# show ip route ospf
! remote loopbacks and fabric links installed via O
OS10# show ip ospf vrf vrf-blue
! per-VRF process state when VRFs are in use
OS10# show running-configuration
! confirm the interface attachments survived the save

What healthy output looks like on a point-to-point link: the neighbour shows address 10.0.0.2, state FULL/ -, and the interface state is P2P with the configured cost. On a broadcast segment you will instead see a DR and a BDR and neighbours in 2WAY/DROTHER, which is normal.

Finish with reachability between loopbacks, because that is what the rest of the fabric will use as a destination:

OS10# ping 2.2.2.2 source 1.1.1.1

Troubleshooting OS10 OSPF

  • No neighbours at all. The interface is still a switchport (no switchport missing), has no IP address, is administratively down, or OSPF was never attached with ip ospf. Check show ip ospf interface first — an empty output means the interface is not in the process.
  • Stuck in EXSTART or EXCHANGE. Almost always an MTU mismatch on the link, or a duplicate router ID. Confirm both with show ip ospf interface and the neighbour table.
  • Neighbour flaps. Timers do not match (one side customised hello/dead), the link is erroring, or a VLT pair has a duplicate router ID because the same loopback address was assigned on both peers.
  • Adjacency up, routes missing. The area numbers differ, the network was filtered by an area range, or the prefix is being received but losing the best-path comparison. Check show ip ospf database before blaming the RIB.
  • Only the wrong VRF shows anything. The interface was not moved with ip vrf forwarding, or the configuration from the previous VRF was never removed.
  • Configuration lost after reload. OS10 does not autosave — run copy running-configuration startup-configuration.
  • Slow convergence after a link failure. Tune hello/dead timers on the fabric links, and keep the number of OSPF neighbours per switch within the platform's supported scale.

FAQ

Does OS10 OSPF need a global routing enable command? No. Once an interface is Layer 3 (no switchport with an IP address), it forwards and participates; unlike IOS there is no separate ip routing switch to remember.

Do process IDs need to match between neighbours? No. The process ID is locally significant; the area ID must match, and the OSPF settings on the interface (timers, network type, area) must match.

Can I advertise a prefix I do not want to attach an interface to? Redistribute it from connected or static routes inside the OSPF process rather than relying on a network statement, which OS10 does not have.

How does OSPF interact with VLT? VLT makes two switches look like one L2 device; OSPF still runs independently on each peer unless you configure VLT peer routing, so give each peer its own loopback and router ID.

Where are OSPF logs? In the OS10 log: show logging log-file filtered for the OSPF process — useful for adjacency flaps that are already gone by the time you look at the neighbour table.

Related articles on this site: OSPF area types: stub and NSSA explained, Dell OS10 basic switch management configuration, and Dell OS10 port channel and LACP configuration. For the OS10 routing counterpart see Dell OS10 BGP configuration, for a closer look at area types see OSPF stub and NSSA configuration, and for the Layer 3 redundancy model above OSPF see Dell OS10 VLT peer routing.

原文链接:https://www.dell.com/support/manuals/en-us/smartfabric-os10/smartfabric-os-user-guide-10-5-0/enable-ospfv2-in-a-non-default-vrf-instance