[c-nsp] explicit-path fails only when ospf is non-broadcast

[Robert Williams]

Hi all,

I have a requirement to convert a few ospf links to use "ip ospf network non-broadcast". When I do this the ospf session re-establishes fine and all basic xconnects continue to work fine. However, those which are in mpls-te tunnels all go down. The tunnel interface goes down due to an explicit path failure.

I have replicated this in the lab with 2x6500/sup-720 directly connected. I have configured Tunnel145 in one direction from RTR-21 -> RTR-23. The reverse path is just a basic xconnect.

The debug from the failed TE tunnel (145) is:

: TE-SIG-HE: Tunnel145 [0]: Attempting to activate
: TE-PCALC-API: 10.10.10.21_90->10.10.10.23_145 {7}: P2P LSP Path Lookup called
: TE-PCALC: 10.10.10.21_90->10.10.10.23_145 {7}: Path Request Info
:   Flags:  IP_EXPLICIT_PATH  METRIC_TE
:   IP explicit-path: Supplied
:     10.10.103.23
:   bw 0, min_bw 0, metric: 0
:   setup_pri 1, hold_pri 1
:   affinity_bits 0x0, affinity_mask 0xFFFF
: TE-PCALC-PATH: 10.10.10.21_90->10.10.10.23_145 {7}: Area (ospf 1  area 0) Path Lookup begin
: TE-PCALC-PATH: create_path_hoplist: No addresses to connect 10.10.10.21 to 10.10.103.23
: TE-PCALC-PATH: 10.10.10.21_90->10.10.10.23_145 {7}: Area (ospf 1  area 0) Path Lookup end: path not found
: TE-PCALC-API: 10.10.10.21_90->10.10.10.23_145 {7}: P2P LSP Path Lookup result: failed
: TE-SIG-HE: Tunnel145: Activation failed, reason: Explicit path rejected by topology database

The lab topology is simple:

[RTR-21] (gi4/48) <-> (gi3/5) [RTR-23]

Configurations as follows:

[RTR-21]
interface Loopback1
 ip address 10.10.10.21 255.255.255.255

interface Vlan103
 description Facing RTR-23
 dampening
 mtu 9188
 ip address 10.10.103.21 255.255.255.0
 no ip proxy-arp
 ip ospf network non-broadcast
 ip ospf 1 area 0
 mpls traffic-eng tunnels
 mpls ip
 arp timeout 300
end

ip explicit-path name path-via-145-only enable
 next-address 10.10.103.23

interface Tunnel145
 ip unnumbered Loopback1
 mpls traffic-eng tunnels
 tunnel mode mpls traffic-eng
 tunnel destination 10.10.10.23
 tunnel mpls traffic-eng priority 1 1
 tunnel mpls traffic-eng path-option 1 explicit name path-via-145-only
 no routing dynamic

pseudowire-class class-via-145
 encapsulation mpls
 preferred-path interface Tunnel145

interface GigabitEthernet4/48
 xconnect 10.10.10.23 501 pw-class class-via-145


[RTR-23]
interface Loopback1
 ip address 10.10.10.23 255.255.255.255

interface Vlan103
 description Facing RTR-21
 dampening
 mtu 9188
 ip address 10.10.103.23 255.255.255.0
 no ip proxy-arp
 ip ospf network non-broadcast
 ip ospf 1 area 0
 mpls traffic-eng tunnels
 mpls ip
 arp timeout 300
end

interface GigabitEthernet3/5
 xconnect 10.10.10.21 501 encapsulation mpls


[OSPF and MPLS config on both routers] (where x = 1 or 3)
router ospf 1
 router-id 10.10.10.2x
 ispf
 log-adjacency-changes detail
 ttl-security all-interfaces
 timers throttle spf 10 100 3000
 timers throttle lsa 10 100 3000
 timers lsa arrival 50
 timers pacing flood 5
 timers pacing retransmission 60
 redistribute maximum-prefix 100
 redistribute connected subnets
 passive-interface Loopback1
 network 10.10.10.0 0.0.0.255 area 0
 neighbor 10.10.103.2x poll-interval 1
 mpls traffic-eng router-id Loopback1
 mpls traffic-eng area 0

mpls label protocol ldp
mpls ldp graceful-restart
mpls ldp tcp pak-priority
no mpls ldp advertise-labels
mpls ldp advertise-labels for LDP
mpls traffic-eng tunnels
mpls traffic-eng reoptimize events link-up
ip rsvp signalling refresh reduction
ip rsvp signalling hello graceful-restart mode full

ip access-list standard LDP
 permit 10.10.0.0 0.0.255.255


[Summary]
If I change the vlan 103 interface from "ip ospf network non-broadcast" back to "ip ospf network point-to-point" then the tunnel comes back up and so do the VCs.
So to confirm, everything is 100% until I change the network type to non-broadcast.

I found this bug but it was fixed a while ago: https://tools.cisco.com/bugsearch/bug/CSCsh42565 - unless it has re-surfaced in 15.1(2)SY2 which is what we have.

So - any ideas or suggestions anyone. I've collected a load of debugging info but it's hard to know what is relevant so let me know what you need to see.

Any input welcome, I really do hope I'm just missing something stupid!

Cheers,


Robert Williams
Custodian Data Centre
Email: Robert at CustodianDC.com
http://www.CustodianDC.com