What's the signalled bandwidth being reserved by the headend "R20" in your example? it's a hunch that you may not have that defined and it becomes Zero bandwidth LSPs.
On Fri, Sep 4, 2020 at 9:09 AM <aar...@gvtc.com> wrote: > Thanks Mark, I have a tunnel traversing those interfaces. Customer > routers (r10, r30) can ping end to end via tunnel. > > > > Not sure if I’m missing something here. I wonder if I’m not signaling for > the rsvp bandwidth correctly. I just don’t see any allocated bandwidth in > the rsvp interfaces anywhere. > > > > Here’s one of the transit routers… r24…. Should I see “allocated (bps)” > here ? > > > > RP/0/0/CPU0:r24#sh rsvp int > > Fri Sep 4 10:54:16.451 CST > > > > *: RDM: Default I/F B/W % : 75% [default] (max resv/bc0), 0% [default] > (bc1) > > > > Interface MaxBW (bps) MaxFlow (bps) Allocated (bps) > MaxSub (bps) > > ------------------------- ------------ ------------- -------------------- > ------------- > > GigabitEthernet0/0/0/0 750M* 750M 0 ( > 0%) 0* > > GigabitEthernet0/0/0/1 750M* 750M 0 ( > 0%) 0* > > > > > > Details…. > > > > LSP/TE-tunnel has dynamic path option, but I disallow it to flow via r21… > so tunnel takes the southbound path via r20-24-r25-r23-r22 > > > > (2) unidirectional te-tunnels > > > > r20 is headend and r22 is tailend r20---->r22 > > r22 is headed and r20 is tailend r22---->r20 > > > > > > R10 R30 > > | | > > | | > > r20-----r21-----r22 > > | | > > | | > > | | > > r24-----r25-----r23 > > > > r20’s tunnel… > > > > RP/0/0/CPU0:r20#sh mpls traffic-eng tun br > > Fri Sep 4 10:59:51.509 CST > > > > TUNNEL NAME DESTINATION STATUS STATE > > tunnel-te1 10.20.0.22 up up > > r22--->r20 10.20.0.20 up up > > Displayed 1 (of 1) heads, 0 (of 0) midpoints, 1 (of 1) tails > > Displayed 1 up, 0 down, 0 recovering, 0 recovered heads > > > > RP/0/0/CPU0:r20#sh mpls traffic-eng tun name tunnel-te1 | be count > > Fri Sep 4 10:59:54.309 CST > > Node hop count: 4 > > Hop0: 10.20.1.21 > > Hop1: 10.20.1.18 > > Hop2: 10.20.1.17 > > Hop3: 10.20.1.14 > > Hop4: 10.20.1.13 > > Hop5: 10.20.1.10 > > Hop6: 10.20.1.9 > > Hop7: 10.20.0.22 > > Displayed 1 (of 1) heads, 0 (of 0) midpoints, 0 (of 1) tails > > Displayed 1 up, 0 down, 0 recovering, 0 recovered heads > > > > r22’s tunnel…. > > > > RP/0/0/CPU0:r22#sh mpl tr tun br > > Fri Sep 4 10:25:32.668 CST > > > > TUNNEL NAME DESTINATION STATUS STATE > > tunnel-te1 10.20.0.20 up up > > r20--->r22 10.20.0.22 up up > > Displayed 1 (of 1) heads, 0 (of 0) midpoints, 1 (of 1) tails > > Displayed 1 up, 0 down, 0 recovering, 0 recovered heads > > > RP/0/0/CPU0:r22#sh mpl tr tun name tunnel-te1 | be count > > Fri Sep 4 10:25:35.858 CST > > Node hop count: 4 > > Hop0: 10.20.1.10 > > Hop1: 10.20.1.13 > > Hop2: 10.20.1.14 > > Hop3: 10.20.1.17 > > Hop4: 10.20.1.18 > > Hop5: 10.20.1.21 > > Hop6: 10.20.1.22 > > Hop7: 10.20.0.20 > > Displayed 1 (of 1) heads, 0 (of 0) midpoints, 0 (of 1) tails > > Displayed 1 up, 0 down, 0 recovering, 0 recovered heads > > > > X = router number > > 10.20.0.0/16 > > 10.20.0.X/24 - loopbacks > > 10.20.1.0/24 – /30’s between routers > > (numbered clockwise, lowest to highest, start at r20) > > (r20 is .1 , r21 is .2 , r21 is .5 , etc) > > 10.20.1.0/30 – r20---r21 > > 10.20.1.4/30 – r21---r22 > > 10.20.1.8/30 – r22---r23 > > 10.20.1.12/30 – r23---r25 > > 10.20.1.16/30 – r25---r24 > > 10.20.1.20/30 – r24---r20 > > > > r10#sh ip int br | in up > > GigabitEthernet3 1.0.0.2 YES manual up > up > > > > RP/0/0/CPU0:r30#sh ip int br | in Up > > GigabitEthernet0/0/0/2 1.1.1.2 Up Up > default > > > > r10#trace 1.1.1.2 > > Type escape sequence to abort. > > Tracing the route to 1.1.1.2 > > VRF info: (vrf in name/id, vrf out name/id) > > 1 1.0.0.1 23 msec 5 msec 7 msec > > 2 10.20.1.21 [MPLS: Labels 24000/24010 Exp 0] 43 msec 50 msec 40 msec > > 3 10.20.1.17 [MPLS: Labels 19/24010 Exp 0] 49 msec 42 msec 41 msec > > 4 10.20.1.13 [MPLS: Labels 24001/24010 Exp 0] 42 msec 46 msec 46 msec > > 5 10.20.1.9 42 msec 38 msec 34 msec > > 6 1.1.1.2 55 msec * 44 msec > > > > RP/0/0/CPU0:r30#traceroute 1.0.0.2 > > Fri Sep 4 15:25:10.129 UTC > > > > Type escape sequence to abort. > > Tracing the route to 1.0.0.2 > > > > 1 1.1.1.1 29 msec 0 msec 0 msec > > 2 10.20.1.10 [MPLS: Labels 24000/24009 Exp 0] 49 msec 49 msec 49 msec > > 3 10.20.1.14 [MPLS: Labels 20/24009 Exp 0] 39 msec 49 msec 39 msec > > 4 10.20.1.18 [MPLS: Labels 24001/24009 Exp 0] 49 msec 39 msec 49 msec > > 5 10.20.1.22 49 msec 49 msec 39 msec > > 6 1.0.0.2 69 msec * 49 msec > > RP/0/0/CPU0:r30# > > > > > > > > > > > > *From:* NANOG <nanog-bounces+aaron1=gvtc....@nanog.org> *On Behalf Of *Mark > Tinka > *Sent:* Thursday, September 3, 2020 10:58 PM > *To:* nanog@nanog.org > *Subject:* Re: rsvp-te admission control - i don't see it > > > > > > On 3/Sep/20 22:20, aar...@gvtc.com wrote: > > Thanks, how do I see the control plane reservation? I don’t seem to be > seeing anything getting allocated > > > > RP/0/0/CPU0:r20#sh rsvp interface g0/0/0/1 > > Thu Sep 3 15:15:55.825 CST > > > > *: RDM: Default I/F B/W % : 75% [default] (max resv/bc0), 0% [default] > (bc1) > > > > Interface MaxBW (bps) MaxFlow (bps) Allocated (bps) > MaxSub (bps) > > ------------------------- ------------ ------------- -------------------- > ------------- > > GigabitEthernet0/0/0/1 1M 1M 0 ( > 0%) 0 > > > > RP/0/0/CPU0:r20#sh rsvp interface summary > > Thu Sep 3 15:16:57.131 CST > > > > Interface MaxBW (bps) Allocated (bps) Path In Path Out Resv In > Resv Out > > ------------------ ----------- --------------- ------- -------- ------- > -------- > > Gi0/0/0/0 0 0 ( 0%) 1 0 > 0 1 > > Gi0/0/0/1 1000K 0 ( 0%) 0 1 > 1 0 > > > You will only see allocations once you have TE tunnels (sessions) actually > setup. > > Without tunnels setup, but RSVP-TE enabled on the interfaces, all you will > see the maximum bandwidth that RSVP-TE can allocate across said interfaces. > > Remember that RSVP-TE is purely control plane. So it doesn't matter if you > signal an LSP with 10Mbps or 10Gbps. It will not determine whether a link > (or LSP) will actually pass 10Mbps or 10Gbps worth of traffic. It's just a > reference. > > Back when I used to RSVP-TE, I'd signal 10Gbps links as 10Mbps. That gave > me plenty of granularity to scale up without having an unwieldy > configuration. > > Mark. >
