Hi, Share the TE topology database for the lab from both routers.
Roman 26.07.2014, 20:53, "Robert Williams" <[email protected]>: > 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: [email protected] > http://www.CustodianDC.com > > _______________________________________________ > cisco-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
