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

2020-09-04 Thread Aaron Gould via NANOG
That’s it!  Thanks dip

 

Using “signalled-bandwidth 5000”  on headend te-tunnel int

 

 

RP/0/0/CPU0:r20#sh run int tt1

Fri Sep  4 13:27:14.833 CST

interface tunnel-te1

bandwidth 20

ipv4 unnumbered Loopback0

signalled-name r20--->r22

signalled-bandwidth 5000

autoroute announce

!

destination 10.20.0.22

path-option 10 dynamic

!

 

On HE…

 

RP/0/0/CPU0:r20#sh mpls traffic-eng tunnels name r20--->r22 | in and

Fri Sep  4 13:28:28.918 CST

Name: tunnel-te1  Destination: 10.20.0.22  Ifhandle:0x1d0 

Bandwidth Requested: 5000 kbps  CT0

Bandwidth: 5000 kbps (CT0) Priority:  7  7 Affinity: 0x0/0x

 

RP/0/0/CPU0:r20#sh rsvp reservation detail | in ate

Fri Sep  4 13:25:51.509 CST

Rate: 0 bits/sec. Burst: 1K bytes. Peak: 0 bits/sec.

State expires in 0.000 sec.

Rate: 500 bits/sec. Burst: 1K bytes. Peak: 5M bits/sec.

State expires in 358.630 sec.

 

RP/0/0/CPU0:r20#sh rsvp int   

Fri Sep  4 13:26:03.738 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*  750M5M (  0%)   
 0*

 

 

On transit lsr in core…

 

RP/0/0/CPU0:r24#sh rsvp session detail | in ate

Fri Sep  4 13:18:25.258 CST

   Tspec: avg rate=0, burst=1K, peak rate=0

   Fspec: avg rate=0, burst=1K, peak rate=0

   Tspec: avg rate=5M, burst=1K, peak rate=5M

   Fspec: avg rate=5M, burst=1K, peak rate=5M

 

RP/0/0/CPU0:r24#sh rsvp int

Fri Sep  4 13:18:33.508 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*  750M5M (  0%)   
 0*

 



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

2020-09-04 Thread dip
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  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 20
>
> 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 20
>
> ipv4 unnumbered Loopback0
>
> signalled-name r22--->r20
>
> autoroute announce
>
> !
>
> destination 10.20.0.20
>
> path-option 10 dynamic
>
>
>
>
>
>
>
>
>
> *From:* dip 
> *Sent:* Friday, September 4, 2020 11:15 AM
> *To:* Aaron 
> *Cc:* Mark Tinka ; NANOG 
> *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  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

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

2020-09-04 Thread aaron1
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 20

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 20

ipv4 unnumbered Loopback0

signalled-name r22--->r20

autoroute announce

!

destination 10.20.0.20

path-option 10 dynamic

 

 

 

 

From: dip  
Sent: Friday, September 4, 2020 11:15 AM
To: Aaron 
Cc: Mark Tinka ; NANOG 
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 mailto: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 <http://10.20.0.0/16> 

10.20.0.X/24  - loopbacks

10.20.1.0/24 <http://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 <http://10.20.1.0/30>   – r20---r21

10.20.1.4/30 <http://10.20.1.4/30>   – r21---r22

10.20.1.8/30 <http://10.20.1.8/30>   – r22---r23

10.20.1.12/30 <http://10.20.1.12/30>  – r23---r25

10.20.1.16/30 <http://10.20.1.16/30>  – r25---r24

10.20.1.20/30 <http://10.20.1.20/30>  – r24---r20

 

r10#sh ip int br | in up

GigabitEthernet3   1.0.0.2 YES manual upup

 

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 

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

2020-09-04 Thread dip
>   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  *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/000 (  0%)   10
> 01
>
> Gi0/0/0/11000K0 (  0%)   01
> 10
>
>
> 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.
>


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

