09-05-2018 11:49 PM - edited 09-05-2018 11:53 PM
I am very new to NCS and Yang modelling. I had created a new Service Yang and the service callback classes. But the callback is not reaching the below mentioned MplsTunnelRFS methods.
The steps followed were,
Is there something missing from the implementation?
Thanks in advance.
Regards
Sarath
Solved! Go to Solution.
09-20-2018 02:03 AM
Sorry, I don't know what else to tell you. It does trigger the callpoint correctly. Are you sure you haven't turned off all traces somehow? Maybe set log level to none or something?
I think you will have to file a ticket with support if you need additional help.
09-06-2018 02:37 AM
If it stores correctly in CDB but does not trigger the service point, then the most likely cause is that NSO doesn't think there is a service point there! If your model was correct you'd get an exception trying to write to a service that is not loaded.
Can you give a bigger piece of the yang model so we can see where the service point is?
By the way do you have only a pre-modification callback and no actual service callback? That is a very unusual design choice. Usually the create callback is the most important one.
Also, how can you be certain it doesn't reach the callback class?
09-06-2018 03:21 AM
Thanks a lot for the reply.
This was not a design choice, I was trying out few callback interfaces.
The create callback was also implemented.
The reason I said the callback is not reaching is, I had put logs in these callback methods and I could not see them in "ncs-java-vm.log".
The Yang that is being used is,
module mplstunnel {
namespace "urn:temp:mpls:mplstunnel";
prefix mplstunnel;
import ietf-inet-types {
prefix inet;
}
import tailf-ncs {
prefix ncs;
}
typedef tunnel-type {
type enumeration{
enum "mpls-tp" {
value 0;
description "mpls-tp";
}
}
description "tunnel type";
}
typedef direction {
type enumeration {
enum "forward"{
value 0;
description "forward";
}
enum "reverse"{
value 1;
description "reverse";
}
}
}
typedef tunnel-direction-type {
type enumeration {
enum "unidirectional" {
value 0;
description "unidirectional";
}
enum "corouted-bidirectional" {
value 1;
description "co-routed-bidirectional";
}
enum "associate-bidirectional" {
value 2;
description "associate-bidirectional";
}
}
description "tunnel direction type";
}
grouping tunnel-path{
leaf in-label{
type uint32 {
range "200001..300000";
}
mandatory "true";
description "Static in label for tunnel";
}
leaf in-interface{
type uint16 {
range "1..4096";
}
mandatory "true";
description "VLan ID";
}
leaf tunnel-in-direction{
type direction;
mandatory "true";
description "Direction of the packet flow";
}
leaf out-label{
type uint32 {
range "200001..300000";
}
mandatory "true";
description "Static in label for tunnel";
}
leaf out-interface{
type uint16 {
range "1..4096";
}
mandatory "true";
description "VLan ID";
}
}
augment /ncs:services {
list mplstunnel {
key tunnel-id;
uses ncs:service-data;
ncs:servicepoint mplstunnel-servicepoint;
leaf tunnel-id {
type uint16{
range "0..4096";
}
mandatory "true";
description "MPLS Tunnel Identifier";
}
leaf-list device {
type leafref {
path "/ncs:devices/ncs:device/ncs:name";
}
}
leaf source {
type string {
length "0..50";
}
mandatory "true";
description "Source node ID of the tunnel";
}
leaf destination{
type string {
length "0..50";
}
mandatory "true";
description "Destination node ID of the tunnel";
}
leaf tunnel-type{
type tunnel-type;
default "mpls-tp";
description "tunnel type";
}
leaf tunnel-mode {
type tunnel-direction-type;
mandatory "true";
description "The object indicates the direction of tunnel";
}
container forward-path{
uses tunnel-path;
}
container reverse-path{
uses tunnel-path;
}
leaf lsp-id{
type uint16 {
range "0..4096";
}
mandatory "true";
description "LSP ID";
}
}
}
}
Regards
Sarath
09-06-2018 03:34 AM
Okay. What log level are you using? You might want to put in an error log or similar so that it is traced by default. (Or set java-vm java-logging logger appropriately, see manual.)
Normally, you get an error when trying to commit if the service point is not implemented. Two things you can do is to first check the loaded packages using show package, here is sample output:
packages package resource-manager package-version 3.3.0 description "Resource manager package" ncs-min-version [ 4.2 ] directory ./state/packages-in-use/1/resource-manager templates [ resource-manager-ipaddress-allocation resource-manager-id-allocation ] component "Address allocation IP validation" callback java-class-name [ com.tailf.pkg.ipaddressallocator.IPValidator ] component "Reactive fastmap IP address allocation" application java-class-name com.tailf.pkg.ipaddressallocator.IPAddressAllocator application start-phase phase2 component "Reactive fastmap id allocation" application java-class-name com.tailf.pkg.idallocator.IdAllocator application start-phase phase2 oper-status up
Another thing you can do, which is a little bit advanced, but might be good for troubleshooting is to do
show ncs-state internal callpoints servicepoint and make sure that your service point is there and that it is bound to something and that no error is registered.
09-06-2018 04:26 AM
Log level that is being used is DEBUG. I have tried using ERROR as well with the same result.
The callback classes and the servicepoints seems to be registered properly. Its very confusing.
Following are the output of the commands
admin@padnms-cli> show packages package mplstunnel
packages package mplstunnel
package-version 1.0
description "MPLS Tunnel service"
ncs-min-version [ 3.0 ]
directory ./state/packages-in-use/2/mplstunnel
required-package common
min-version 1.0
component mplstunnel
callback java-class-name [ com.padtec.packet.service.mplstunnel.MplsTunnelRFS ]
oper-status up
[ok][2018-09-06 22:28:57]
admin@padnms-cli>
admin@padnms-cli> show ncs-state internal callpoints servicepoint mplstunnel-servicepoint
ncs-state internal callpoints servicepoint mplstunnel-servicepoint
daemon id 34
daemon name ncs-dp-30-mplstunnel:mplstunnel
[ok][2018-09-06 22:31:35]
09-06-2018 04:57 AM
09-06-2018 06:02 AM - edited 09-06-2018 06:03 AM
It seems Some of those lines are available my devel.logs, as seen in the below traces.
But the last line, "create: service create ok" seems to be missing from my devel.log.
I am wondering whether there is any issue with the way that I am deploying the new service.
I have a set of already running services. For deploying the new service, I compile the new packages and replace the package(mplstunnel) in <ncs-dir>/packages/services/ and perform a "request packages reload" from ncs_cli.
Regards
Sarath
<DEBUG> 6-Sep-2018::23:51:32.580 administrator-OptiPlex-390 ncs[19915]: ncs commit progress db=running usid=67 thandle=93: validate: creating rollback file...
<DEBUG> 6-Sep-2018::23:51:32.583 administrator-OptiPlex-390 ncs[19915]: ncs commit progress db=running usid=67 thandle=93: ok
<DEBUG> 6-Sep-2018::23:51:32.583 administrator-OptiPlex-390 ncs[19915]: ncs commit progress db=running usid=67 thandle=93: validate: run transforms and transaction hooks...
<DEBUG> 6-Sep-2018::23:51:32.584 administrator-OptiPlex-390 ncs[19915]: devel-c write_all request for callpoint 'ncs-rfs-service-hook' path
<DEBUG> 6-Sep-2018::23:51:32.584 administrator-OptiPlex-390 ncs[19915]: devel-c new_usess db request daemon id: 34
<DEBUG> 6-Sep-2018::23:51:32.585 administrator-OptiPlex-390 ncs[19915]: devel-c db reply daemon id: 34
<DEBUG> 6-Sep-2018::23:51:32.585 administrator-OptiPlex-390 ncs[19915]: devel-c new_trans request daemon id: 34 thandle: 93
<DEBUG> 6-Sep-2018::23:51:32.594 administrator-OptiPlex-390 ncs[19915]: devel-c New worker connected (daemon id: 34 worker id: 2)
<DEBUG> 6-Sep-2018::23:51:32.594 administrator-OptiPlex-390 ncs[19915]: devel-c new_trans succeeded daemon id: 34 session id: 2 worker id: 2
<DEBUG> 6-Sep-2018::23:51:32.594 administrator-OptiPlex-390 ncs[19915]: devel-c service_pre_modification(create) request for callpoint 'mplstunnel-servicepoint' path /ncs:services/mplstunnel{2}
<DEBUG> 6-Sep-2018::23:51:32.599 administrator-OptiPlex-390 ncs[19915]: devel-c service_pre_modification(create) succeeded for callpoint 'mplstunnel-servicepoint' path /ncs:services/mplstunnel{2}
<DEBUG> 6-Sep-2018::23:51:32.600 administrator-OptiPlex-390 ncs[19915]: devel-c service_create request for callpoint 'mplstunnel-servicepoint' path /ncs:services/mplstunnel{2}
<DEBUG> 6-Sep-2018::23:51:32.604 administrator-OptiPlex-390 ncs[19915]: devel-c service_create succeeded for callpoint 'mplstunnel-servicepoint' path /ncs:services/mplstunnel{2}
<DEBUG> 6-Sep-2018::23:51:32.606 administrator-OptiPlex-390 ncs[19915]: devel-c write_all succeeded for callpoint 'ncs-rfs-service-hook' path
<DEBUG> 6-Sep-2018::23:51:32.607 administrator-OptiPlex-390 ncs[19915]: ncs commit progress db=running usid=67 thandle=93: ok
<DEBUG> 6-Sep-2018::23:51:32.607 administrator-OptiPlex-390 ncs[19915]: ncs commit progress db=running usid=67 thandle=93: validate: mark inactive...
<DEBUG> 6-Sep-2018::23:51:32.608 administrator-OptiPlex-390 ncs[19915]: ncs commit progress db=running usid=67 thandle=93: ok
<DEBUG> 6-Sep-2018::23:51:32.608 administrator-OptiPlex-390 ncs[19915]: ncs commit progress db=running usid=67 thandle=93: validate: pre validate...
<DEBUG> 6-Sep-2018::23:51:32.608 administrator-OptiPlex-390 ncs[19915]: ncs commit progress db=running usid=67 thandle=93: ok
<DEBUG> 6-Sep-2018::23:51:32.609 administrator-OptiPlex-390 ncs[19915]: ncs commit progress db=running usid=67 thandle=93: validate: run dependency-triggered validation...
<DEBUG> 6-Sep-2018::23:51:32.609 administrator-OptiPlex-390 ncs[19915]: ncs commit progress db=running usid=67 thandle=93: validate: dependency-triggered validation done
<DEBUG> 6-Sep-2018::23:51:32.609 administrator-OptiPlex-390 ncs[19915]: ncs commit progress db=running usid=67 thandle=93: validate: check configuration policies...
<DEBUG> 6-Sep-2018::23:51:32.610 administrator-OptiPlex-390 ncs[19915]: ncs commit progress db=running usid=67 thandle=93: validate: configuration policies done
<DEBUG> 6-Sep-2018::23:51:32.610 administrator-OptiPlex-390 ncs[19915]: ncs commit progress db=running usid=67 thandle=93: entering write phase for running...
<DEBUG> 6-Sep-2018::23:51:32.610 administrator-OptiPlex-390 ncs[19915]: ncs commit progress db=running usid=67 thandle=93: cdb: write_start
<DEBUG> 6-Sep-2018::23:51:32.611 administrator-OptiPlex-390 ncs[19915]: ncs commit progress db=running usid=67 thandle=93: entering prepare phase for running...
<DEBUG> 6-Sep-2018::23:51:32.612 administrator-OptiPlex-390 ncs[19915]: ncs commit progress db=running usid=67 thandle=93: cdb: prepare
<DEBUG> 6-Sep-2018::23:51:32.612 administrator-OptiPlex-390 ncs[19915]: ncs commit progress db=running usid=67 thandle=93: cdb: delivering prepare subscription notifications at prio 0
<DEBUG> 6-Sep-2018::23:51:32.612 administrator-OptiPlex-390 ncs[19915]: ncs commit progress db=running usid=67 thandle=93: cdb: all prepare subscription notifications acknowledged
<DEBUG> 6-Sep-2018::23:51:32.612 administrator-OptiPlex-390 ncs[19915]: ncs commit progress db=running usid=67 thandle=93: entering commit phase for running...
<DEBUG> 6-Sep-2018::23:51:32.612 administrator-OptiPlex-390 ncs[19915]: ncs commit progress db=running usid=67 thandle=93: cdb: commit
<DEBUG> 6-Sep-2018::23:51:32.654 administrator-OptiPlex-390 ncs[19915]: ncs commit progress db=running usid=67 thandle=93: cdb: delivering commit subscription notifications at prio 0
<DEBUG> 6-Sep-2018::23:51:32.655 administrator-OptiPlex-390 ncs[19915]: ncs commit progress db=running usid=67 thandle=93: cdb: all commit subscription notifications acknowledged
<DEBUG> 6-Sep-2018::23:51:32.662 administrator-OptiPlex-390 ncs[19915]: devel-c close_trans request daemon id: 34 session id: 2
<DEBUG> 6-Sep-2018::23:51:32.662 administrator-OptiPlex-390 ncs[19915]: devel-c close_usess db request daemon id: 34
09-06-2018 06:09 AM
09-20-2018 12:33 AM
Hi,
Thanks again for the reply.
Following is the package structure that I have. It is not any different from the package structure for another working service.
I am invoking the new service exactly the same way as I do for the working service(which prints the debug statement inside the callback class).
packages
Regards
Sarath
09-20-2018 02:03 AM
Sorry, I don't know what else to tell you. It does trigger the callpoint correctly. Are you sure you haven't turned off all traces somehow? Maybe set log level to none or something?
I think you will have to file a ticket with support if you need additional help.
10-04-2018 01:57 PM
Hello,
Sorry to be late to this discussion.
I've seen situations where the programmer has the same servicepoint defined in both the service java/python code _and_ in the header of the service template. I believe in this case I've seen that execution goes directly to the template servicepoint first (or it is indeterministic and a race determines). If processing goes directly to the template, you will not see the logs in your service java/python code since the service code is not executed.
-Larry
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide