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

Robert Williams Robert at CustodianDC.com
Sat Jul 26 14:35:10 EDT 2014


Hi,

Sure no problem, here we go:

[RTR-21]

rtr-8-21#sh mpls traffic-eng topology br
My_System_id: 10.10.10.21 (ospf 1  area 0)

Signalling error holddown: 10 sec Global Link Generation 58

IGP Id: 10.10.10.21, MPLS TE Id:10.10.10.21 Router Node  (ospf 1  area 0)
      link[0]: Nonbroadcast Multiaccess, Nbr IGP Id: 10.10.103.23, nbr_node_id:17, gen:57
          frag_id 66, Intf Address:10.10.103.21
          TE metric:1, IGP metric:1, attribute flags:0x0
          SRLGs: None

IGP Id: 10.10.10.23, MPLS TE Id:10.10.10.23 Router Node  (ospf 1  area 0)
      link[0]: Nonbroadcast Multiaccess, Nbr IGP Id: 10.10.103.23, nbr_node_id:17, gen:56
          frag_id 66, Intf Address:10.10.103.23
          TE metric:1, IGP metric:1, attribute flags:0x0
          SRLGs: None

IGP Id: 10.10.10.25, MPLS TE Id:10.10.10.25 Router Node  (ospf 1  area 0)
      link[0]: Broadcast, DR: 10.10.104.25, nbr_node_id:14, gen:47
          frag_id 10, Intf Address:10.10.104.25
          TE metric:1, IGP metric:1, attribute flags:0x0
          SRLGs: None

      link[1]: Broadcast, DR: 10.10.105.25, nbr_node_id:-1, gen:47
          frag_id 11, Intf Address:10.10.105.25
          TE metric:1, IGP metric:1, attribute flags:0x0
          SRLGs: None

IGP Id: 10.10.103.23, Network Node  (ospf 1  area 0)
      link[0]: Broadcast, Nbr IGP Id: 10.10.10.23, nbr_node_id:15, gen:58

      link[1]: Broadcast, Nbr IGP Id: 10.10.10.21, nbr_node_id:18, gen:58

IGP Id: 10.10.104.25, Network Node  (ospf 1  area 0)
      link[0]: Broadcast, Nbr IGP Id: 10.10.10.25, nbr_node_id:16, gen:45

      link[1]: Broadcast, Nbr IGP Id: 10.10.10.23, nbr_node_id:-1, gen:45


[RTR-23]

rtr-8-23#sh mpls traffic-eng topology br
My_System_id: 10.10.10.23 (ospf 1  area 0)

Signalling error holddown: 10 sec Global Link Generation 87

IGP Id: 10.10.10.21, MPLS TE Id:10.10.10.21 Router Node  (ospf 1  area 0)
      link[0]: Nonbroadcast Multiaccess, Nbr IGP Id: 10.10.103.23, nbr_node_id:19, gen:86
          frag_id 66, Intf Address:10.10.103.21
          TE metric:1, IGP metric:1, attribute flags:0x0
          SRLGs: None

IGP Id: 10.10.10.23, MPLS TE Id:10.10.10.23 Router Node  (ospf 1  area 0)
      link[0]: Nonbroadcast Multiaccess, Nbr IGP Id: 10.10.103.23, nbr_node_id:19, gen:84
          frag_id 66, Intf Address:10.10.103.23
          TE metric:1, IGP metric:1, attribute flags:0x0
          SRLGs: None

IGP Id: 10.10.10.25, MPLS TE Id:10.10.10.25 Router Node  (ospf 1  area 0)
      link[0]: Broadcast, DR: 10.10.104.25, nbr_node_id:3, gen:73
          frag_id 10, Intf Address:10.10.104.25
          TE metric:1, IGP metric:1, attribute flags:0x0
          SRLGs: None

      link[1]: Broadcast, DR: 10.10.105.25, nbr_node_id:-1, gen:73
          frag_id 11, Intf Address:10.10.105.25
          TE metric:1, IGP metric:1, attribute flags:0x0
          SRLGs: None

IGP Id: 10.10.103.23, Network Node  (ospf 1  area 0)
      link[0]: Broadcast, Nbr IGP Id: 10.10.10.23, nbr_node_id:17, gen:87

      link[1]: Broadcast, Nbr IGP Id: 10.10.10.21, nbr_node_id:18, gen:87

IGP Id: 10.10.104.25, Network Node  (ospf 1  area 0)
      link[0]: Broadcast, Nbr IGP Id: 10.10.10.25, nbr_node_id:2, gen:69

      link[1]: Broadcast, Nbr IGP Id: 10.10.10.23, nbr_node_id:-1, gen:69


(It shows another lab box (.25) but that is not part of this issue or test)


I 'think' that's the one you are after, if not please let me know!

Best wishes & thanks,



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

-----Original Message-----
From: cisco-nsp [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of junior
Sent: 26 July 2014 18:28
To: 'cisco-nsp at puck.nether.net'
Subject: Re: [c-nsp] explicit-path fails only when ospf is non-broadcast

Hi,

Share the TE topology database for the lab from both routers.

Roman

26.07.2014, 20:53, "Robert Williams" <Robert at CustodianDC.com>:
> 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
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/



More information about the cisco-nsp mailing list