Re: rsvp-te admission control - i don't see it

[dip <diptanshu.singh () gmail com>]

can you try this
https://www.cisco.com/c/en/us/td/docs/ios_xr_sw/iosxr_r3-7/mpls/command/reference/gr37mpte.html#wp2134470


On Fri, Sep 4, 2020 at 10:26 AM <aaron1 () gvtc com> wrote:

> Thanks dip, let me know what you think.
>
> r20 is headend and r22 is tailend   r20---->r22
>
> r22 is headed and r20 is tailend      r22---->r20
>
> RP/0/0/CPU0:r20#sh run int tt1
>
> Fri Sep  4 12:25:09.198 CST
>
> interface tunnel-te1
>
> bandwidth 200000
>
> ipv4 unnumbered Loopback0
>
> signalled-name r20--->r22
>
> autoroute announce
>
> !
>
> destination 10.20.0.22
>
> path-option 10 dynamic
>
>
>
>
>
> RP/0/0/CPU0:r22#sh run int tt1
>
> Fri Sep  4 11:50:01.581 CST
>
> interface tunnel-te1
>
> bandwidth 200000
>
> ipv4 unnumbered Loopback0
>
> signalled-name r22--->r20
>
> autoroute announce
>
> !
>
> destination 10.20.0.20
>
> path-option 10 dynamic
>
>
>
>
>
>
>
>
>
> *From:* dip <diptanshu.singh () gmail com>
> *Sent:* Friday, September 4, 2020 11:15 AM
> *To:* Aaron <aaron1 () gvtc com>
> *Cc:* Mark Tinka <mark.tinka () seacom com>; NANOG <nanog () nanog org>
> *Subject:* Re: rsvp-te admission control - i don't see it
>
>
>
> 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 <aaron1 () 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.com () 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, aaron1 () 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.