Re: [c-nsp] ASR920 Port Licensing

[t...@pelican.org]

On Wednesday, 24 February, 2021 16:47, "Gert Doering"  
said:

> Yep.  Welcome to the world of "we truly understand what our customers
> are really expecting from a network vendor".

I do wonder if someone - Enterprise customers? - is actually asking for this 
kind of time-bomb phone-home licensing, or if it's purely a vendor frog-boiling 
exercise in how bad they can make the customer experience and still have it be 
less bad than the pain of jumping ship...

It's not just C up to this nonsense, experiencing the same pain with 
network-refresh in J-land :(

Cheers,
Tim.


___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] asr1001-x : dynamic qos on virtual-template

[t...@pelican.org]

Hi Cédric,

On Tuesday, 16 February, 2021 07:46, "BASSAGET Cédric" 
 said:

> I tried something like this :
> class-map match-any QOS-class-voip
>  match dscp cs3
>  match dscp ef
> !
> policy-map child
>  class QOS-class-voip
>   police cir 10m
>conform-action transmit
>exceed-action drop
>  class class-default
> policy-map parent
>  class class-default
>   shape average 1g
>service-policy child
> !
> interface Virtual-Template1
>  service-policy output parent
> 
> but when the PPPoE session comes up, I still have this error :
> %QOS-6-POLICY_INST_FAILED: Service policy installation failed on SSS
> session identifier 66 -. service-policy not applicable for interface
> features. policy:parent, dir:OUT, ptype:, ctype:DEFAULT

Does Harald's suggested RADIUS-push of:

cisco-avpair += "ip:sub-qos-policy-out=parent"

rather than applying to the virtual-template work instead?  You'd need to push 
it for every user, obviously.  That's the way I've had QoS-policies applied to 
the created virtual-access sub-interfaces in the past.

Cheers,
Tim.


___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] asr1001-x : dynamic qos on virtual-template

[t...@pelican.org]

Hi Cédric,

On Monday, 15 February, 2021 15:51, "BASSAGET Cédric" 
 said:

> The problem here is that I don't know the speed on the access side. I know
> it will go up to 1Gb/s down - 250Mb/s up. But it can be lower than that, as
> it's GPON architecture.
> We don't sell a fixed (guaranteed) bandwidth to customers. We sell it as
> "up to 1Gb/s down - 250Mb/s up" as we are not able to guaranty bandwidth.

That's contention in the network, though, not speed to the CPE, unless I'm 
missing something.  Nothing's going to report in a PPP connection how much 
traffic is making it through the access layer to the LNS.  Not the same thing 
as DSL/FTTC, where you've got a physical negotiation going on between the CPE 
and the DSLAM to agree the upstream / downstream speeds of a particular copper 
pair, before you even get to any further contention 

So you can treat it as:

- You have 1G from the LNS to the CPE.  You can choose which 1G of packets to 
put into that sessions.  Sometimes the access layer will discard some of those 
packets, you don't have any control over that.  Make a 1G shaper, with your 
voice priority class in it.  Voice won't get discarded in favour of data in the 
parts you control.

- You have some amount of bandwidth from the LNS to the CPE that's (almost) 
always achievable - what that is will depend on your exact access layer set-up, 
split ratio, etc.  Maybe that's 250M downstream.  You build your shaper around 
that value, with your voice priority class in it.  You've got control of 
exactly which 250M stream leaves your LNS, with a high expectation that all of 
those packets reach the CPE - BUT the customer will never get more throughput 
than that, even if all the other links on the GPON node are idle.

It's really down to whether you're after higher-bandwidth with "intelligent 
discard" QoS, or something closer to a guaranteed but lower bandwidth.

I'm not aware of anything in the FTTH space that would let you detect 
congestion in the access layer and back off the parent shaper accordingly.  
Neither end has that info, without you building some kind of active probes of 
your own.

What's the problem you're trying to solve?  Customers with >1G of traffic 
trying to go downstream, and you need to make sure data packets are discarded 
rather than voice?

Cheers,
Tim.


___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] asr1001-x : dynamic qos on virtual-template

[t...@pelican.org]

Hi Cédric,

On Monday, 15 February, 2021 14:29, "BASSAGET Cédric" 
 said:

> QoS I'm trying to deploy is not for DLS links, it's for FTTH. I have no
> information about CPE throughput capabilities in access-request or
> accounting messages.

If your access circuit is FTTH, you shouldn't have the same problem as DSL or 
FTTC, where the actual sync speed and hence bandwidth available can be all over 
the place, and you need to account for it in your policy.  Keeping things 
simple, and following Harald's examples of pushing a fixed-name policy via 
RADIUS might be a better way to go.

