Re: [c-nsp] IOS-XE Smart licensing
I believe it's required that it must stay there. You can run an on-prem version of the manager which your routers can call in to. This will then call into Cisco for you. https://www.cisco.com/c/en/us/buy/smart-accounts/software-manager.html It's all a massive pain. We have kit that randomly stops calling in, and generates angry messages in dashboards. The sneaky alternative is that it's all honour based anyway (at least for the range we are using). Just let it sit in eval mode and move on with your life. Regards, Dave On Wed, 24 Feb 2021 at 11:22, Hank Nussbacher wrote: > So we bought a bunch of ASR1009x along with IOS-XE and are encountering > the joy of Smart licensing. > > Once we have our license established, do we need to leave the > "call-home" section? > > To me it screams "security violation" and something I'd like to > permanently disable after getting the license activated. > > Or does Cisco like to have their routers constantly ping the mothership > in regards to the licensing? > > > Regards, > > Hank > > ___ > 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/ > ___ 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] LSR platforms
NCS55A1 is reasonable. 36x100G ports. There are various other boxes in the NCS family that may have a port configuration you want. Keep in mind it’s broadcom, and comes with limitations with respect to things kike QoS. For a pure LSR role it does the job well. Dave On Thu, 10 Dec 2020 at 18:05, James Mitchell wrote: > What hardware platforms are operators running as P routers for smaller MPLS > networks? I’m not interested in large CRS type platforms, but simply an LSR > thats main function is MPLS switching at 10/40/100G speeds. Preferably > Cisco. Anyone have a recommendation based on experience? > ___ > 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/ > ___ 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] AAA on IOS-XR (NCS540)
This is our config to do just that. Running 7.0.2 aaa authorization exec LOCAL local aaa authorization exec TACACS group TACACS local aaa authentication login LOCAL local aaa authentication login TACACS group TACACS local aaa accounting exec default start-stop group TACACS aaa accounting system default start-stop group TACACS aaa accounting commands default start-stop group TACACS aaa group server tacacs+ TACACS server 10.0.0.1 server 10.0.0.2 tacacs-server host 10.0.0.1 port 49 key 7 xxx ! tacacs-server host 10.0.0.2 port 49 key 7 xxx ! username admin group root-lr secret 10 xxx line console authorization exec LOCAL login authentication LOCAL exec-timeout 12 0 ! line default authorization exec TACACS login authentication TACACS exec-timeout 12 0 transport input ssh Regards, Dave On Thu, 3 Dec 2020 at 18:31, Eric Van Tol wrote: > Hi all, > I’m going nuts here trying to get my AAA set up on an NCS. The goal is to > authenticate against TACACS on VTY lines but either use the local user > database or line/enable for console access and I cannot get it right. > Sometimes my VTY authentication fails the first time and it requires you to > put in your password a second time, even though the TACACS servers are > definitely available. I cannot get console access to work properly at all. > I’m running XR 7.1.1. Here’s the aaa portion of the config: > > tacacs source-interface Loopback1 vrf default > tacacs-server host 192.168.45.126 port 49 > key 7 ** > single-connection > ! > tacacs-server host 192.168.46.126 port 49 > key 7 ** > timeout 3 > single-connection > ! > username admin > group root-lr > group cisco-support > secret 10 $secretpass > ! > aaa group server tacacs+ TACACS > server 192.168.45.126 > server 192.168.46.126 > ! > aaa authorization exec CONSOLE local > aaa authorization exec default group TACACS local > aaa authentication login CONSOLE local line > aaa authentication login default group TACACS line! > ! > line console > password 7 ** > authorization exec CONSOLE > login authentication CONSOLE > ! > line default > password 7 ** > timeout login response 30 > authorization exec default > login authentication default > exec-timeout 0 0 > access-class ingress access-protect > session-timeout 120 > transport input ssh > ! > > I’ve tried different permutations of the line console config and can’t get > the right combination. Can someone point me in the right direction here? > > Thanks in advance, > evt > > ___ > 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/ > ___ 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] telemetry on IOS XE
A while back when I was experimenting this is the configuration I had running on a CSR1k 16.12.0 netconf-yang telemetry ietf subscription 1 encoding encode-kvgpb filter xpath /process-cpu-ios-xe-oper:cpu-usage/cpu-utilization/five-seconds source-address 192.168.0.2 stream yang-push update-policy periodic 5000 receiver ip address 10.0.2.1 57000 protocol grpc-tcp Apart from the VRF statement that is exactly what you have. Coincidently I’m trying to get this working on IOS XR with no success. A variety of versions, and I’m also having issues. I’m using the same config I tested a while back, but as with you I’m trying to source it in a VRF. I’ve got a TAC case open, however I’ve got a feeling it’s going to come back as unsupported. On Sat, 20 Jun 2020 at 06:42, Robert Hass wrote: > Yes I did > > #sh run | inc netconf > netconf-yang > > #show platform software yang-management process > confd: Running > nesd : Running > syncfd : Running > ncsshd : Running > dmiauthd : Running > nginx: Running > ndbmand : Running > pubd : Running > gnmib: Not Running > > On Sat, Jun 20, 2020 at 12:02 AM Dave Bell wrote: > >> Have you enabled netconf-yang? >> >> On Fri, 19 Jun 2020 at 20:46, Robert Hass wrote: >> >>> Hi >>> I'm trying to run telemetry on IOS XE (Catalyst 9300) but without lack. >>> >>> My config: >>> >>> test#sh run | sec tele >>> telemetry ietf subscription 1 >>> encoding encode-kvgpb >>> filter xpath >>> /process-cpu-ios-xe-oper:cpu-usage/cpu-utilization/five-seconds >>> source-address 10.0.0.147 >>> source-vrf Mgmt-vrf >>> stream yang-push >>> update-policy periodic 500 >>> receiver ip address 10.0.3.16 12345 protocol grpc-tcp >>> >>> But it's not working: >>> #show telemetry ietf subscription all >>> The process for the command is not responding or is otherwise unavailable >>> >>> Any ideas ? >>> >>> Running IOS XE 17.02.01 >>> >>> Rob >>> ___ >>> 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/ >>> >> ___ 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] telemetry on IOS XE
Have you enabled netconf-yang? On Fri, 19 Jun 2020 at 20:46, Robert Hass wrote: > Hi > I'm trying to run telemetry on IOS XE (Catalyst 9300) but without lack. > > My config: > > test#sh run | sec tele > telemetry ietf subscription 1 > encoding encode-kvgpb > filter xpath > /process-cpu-ios-xe-oper:cpu-usage/cpu-utilization/five-seconds > source-address 10.0.0.147 > source-vrf Mgmt-vrf > stream yang-push > update-policy periodic 500 > receiver ip address 10.0.3.16 12345 protocol grpc-tcp > > But it's not working: > #show telemetry ietf subscription all > The process for the command is not responding or is otherwise unavailable > > Any ideas ? > > Running IOS XE 17.02.01 > > Rob > ___ > 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/ > ___ 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] IOS-XR IS-IS authentication
Keychain for XR would help too..
key chain ISIS-DOMAIN
key 1
accept-lifetime 00:00:00 january 01 2020 infinite
key-string password
send-lifetime 00:00:00 january 01 2020 infinite
cryptographic-algorithm HMAC-MD5
On Wed, 27 May 2020 at 12:58, Dave Bell wrote:
> We've just turned up something similar. The difference is we are not using
> a keychain for the P2P password.
>
> >show configuration protocols isis
> topologies ipv6-unicast;
> overload timeout 300;
> level 1 disable;
> level 2 {
> authentication-key-chain ISIS_DOMAIN;
> wide-metrics-only;
> }
> interface ae6.0 {
> ldp-synchronization;
> lsp-interval 50;
> point-to-point;
> link-protection;
> level 2 {
> metric 1;
> ipv6-unicast-metric 1;
> hello-authentication-key ""; ## SECRET-DATA
> hello-authentication-type md5;
> }
> }
>
> > show configuration security
> authentication-key-chains {
> key-chain ISIS_DOMAIN {
> key 1 {
> secret "; ## SECRET-DATA
> start-time "2019-1-1.00:00:00 +";
> algorithm md5;
> }
> }
> }
>
>
>
> router isis ISIS
> set-overload-bit on-startup wait-for-bgp
> is-type level-2-only
> net 49.0001.0511.4807.2051.00
> lsp-password keychain ISIS-DOMAIN
> address-family ipv4 unicast
> metric-style wide level 2
> maximum-paths 8
> segment-routing mpls
> !
> address-family ipv6 unicast
> metric-style wide level 2
> maximum-paths 8
> !
> interface Bundle-Ether1
> hello-password hmac-md5 encrypted
> address-family ipv4 unicast
>metric 1
>
> On Wed, 27 May 2020 at 12:46, Eric Van Tol wrote:
>
>> Sorry if this is a duplicate – Outlook chose the ‘bounces’ address as the
>> one to send to and I didn’t notice.
>>
>> Hi all,
>> I’m testing out an NCS540 for use in our network and this is my first
>> foray into IOS-XR. We have a mix of Juniper and Cisco IOS/IOS-XE devices
>> that the NCS needs to interoperate with. I’m having some minor trouble with
>> IS-IS authentication and it’s kind of driving me nuts because I can’t get
>> IS-IS to come up when authentication is configured. I keep getting this
>> error:
>>
>> BAD P2P IIH rcvd from TenGigE0/0/0/19 SNPA 5c5e.abde.1e00: dropped
>> because cryptographic password mismatch
>>
>> Seems pretty obvious, but my keychain key password is configured and
>> verified to match on both sides:
>>
>> key chain isis-chain
>> key 1
>> accept-lifetime 00:00:00 january 01 1993 infinite
>> key-string password
>> send-lifetime 00:00:00 january 01 1993 infinite
>> cryptographic-algorithm HMAC-MD5
>> !
>> accept-tolerance infinite
>>
>> I’ve tried both MD5 and HMAC-MD5, neither works. Here is my IS-IS config
>> on the NCS540:
>>
>> router isis rtr1
>> set-overload-bit on-startup wait-for-bgp
>> is-type level-2-only
>> net 49.0001.1071.3820.2192.00
>> log adjacency changes
>> lsp-mtu 1497
>> lsp-password keychain isis-chain
>> address-family ipv4 unicast
>> metric-style wide level 2
>> !
>> address-family ipv6 unicast
>> metric-style wide level 2
>> single-topology
>> !
>> interface Loopback1
>> passive
>> address-family ipv4 unicast
>> !
>> address-family ipv6 unicast
>> !
>> !
>> interface TenGigE0/0/0/19
>> circuit-type level-2-only
>> point-to-point
>> hello-password keychain isis-chain
>> address-family ipv4 unicast
>>metric 3500
>> !
>> address-family ipv6 unicast
>>metric 3500
>> !
>> !
>>
>> traceoptions on the Juniper shows something similar:
>>
>> ERROR: IIH from 1071.3820.2192 on xe-0/0/0.0 failed authentication
>>
>> Here’s the Juniper key config and isis stanza:
>>
>> authentication-key-chains {
>> key-chain isis-chain {
>> key 1 {
>> secret ""; ## SECRET-DATA
>> start-time "1993-1-1.00:00:00 +";
>> algorithm md5;
>> }
>> }
>> }
>> protocols {
>> isis {
>> level 1 disable;
>> level 2 {
>> authentication-key-chain isis-chain;
>> wide-metrics-only;
>> }
>> interface xe-0/0/0.0 {
>> point-to-point;
>> level 2 {
>> metric 3500;
>> hello-authentication-key-chain isis-chain;
>> }
>> level 1 disable;
>> }
>> }
>>
>> I know it’s got to be something simple, but it’s not clicking for me
>> today. It seems like any step forward I take with IOS-XR, I end up taking
>> two steps back on the next thing that ‘just works’ everywhere else.
>>
>> -evt
>> ___
>> 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/
>>
>
___
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] IOS-XR IS-IS authentication
We've just turned up something similar. The difference is we are not using
a keychain for the P2P password.
>show configuration protocols isis
topologies ipv6-unicast;
overload timeout 300;
level 1 disable;
level 2 {
authentication-key-chain ISIS_DOMAIN;
wide-metrics-only;
}
interface ae6.0 {
ldp-synchronization;
lsp-interval 50;
point-to-point;
link-protection;
level 2 {
metric 1;
ipv6-unicast-metric 1;
hello-authentication-key ""; ## SECRET-DATA
hello-authentication-type md5;
}
}
> show configuration security
authentication-key-chains {
key-chain ISIS_DOMAIN {
key 1 {
secret "; ## SECRET-DATA
start-time "2019-1-1.00:00:00 +";
algorithm md5;
}
}
}
router isis ISIS
set-overload-bit on-startup wait-for-bgp
is-type level-2-only
net 49.0001.0511.4807.2051.00
lsp-password keychain ISIS-DOMAIN
address-family ipv4 unicast
metric-style wide level 2
maximum-paths 8
segment-routing mpls
!
address-family ipv6 unicast
metric-style wide level 2
maximum-paths 8
!
interface Bundle-Ether1
hello-password hmac-md5 encrypted
address-family ipv4 unicast
metric 1
On Wed, 27 May 2020 at 12:46, Eric Van Tol wrote:
> Sorry if this is a duplicate – Outlook chose the ‘bounces’ address as the
> one to send to and I didn’t notice.
>
> Hi all,
> I’m testing out an NCS540 for use in our network and this is my first
> foray into IOS-XR. We have a mix of Juniper and Cisco IOS/IOS-XE devices
> that the NCS needs to interoperate with. I’m having some minor trouble with
> IS-IS authentication and it’s kind of driving me nuts because I can’t get
> IS-IS to come up when authentication is configured. I keep getting this
> error:
>
> BAD P2P IIH rcvd from TenGigE0/0/0/19 SNPA 5c5e.abde.1e00: dropped because
> cryptographic password mismatch
>
> Seems pretty obvious, but my keychain key password is configured and
> verified to match on both sides:
>
> key chain isis-chain
> key 1
> accept-lifetime 00:00:00 january 01 1993 infinite
> key-string password
> send-lifetime 00:00:00 january 01 1993 infinite
> cryptographic-algorithm HMAC-MD5
> !
> accept-tolerance infinite
>
> I’ve tried both MD5 and HMAC-MD5, neither works. Here is my IS-IS config
> on the NCS540:
>
> router isis rtr1
> set-overload-bit on-startup wait-for-bgp
> is-type level-2-only
> net 49.0001.1071.3820.2192.00
> log adjacency changes
> lsp-mtu 1497
> lsp-password keychain isis-chain
> address-family ipv4 unicast
> metric-style wide level 2
> !
> address-family ipv6 unicast
> metric-style wide level 2
> single-topology
> !
> interface Loopback1
> passive
> address-family ipv4 unicast
> !
> address-family ipv6 unicast
> !
> !
> interface TenGigE0/0/0/19
> circuit-type level-2-only
> point-to-point
> hello-password keychain isis-chain
> address-family ipv4 unicast
>metric 3500
> !
> address-family ipv6 unicast
>metric 3500
> !
> !
>
> traceoptions on the Juniper shows something similar:
>
> ERROR: IIH from 1071.3820.2192 on xe-0/0/0.0 failed authentication
>
> Here’s the Juniper key config and isis stanza:
>
> authentication-key-chains {
> key-chain isis-chain {
> key 1 {
> secret ""; ## SECRET-DATA
> start-time "1993-1-1.00:00:00 +";
> algorithm md5;
> }
> }
> }
> protocols {
> isis {
> level 1 disable;
> level 2 {
> authentication-key-chain isis-chain;
> wide-metrics-only;
> }
> interface xe-0/0/0.0 {
> point-to-point;
> level 2 {
> metric 3500;
> hello-authentication-key-chain isis-chain;
> }
> level 1 disable;
> }
> }
>
> I know it’s got to be something simple, but it’s not clicking for me
> today. It seems like any step forward I take with IOS-XR, I end up taking
> two steps back on the next thing that ‘just works’ everywhere else.
>
> -evt
> ___
> 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/
>
___
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?
Metro Ethernet Forum - https://www.mef.net/ On Thu, 26 Mar 2020 at 15:03, Robert Raszuk wrote: > > The standardization is coming, check out > https://www.mef.net/mef-3-0-sd-wan > > 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. > > Is this the same as Microsoft's MEF: > > "The Managed Extensibility Framework (MEF) is a library in .NET that > enables greater reuse of applications and components." > > Thx, > R. > > On Thu, Mar 26, 2020 at 3:11 PM wrote: > > > > Sent: Sunday, March 15, 2020 6:04 PM > > > To: Hunter Fuller > > > > > > That's what I'm asking about. > > > > > > While the thread Mark referenced, deals (in my humble opinion) > primarily > > > with automation side of things, my question is how the whole SDN thing > > > became vendor-specific-closed-protocol? > > > > > > I'm not talking specifically about any particular facet of SDN, such as > > > automation or forwarding plane control over the network (though l > > > personally most interested in the latter, at least for now) or anything > > else - > > > rather, how 100% of solutions I've been presented over past year or so, > > are > > > all closed code-proprietary protocol solutions? > > > > > > Not a single one was based on an open standard, such as Open Flow, not > a > > > single one is able to interoperate with others, though one particular > SDN > > > solution will cost *a third *same vendor "traditional" standard > compliant > > > equipment. That's for me, was begging the question - am I missing > > > something here and I'm really be better off by selling my soul to a > > single > > > vendor for eternity, rather than opting for standard compliant box? If > > there's > > > such one to begin with? > > > > > The standardization is coming, check out > > https://www.mef.net/mef-3-0-sd-wan > > > > Though the only thing that can be meaningfully standardized really are > > "some" mechanisms/protocols used to disseminate "some" decisions. -but > that > > should be enough for basic inerop between vendors. > > How the controller comes to a decision is each vendors secret sauce (and > > as you might have guessed, there always will be some decisions that need > to > > communicated using novel/custom mechanisms -hence my use of "some") . > > > > adam > > > > ___ > > 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/ > > > ___ > 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/ > ___ 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/
