With this pattern two online tools give the full match “126.96.36.199/2”. But when I modify the pattern by move ([0-9]) to the end as the following:
Two online tools give exactly the full match “188.8.131.52/28”.
So I decide to modify the yang file “ietf-inet-types”, re-compile it by confdc, and replace the fxs file. But the ConfD cannot still be started. And the same error above appears on the command line.
I try another workaround by typedef a new type, such as my-ipv4-prefix with the latter pattern that the prefix “184.108.40.206/28” is validated by two online tools, in my YANG file. This solution works and ConfD can be started without any error.
Please anyone show me if this error of pattern of ietf module or error of ConfD?
String pattern is not the only validation done on ipv4-prefix.
Quote from the ietf-inet-types YANG you reference:
A prefix length value of n corresponds to an IP address
mask that has n contiguous 1-bits from the most
significant bit (MSB) and all other bits set to 0.
The canonical format of an IPv4 prefix has all bits of
the IPv4 address set to zero that are not part of the
To conform with base definition of ipv4-prefix, correct bitmask is not 28, but 29:
Many thanks josephm. I got your explaination. The address 220.127.116.11 is not a network address for the prefix 18.104.22.168/28.
Another confuse is that why the ConfD cannot still be started if I try to modify the yang file “ietf-inet-types” by changing the pattern of IPv4 prefix, re-compile it by confdc, and replace the fxs file? The same error above appears on the command line.
All built-in modules except ietf-netconf-with-defaults are always supported by the server. Support for ietf-netconf-with-defaults can be controlled by a setting in confd.conf.
So in the case of those built-in to ConfD standard YANG modules, including the ietf-inet-types module, rather than expanding the allowed value space of the pattern for the inet:ip-prefix type you would have to create your own type.