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

[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: [outages] Major Level3 (CenturyLink) Issues

[Robert Raszuk]

And just to add just a little bit of fuel to this fire let me share that
the base principle of BGP spec mandating to withdraw the routes when the
session goes down could be in the glory of IETF soon a history :(

It started with the proposal to make BGP state "persistent":
https://tools.ietf.org/html/draft-uttaro-idr-bgp-persistence-00

Now it got smoothed and improved a bit, but the effect is still the same -
keep the routes and do not withdraw when session goes down:
https://tools.ietf.org/html/draft-ietf-idr-long-lived-gr-00

Sure it is up to the operator discretion to enable it or not. But soon we
can no longer blame such behaviour as violation of BGP RFC if this proceeds
forward to formal RFC.

Hint: Max LLST value (24 bits in seconds) is over 194 days of prefix
expiration not just mentioned here with dislike 5 hours or so :)

Best
R,.


On Thu, Sep 3, 2020 at 6:20 PM Mark Tinka  wrote:

>
>
> On 2/Sep/20 15:12, Baldur Norddahl wrote:
>
> > I am not buying it. No normal implementation of BGP stays online,
> > replying to heart beat and accepting updates from ebgp peers, yet
> > after 5 hours failed to process withdrawal from customers.
>
> A BGP RFC spec. is not the same thing as a vendor translating that spec.
> into code. If it were, we'd never need this list.
>
> Triple the effort when deployed and operated at scale.
>
> Mark.
>

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

[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   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

[Ł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

[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

 

Re: Centurylink having a bad morning?

[Mark Tinka]

On 31/Aug/20 17:57, Bryan Holloway wrote:

> Not everyone will peer with you, notably, AS3356 (unless you're big
> enough, which few can say.)

I think Tomas meant more diverse peering, not peering with CL.

Mark.

Re: Centurylink having a bad morning?

[Andrew Koch]

On Wed, Sep 2, 2020 at 11:02, Warren Kumari  wrote:

>> well, what you REALLY need is one of these:
>> https://www.cru-inc.com/products/wiebetech/hotplug_field_kit_product/
>>
>
> Yeah, no... actually, hell no!
>
> That setup scares me, and I'm surprised that it can be sold at all,
> even with many warning labels and disclaimers...
> After the first time I saw it (I suspect also due to Chris!) I tried
> doing something similar -- I cut the ends off a power cord, attached
> alligator clips ...

called a suicide cord for a reason. Bad idea that comes about regularly when 
people try to back feed a generator to their house.

Andy

Re: Does anyone actually like CenturyLink?

[Mark Tinka]

On 3/Sep/20 17:54, Rubens Kuhl wrote:

> The outage that happened, while long, was the type that every big
> enough infrastructure will face one day or another.

This is probably the most sage piece of advice.

None of us are immune to this occurrence, regardless of size. Our only
hope is that the first one is the last one, per job :-).

Mark.

Re: Does anyone actually like CenturyLink?

[Mark Tinka]

On 3/Sep/20 17:54, Rubens Kuhl wrote:

> The outage that happened, while long, was the type that every big
> enough infrastructure will face one day or another.

This is probably the most sage piece of advice.

None of us are immune to this occurrence, regardless of size. I our only
hope is that the first one is the last one, per job :-).

Mark.

Re: [outages] Major Level3 (CenturyLink) Issues

[Mark Tinka]

On 2/Sep/20 15:12, Baldur Norddahl wrote:

> I am not buying it. No normal implementation of BGP stays online,
> replying to heart beat and accepting updates from ebgp peers, yet
> after 5 hours failed to process withdrawal from customers.

A BGP RFC spec. is not the same thing as a vendor translating that spec.
into code. If it were, we'd never need this list.

Triple the effort when deployed and operated at scale.

Mark.

Re: [outages] Major Level3 (CenturyLink) Issues

[Mark Tinka]

On 2/Sep/20 13:36, Mike Hammett wrote:

> Sure, but I don't care how busy your router is, it shouldn't take
> hours to withdraw routes.

If only routers had feelings...

Mark.

Re: Centurylink having a bad morning?

[Mark Tinka]

On 2/Sep/20 05:53, Alain Hebert wrote:

>
>     Beat installing a Cisco 12k solo with 2x4's to align the mounting
> holes...

I still have those in a rack somewhere, trapping air, if you want to
test that :-)...

Mark.

Re: Does anyone actually like CenturyLink?

[Rubens Kuhl]

The only ones that like CL are the ones with no options. CL is now an
operational threat to the whole Internet due to their hours-long time
to withdraw routes, something that having other providers or not being
a direct customer doesn't prevent.

The outage that happened, while long, was the type that every big
enough infrastructure will face one day or another. But their
inability to process BGP messages is unacceptable, and it has been
like that for a long time.


Rubens

On Sun, Aug 30, 2020 at 12:03 PM Ross Tajvar  wrote:
>
> I've never heard a single positive word about them, and I've had my fair 
> share of issues myself (as an indirect customer). But it seems that lots of 
> people put them in their transit blend. Other than lack of options, why would 
> anyone use them? To me, it just seems like asking for trouble...but maybe I'm 
> missing something?