Presumably you only have to deal with whatever service tiers are available on 
your FTTH service, e.g. you need a 100M, 300M and 900M policy with the 
corresponding parent shaper, not all the possible bandwidth rates in between.  
If you've bought 100M FTTH on the access side, you should get 100M, not worry 
about exactly what "up to 100M" speed you've managed to sync at.

Cheers,
Tim.


___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Sanity check OSPF/BGP

[t...@pelican.org]

On Thursday, 8 October, 2020 17:08, "Drew Weaver"  said:

> Previously, when we had this issue it was determined that it was because 
> there was
> still a route to the BGP neighbor in the routing table (because the neighbor 
> IP
> was part of our IP announcements and it would wait until the hold time to 
> expire)
> but we got around that particular issue by using RFC1918 IPs for the 
> neighbors and
> BGP Next hop address tracking took care of the rest (made it much faster, 
> like 1-2
> seconds) but it seems like in our current architecture with the new core
> it’s operating differently.
> 
> It’s almost like the new core routers are continuing to be seen as a path to
> this neighbor by the old core routers and vice versa even though OSPF went 
> down on
> both of them at the same exact time.
> 
> It’s a mystery for sure.

Back to basics - what does "show ip route " give you during 
that two-minute window?

Is there a default route somewhere in the network that could be flagging that 
remote loopback as still reachable until the BGP timers expire?

Regards,
Tim.


___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] XR6 process conflicts

[t...@pelican.org]

On Monday, 14 September, 2020 19:38, "Radu-Adrian FEURDEAN" 
 said:

> On Sat, Sep 12, 2020, at 11:25, James Bensley wrote:
> 
>> In your specific case/example; if I have a PE with a single physical
>> interface connected to some 3rd party wholesale Ethernet NNI, with 500
>> sub-interfaces, each running OSPF to a remote CPE; if the physical
>> interface goes down I don't need 500 SNMP traps or syslog messages to
>> tell me that all 500 OSPF sessions are down. There are two sides to
> 
> OTOH, if the NNI service goes down (circuits are interrupted), but the 
> interface
> stays up, you will be happy to know that ALL circuits are down (or at least 
> which
> of them went down) when you open a ticket to the NNI provider.

And in an ideal world, of course, your monitoring platform will do intelligent 
root-cause analysis, suppress all the individual circuit alarms, generate a 
single master alarm for the NNI for the NOC to deal with, and notify all the 
impacted customers of the master ticket.

I'd usually want to err on the side of having more data and putting appropriate 
filtering between the data and the person viewing, rather than NOT having data 
it later turns out would be useful.

Regards,
Tim.


___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Rehosting a perpetual CSR1000V license

[t...@pelican.org]

On Friday, 24 July, 2020 14:52, "Nick Hilliard"  said:

> yep, that works fine for electricity because the cost of generating
> electricity is a significant percentage of the amount that the end user
> pays.  I.e. the marginal cost is significant, so it's worth billing per
> kWh.  If this model had been a better way of charging for residential ip
> data delivery, it would have been deployed a long time ago, but the
> marginal cost per bit isn't worth it in the majority of cases because
> the cost of mass billing is so high.

Not forgetting the cost of billing *disputes*.

It's been a couple of decades since I worked in residential Internet, but when 
I did, if the customer called you, ever, for any reason, the contract was 
essentially running at a loss.  I can't imagine margins have got better...

Regards,
Tim.


___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] how many IGP routes is too many?

[t...@pelican.org]

On Thursday, 2 April, 2020 09:43, "Saku Ytti"  said:

> At any rate tens of thousands of routes is fine and normal, but if
> you'd try in a lab, I'd not be particularly surprised if millions
> work. Of course you should not really want to carry anything else but
> loop0 and NMS networks in IGP.

The last is the key point, I think.  Is the OP asking the question because 
they're looking to build a network with a *lot* of devices in, or because 
they're trying to carry other things in the IGP?

Regards,
Tim.

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] [External] SDx open standard?

[t...@pelican.org]

On Thursday, 26 March, 2020 15:15, sth...@nethelp.no said:

>> I spent 10 min browsing MEF web site and still do not know what "MEF"
>> stands for ... Looks to me like yet one more  commercial entity to drain a
>> little bit of cash out of the vendors while perhaps help with marketing and
>> sales a bit.
> 
> Metro Ethernet Forum. They've been around for a while.
> 

In fairness, that term is almost entirely absent from the web site, as far as I 
can see.

