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

aaron1 at gvtc.com aaron1 at gvtc.com
Fri Sep 4 16:06:17 UTC 2020


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 at nanog.org> On Behalf Of Mark Tinka
Sent: Thursday, September 3, 2020 10:58 PM
To: nanog at nanog.org
Subject: Re: rsvp-te admission control - i don't see it

 

 

On 3/Sep/20 22:20, aaron1 at gvtc.com <mailto:aaron1 at 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20200904/3c7030ac/attachment.html>


More information about the NANOG mailing list