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
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
|
#
# 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 imporant 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 redily see the order in which entries will be processed. Next, it
# processes each entry, starting from the lowest priority entry, and
# proceeding in increasing prioriy 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 commited.
#
200 firewall/group
210 firewall
300 protocols/ospf
301 protocols/ospfv3
302 protocols/rip
303 protocols/ripng
310 interfaces/bridge
315 interfaces/bonding
318 interfaces/ethernet
319 interfaces/ethernet/node.tag/vif
320 interfaces/ethernet/node.tag/vif/node.tag/bridge-group
320 interfaces/bridge/node.tag/address
320 interfaces/loopback
330 interfaces/adsl
340 interfaces/serial
350 interfaces/wirelessmodem
380 interfaces/tunnel
380 interfaces/openvpn
400 system
450 protocols/static
470 policy
500 protocols/bgp
510 protocols/bgp/node.tag/parameters
520 protocols/bgp/node.tag/neighbor
530 protocols/bgp/node.tag/ipv6
530 protocols/bgp/node.tag/network
530 protocols/bgp/node.tag/redistribute
530 protocols/bgp/node.tag/timers
610 protocols/ospf/parameters
620 protocols/ospf/access-list
620 protocols/ospf/area
620 protocols/ospf/auto-cost
620 protocols/ospf/default-information
620 protocols/ospf/default-metric
620 protocols/ospf/distance
620 protocols/ospf/log-adjacency-changes
620 protocols/ospf/max-metric
620 protocols/ospf/mpls-te
620 protocols/ospf/neighbor
620 protocols/ospf/passive-interface
620 protocols/ospf/access-list
620 protocols/ospf/redistribute
620 protocols/ospf/refresh
620 protocols/ospf/timers
630 protocols/ospfv3/area
630 protocols/ospfv3/parameters
630 protocols/ospfv3/redistribute
640 protocols/rip/default-distance
640 protocols/rip/default-information
640 protocols/rip/default-metric
640 protocols/rip/distribute-list
640 protocols/rip/interface
640 protocols/rip/neighbor
640 protocols/rip/network
640 protocols/rip/network-distance
640 protocols/rip/passive-interface
640 protocols/rip/redistribute
640 protocols/rip/route
640 protocols/rip/timers
650 protocols/ripng/aggregate-address
650 protocols/ripng/default-information
650 protocols/ripng/default-metric
650 protocols/ripng/distribute-list
650 protocols/ripng/interface
650 protocols/ripng/network
650 protocols/ripng/passive-interface
650 protocols/ripng/redistribute
650 protocols/ripng/route
650 protocols/ripng/timers
800 interfaces/ethernet/node.tag/vrrp
800 interfaces/ethernet/node.tag/vif/node.tag/vrrp
810 interfaces/bridge/node.tag/ip
810 interfaces/adsl/node.tag/pvc/node.tag/pppoa/node.tag/ip
810 interfaces/adsl/node.tag/pvc/node.tag/pppoe/node.tag/ip
810 interfaces/adsl/node.tag/pvc/node.tag/classical-ipoa/ip
810 interfaces/adsl/node.tag/pvc/node.tag/bridged-ethernet/ip
810 interfaces/multilink/node.tag/vif/node.tag/ip
810 interfaces/loopback/node.tag/ip
810 interfaces/serial/node.tag/frame-relay/vif
810 interfaces/serial/node.tag/frame-relay/vif/node.tag/ip
810 interfaces/serial/node.tag/ppp
810 interfaces/serial/node.tag/ppp/vif
810 interfaces/serial/node.tag/ppp/vif/node.tag/ip
810 interfaces/serial/node.tag/cisco-hdlc/vif
810 interfaces/serial/node.tag/cisco-hdlc/vif/node.tag/ip
810 interfaces/ethernet/node.tag/vif/node.tag/ip
810 interfaces/ethernet/node.tag/vif/node.tag/pppoe/node.tag/ip
810 interfaces/ethernet/node.tag/ip
810 interfaces/ethernet/node.tag/pppoe/node.tag/ip
810 interfaces/bonding/node.tag/vif
810 interfaces/bonding/node.tag/vif/node.tag/ip
810 interfaces/bonding/node.tag/ip
810 interfaces/tunnel/node.tag/ip
810 interfaces/wirelessmodem/node.tag/ip
810 interfaces/openvpn/node.tag/ip
820 interfaces/bridge/node.tag/ipv6
820 interfaces/adsl/node.tag/pvc/node.tag/pppoa/node.tag/ipv6
820 interfaces/adsl/node.tag/pvc/node.tag/pppoe/node.tag/ipv6
820 interfaces/adsl/node.tag/pvc/node.tag/classical-ipoa/ipv6
820 interfaces/adsl/node.tag/pvc/node.tag/bridged-ethernet/ipv6
820 interfaces/multilink/node.tag/vif/node.tag/ipv6
820 interfaces/loopback/node.tag/ipv6
820 interfaces/serial/node.tag/frame-relay/vif
820 interfaces/serial/node.tag/frame-relay/vif/node.tag/ipv6
820 interfaces/serial/node.tag/ppp
820 interfaces/serial/node.tag/ppp/vif
820 interfaces/serial/node.tag/ppp/vif/node.tag/ipv6
820 interfaces/serial/node.tag/cisco-hdlc/vif
820 interfaces/serial/node.tag/cisco-hdlc/vif/node.tag/ipv6
820 interfaces/ethernet/node.tag/vif/node.tag/ipv6
820 interfaces/ethernet/node.tag/vif/node.tag/pppoe/node.tag/ipv6
820 interfaces/ethernet/node.tag/ipv6
820 interfaces/ethernet/node.tag/pppoe/node.tag/ipv6
820 interfaces/bonding/node.tag/vif
820 interfaces/bonding/node.tag/vif/node.tag/ipv6
820 interfaces/bonding/node.tag/ipv6
820 interfaces/tunnel/node.tag/ipv6
820 interfaces/wirelessmodem/node.tag/ipv6
820 interfaces/openvpn/node.tag/ipv6
850 interfaces
960 cluster
900 protocols/snmp
900 vpn
900 qos-policy
900 test-definition
900 content-inspection
900 load-balancing
900 service
900 protocols
|