Is it an expansion that's been deliberately dropped in the face of expanding to 
work on SDN, NDV, et al beyond their original Metro Ethernet scope?  And now 
MEF is just MEF?

Regards,
Tim.

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Inter-area Summarization problem on Nexus 9508

[t...@pelican.org]

On Thursday, 16 November, 2017 13:24, "Brian Turnbow"  said:

>>  Anyone know what is wrong with the below range ?
>>
> 
> Yep, host bits are set
> You need to put in the network
> 
>> router ospf 386
>>   vrf AAA
>> area 0.0.0.1 stub no-summary
>>
>> NX9KB9002(config-router-vrf)# area 1 range 10.203.165.80/28
>> Invalid range, host bits are set

10.203.165.80 is a valid network address for a /28, but doesn't "area range" 
take an address and dotted-quad netmask rather than a CIDR prefix?  So:

area 1 range 10.203.165.80 255.255.255.240

Regards,
Tim.


___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] monitor primary and secondary IP address traffic separately over SNMP

[t...@pelican.org]

On Tuesday, 7 March, 2017 15:53, "Martin T"  said:

> While I have done very little testing, then essentially this seems to
> work. However, this counts only ingress traffic. In addition, I wonder
> does such configuration have any noticeable affect on router CPU?
> Model is Cisco 2921 and traffic is ~100Mbps.

My experience across the board for ISRG2 is that applying a service policy 
reduces your throughput by anything up to 90%.  (Yes, 90% *reduction*, i.e. 
only 10% of the original throughput).  Conversations with the BU confirm that 
this is expected behaviour, but I don't believe I've explicitly tested it with 
*only* an inbound "counting" service policy.

For IMIX traffic, I'm getting around 450Mb/s out of a 2921 with no service 
policy, 70Mb/s with an outbound QoS policy.  Those are symmetric 
bi-directional, so in Cisco-speak, a total of 900Mb/s or 140Mb/s throughput, 
split between upstream and downstream as you wish.

Regards,
Tim.



___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] ACL performance question

[t...@pelican.org]

Hi Satish,

On Saturday, 20 August, 2016 21:23, "Satish Patel"  said:

> We have ASR1006 Router and we are running ACL on it to allow specific
> port to specific server.
> 
> Question is there any ACL performance impact on individual IP vs full
> subnet. like following example.
> 
> we have 202.100.100.0/24 subnet now i want to use first 200 IPs for
> web server port 80 remaining 55 (whatever) mail service port 25.

Taking a step backwards, does it *have* to be 200 and 55?  Or can you split on 
bit boundaries and get much simpler ACLs?  For example, if you can live with 
191 web servers and 63 mail servers...

> Now how do i tell ACL to isolate them or subnet them? Other option i
> have i create individual ACL for each IP like following but question
> is does it impact on router performance?
> 
> access-list 102 permit tcp any host 202.100.100.1 eq www
> access-list 102 permit tcp any host 202.100.100.2 eq www
> access-list 102 permit tcp any host 202.100.100.3 eq www
> access-list 102 permit tcp any host 202.100.100.4 eq www
> ...
> ...
> access-list 102 permit tcp any host 202.100.100.201 eq smtp
> access-list 102 permit tcp any host 202.100.100.202 eq smtp

Becomes:

access-list 102 permit tcp any 202.100.100.0 0.0.0.127 eq www
access-list 102 permit tcp any 202.100.100.128 0.0.0.63 eq www
access-list 102 permit tcp any 202.100.100.192 0.0.0.63 eq smtp

Ignoring any performance or TCAM issues, that looks like something that's going 
to make your operations folk less crazy trying to work with the configs.

Regards,
Tim.


___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[c-nsp] Docs on Cisco NAT / RFC4787

[t...@pelican.org]

Hi all,

Does anyone have pointers to docs or previous experience on how Cisco NAT, and 
specifically PAT overload against a single WAN interface address, interacts 
with the various REQs in RFC4787?  I'm needing to respond to some questions 
about it rather more quickly than I can put it together in the lab...

Thanks in advance,
Tim.

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] NX-OS SNMP agent returns first 64 characters of interface description while CLI allows one to enter 80 characters interface descriptions

[t...@pelican.org]

On Thursday, 29 October, 2015 16:25, "Martin T"  said:

> Where does this inconsistency come from? Is there a way to increase
> the amount of characters returned by NX-OS SNMP agent for interface
> descriptions?

Vanilla IOS has "snmp ifmib ifalias long" - you could check if this is 
available under NX-OS.

Regards,
Tim.

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/