Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CVL custom validation function hooks needs to supported #231

Open
rvasanthm opened this issue Oct 31, 2019 · 2 comments
Open

CVL custom validation function hooks needs to supported #231

rvasanthm opened this issue Oct 31, 2019 · 2 comments
Assignees
Labels
Fix available Fix available in master branch.

Comments

@rvasanthm
Copy link
Collaborator

Use cases:

  1. Based on the interface type create and delete requests need to be controlled.
  2. IP address overlap or duplicate check needs to be done across all interface IP tables while configuring for an interface.

Slack discussion:
Kwan Kim 11:14 AM
@partha Dutta @ravi Kumar Vasanthm Thanks Partha. I think we need more parameters.

  • need the operation type,
  • need to access DB to validate the request against the current config or state
  • need to report error string
  • need to get the entry, not individual
    Hence, here is a suggested fucntion:
    func ValidateFunc(opType int, d *db.DB, ctxNode interface{}, tblName string, key []string, value db.Value) error
    Please share your thoughts.
    Partha Dutta 7:06 PM
    I agree on including operation type, error string.
    Since CVL does not use DB struct, CVL session Redis Client can be included.
    I think depending on where the custom validation function is attached, node level or list level, the entry map can have value accordingly.
    I will look into detailed feasibility and come back.
    Meantime, please provide the YANG model where you want to put custom validation. Please also explain why we are not able to achieve the validation using 'must' expression.
    Partha Dutta 7:12 PM
    replied to a thread:
    @partha Dutta @Kwan Kim Issue 1- Interface creation and delete should be controlled based on interface type from CLI/GNMI/REST, physical and management interfaces create and delete should be blocked for above mentioned interface types.…
    Issue 1. Are you referring to sonic-interace.yang here ? Where interface type is stored in Redis table ? Have you tried must expression here ? What limitation you faced ?
    Issue 2. Did you try "count(//ip-address) = 0" sort of must expression ? What problem you faced ?

Partha Dutta Oct 21st at 8:21 PM
@ravi Kumar Vasanthm It looks like that following must expression can impose this constraint in sonic-interface.yang. Please let me know your opinion.
leaf ip_prefix {
mandatory true;
type inet:ip-prefix;
must "(/cmn:operation/cmn:operation != 'CREATE') or count(/sonic-interface/INTERFACE/INTERFACE_IPADDR_LIST[ip_prefix=current()]) = 1" {
error-message "IP address has already been configured.";
}
}

(edited)
2 replies

Ravi Kumar Vasanthm 9 days ago
@partha Dutta This check covers only is this IP address assigned/configured in the system. But it doesn't check the network address overlap based on the netmask/prefix configured on interfaces. Please check golang net package method which checks the network overlap cases.
func (n *IPNet) Contains(ip IP) bool

Ravi Kumar Vasanthm 9 days ago
If current address should not overlap and also we need to consider checking all the IP address tables in config DB (INTERFACE,MGMT_INTERFACE, PORTFCHANNEL_XX, VLANS_XXX)

@bhavini-gada
Copy link
Collaborator

@dutta-partha - Any updates here ?

@dutta-partha
Copy link
Collaborator

Custom validation support is available, you may implement network overlap checking using it.

@dutta-partha dutta-partha added the Fix available Fix available in master branch. label Dec 11, 2019
dell-engops pushed a commit that referenced this issue Nov 11, 2022
Fixed copy command URL invalid - password encoding
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Fix available Fix available in master branch.
Projects
None yet
Development

No branches or pull requests

3 participants