2020-09-04 Thread aaron1
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 upup

 

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  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 <mailto:aar...@gvtc.com>  wrote:

Thanks, how do I see the control plane reservation?  I don’t seem to be seeing

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

2020-09-03 Thread Mark Tinka


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.


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

2020-09-03 Thread aaron1
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/000 (  0%)   10   01

Gi0/0/0/11000K0 (  0%)   01   10

 

-Aaron

 

 

From: Łukasz Bromirski  
Sent: Thursday, September 3, 2020 2:45 PM
To: aar...@gvtc.com
Cc: nanog@nanog.org
Subject: Re: rsvp-te admission control - i don't see it

 

Aaron,





On 3 Sep 2020, at 20:05, aar...@gvtc.com <mailto:aar...@gvtc.com>  wrote:

 

I have a functional mpls-te test running, seems fine…but, question about 
bandwidth reservations please.

 

At the Headend router, I set bandwidth on my mpls-te tunnel, but I can’t for 
the life of me, find where in the network is this bandwidth actually being 
admitted, or seen, or allocated or anything!

 

I mean I look on rsvp interfaces, I look in wireshark at the tspec field of the 
path message, I look in the mpls te tunnels along the way, etc, etc, I can’t 
find where the network sees that bandwidth I’m asking for at the tunnel Head 
end.

 

I’m not sure if I understand you, but RSVP only does control plane reservation.

 

Then, once you have a tunnel to establish with specific bandwidth required, 
RSVP-TE will do CSPF based on link coloring, bandwidth available over 
interfaces and priority of tunnel to decide how to establish it. If the tunnel 
is setup over interface, bandwidth assigned to tunnel is taken out from 
bandwidth available on that interface. But this is purely control plane 
reservation. Nothing will be enforced in data plane.

 

To enforce those values, you need to apply QoS policies to interfaces over 
which you expert to serve MPLS TE tunnels.

 

— 

./



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

2020-09-03 Thread Łukasz Bromirski
Aaron,

> On 3 Sep 2020, at 20:05, aar...@gvtc.com wrote:
> 
> I have a functional mpls-te test running, seems fine…but, question about 
> bandwidth reservations please.
>  
> At the Headend router, I set bandwidth on my mpls-te tunnel, but I can’t for 
> the life of me, find where in the network is this bandwidth actually being 
> admitted, or seen, or allocated or anything!
>  
> I mean I look on rsvp interfaces, I look in wireshark at the tspec field of 
> the path message, I look in the mpls te tunnels along the way, etc, etc, I 
> can’t find where the network sees that bandwidth I’m asking for at the tunnel 
> Head end.

I’m not sure if I understand you, but RSVP only does control plane reservation.

Then, once you have a tunnel to establish with specific bandwidth required, 
RSVP-TE will do CSPF based on link coloring, bandwidth available over 
interfaces and priority of tunnel to decide how to establish it. If the tunnel 
is setup over interface, bandwidth assigned to tunnel is taken out from 
bandwidth available on that interface. But this is purely control plane 
reservation. Nothing will be enforced in data plane.

To enforce those values, you need to apply QoS policies to interfaces over 
which you expert to serve MPLS TE tunnels.

— 
./

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

2020-09-03 Thread aaron1
I have a functional mpls-te test running, seems fine.but, question about
bandwidth reservations please.

 

At the Headend router, I set bandwidth on my mpls-te tunnel, but I can't for
the life of me, find where in the network is this bandwidth actually being
admitted, or seen, or allocated or anything!

 

I mean I look on rsvp interfaces, I look in wireshark at the tspec field of
the path message, I look in the mpls te tunnels along the way, etc, etc, I
can't find where the network sees that bandwidth I'm asking for at the
tunnel Head end.

 

Using IOS-XR in EVE-NG for testing.  XR 6.3.1

 

I'll give you other details if you want them.

 

 

 

Aaron

aar...@gvtc.com