1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
|
#
# Vyatta Configuration Priority File.
#
# This file controls the processing of the statements in the Vyatta
# config file when it is first read during system startup, or during
# system operation when it is read with the "load" command. It also
# applies when configuration changes are entered by users in config
# mode.
#
# It primarily affects the way in which actions are preformed at the
# time the "commit" command is issued. These actions are encoded into
# the config templates, and consist of code executed at the "update:",
# "delete:", "create", "begin:", and "end:" tags.
#
# The priority file provides a few important benefits. First, it breaks
# the configuration statements to be committed into groups whose "commit
# actions" are applied together in a "transaction".
# Second, it defines the order in which these transactions are
# performed.
#
# Breaking the config statements into multiple transactions is important
# because transactions have all-or-nothing semantics. If all the
# statements to be committed were processed in a single transaction, a
# failure of any service would mean that no services would be
# configured. Processing the statements in multiple transactions means
# that failures in one area do not necessary prevent a service in
# another area from being configured. Note that this means that the
# "commit" command executes multiple "transactions" despite what might
# be implied by the command's name.
#
# Ordering the transactions is important because some services are
# dependent on other services being configured before they are.
#
# The format of this file is as a sequence of one-line entries that have
# the following format:
#
# <priority> <config-sub-tree>
#
# The <priority> field is number in the range 0 - 1000, and is used to
# order the processing of of the config statements. The
# <config-sub-tree> field is the path to a sub-tree of the configuration
# tree.
#
# When the Vyatta config file is processed at system startup, or when a
# new config file is loaded via the "load" command, the system first
# applies each entry in the file to the proposed configuration tree via
# a "set" command. After all parameters have been set, it issues the
# "commit" command.
#
# The "commit" command reads this priority file and sorts the entries in
# increasing order by their <priority> field. We usually try to
# maintain this file sorted in increasing <priority> order so that we
# can readily see the order in which entries will be processed. Next, it
# processes each entry, starting from the lowest priority entry, and
# proceeding in increasing priority order. For each entry, it checks to
# see if the <config-sub-tree> exists in the tree of parameters to be
# committed. If it does, it takes the config statements under that
# sub-tree and removes any statements that match a deeper sub-tree that
# was processed earlier or will be processed later. If any statements
# remain, then those statements are processed together as a group in a
# "transaction".
#
# To perform the transaction, the "commit" command then iterates through
# the statements in the group, performing the commit actions associated
# with each one. If any of the commit actions fail, then the
# transaction involving this group is viewed as having failed. No
# further commit actions are performed on the remaining statements in
# the group, and the parameters that make up the group are NOT added to
# the running configuration. If no commit actions fail, then the
# transaction is viewed as having succeeded.
#
# After the "commit" command completes processing one group, it iterates
# to the next entry in the sorted priority file and repeats the process.
# If, after processing the entire priority file, any configuration
# statements remain, they are applied in one final transaction.
#
# This process has a few important consequences. First, the commit
# action for every statement in the proposed config tree is applied
# exactly once. Second, each line in this file generates at most one
# transaction. Third, a config statement may be applied in a
# transaction before one of its parent nodes is applied. Its parent may
# be a multi-node parameter. An example of this is if the routing
# protocol parameters of an interface are applied before the interface
# itself is applied. In this case, the parent nodes are created in the
# "active config" tree at the time the lower-level node is committed.
#
200 firewall/group/port-group
200 firewall/group/port-group/node.tag/port
200 firewall/group/address-group
200 firewall/group/address-group/node.tag/address
200 firewall/group/network-group
200 firewall/group/network-group/node.tag/network
210 firewall/name/node.tag
210 firewall/modify/node.tag
210 firewall/ipv6-name/node.tag
210 firewall/ipv6-modify/node.tag
215 firewall
310 interfaces/bridge
315 interfaces/bonding
318 interfaces/ethernet
319 interfaces/ethernet/node.tag/vif
319 interfaces/ethernet/node.tag/bond-group
320 interfaces/ethernet/node.tag/vif/node.tag/bridge-group
320 interfaces/bonding/node.tag/bridge-group
320 interfaces/bonding/node.tag/vif
320 interfaces/bridge/node.tag/address
320 interfaces/loopback
330 interfaces/adsl
340 interfaces/serial
350 interfaces/wirelessmodem
380 interfaces/tunnel
380 interfaces/openvpn
390 interfaces/pseudo-ethernet
391 interfaces/pseudo-ethernet/node.tag/vif
400 system/domain-name
400 system/domain-search
400 system/gateway-address
400 system/host-name
400 system/ip
400 system/ipv6
400 system/login
400 system/name-server
400 system/ntp-server
400 system/options
400 system/package
400 system/static-host-mapping
400 system/syslog
400 system/time-zone
405 system
450 protocols/static
470 policy
500 protocols/bgp/node.tag/parameters
510 protocols/bgp/node.tag/neighbor
520 protocols/bgp
610 protocols/ospf/parameters
620 protocols/ospf
630 protocols/ospfv3/parameters
640 protocols/ospfv3
650 protocols/rip
660 protocols/ripng
800 interfaces/ethernet/node.tag/vrrp
800 interfaces/ethernet/node.tag/vif/node.tag/vrrp
810 interfaces/serial/node.tag/frame-relay/vif
810 interfaces/serial/node.tag/ppp
810 interfaces/serial/node.tag/ppp/vif
810 interfaces/serial/node.tag/cisco-hdlc/vif
850 interfaces
900 protocols/snmp
900 vpn
900 qos-policy
900 test-definition
900 content-inspection
900 load-balancing
900 protocols
900 service
910 service/dhcp-relay
911 service/dhcp-server
912 service/dns
913 service/https
914 service/nat
915 service/ssh
916 service/telnet
917 service/webproxy
960 cluster
970 zone-policy/zone/node.tag/from
975 zone-policy
|
