-
Notifications
You must be signed in to change notification settings - Fork 0
/
pfxaggr.1
140 lines (140 loc) · 3.26 KB
/
pfxaggr.1
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
.\" Automatically generated by Pandoc 2.11.0.3
.\"
.TH pfxaggr 1 "2020-11-03" "0.6" "Prefix aggregation tool"
.hy
.SH pfxaggr
.PP
Yet another IP aggregation tool (fast)
.SS SYNOPSIS
.PP
\f[C]pfxaggr [-v|-v -v] [-c] [-na|-a0|-a1|-a2|-a3|-a4]\f[R]
.SS DESCRIPTION
.PP
pfxaggr reads from STDIN prefixes in CIDR notation (v4 & v6) and outputs
them sorted / aggregated / in another notation to STDOUT.
.SS INSTALLATION
.PP
make
.SS USAGE INFORMATION
.PP
What do the different modes do?
Let\[aq]s take as example the following input:
.IP
.nf
\f[C]
192.0.2.0/32
192.0.2.1/32
192.0.2.0/31
192.0.2.2/31
192.0.2.7/31 (unaligned)
192.0.2.2/32
192.0.2.3/32
192.0.2.0/30
192.0.2.4/31
\f[R]
.fi
.PP
\f[C]-na\f[R] just aligns and sorts the prefixes:
.IP
.nf
\f[C]
192.0.2.0/30
192.0.2.0/31
192.0.2.0/32
192.0.2.1/32
192.0.2.2/31
192.0.2.2/32
192.0.2.3/32
192.0.2.4/31
192.0.2.6/31
\f[R]
.fi
.PP
\f[C]-a0\f[R] aggregates them by \[dq]hiding\[dq] prefixes, which are
covered by less specifics seen in the input.
No new less specifics are added:
.IP
.nf
\f[C]
192.0.2.0/30
192.0.2.4/31
192.0.2.6/31
\f[R]
.fi
.PP
\f[C]-a1\f[R] aggregates them but eventually adds new less specifics.
The covered address space remains the same, but added less specifics
might not had been seen in the input:
.IP
.nf
\f[C]
192.0.2.0/29
\f[R]
.fi
.PP
\f[C]-a2\f[R] combines the prefixes of the input in a slightly different
notation for exact match with the input.
prefix/mask-maxmask states, that in the input, every possible
combination of prefix/m with m between mask and maxmask was present:
.IP
.nf
\f[C]
192.0.2.0/30-32
192.0.2.4/31
192.0.2.6/31
\f[R]
.fi
.PP
\f[C]-a3\f[R] combines the prefixes of the input in a slightly different
notation for exact match with the input.
In addition to \f[C]-a2\f[R] also combines complete \[dq]sets\[dq] from
the closest less-specific prefix/mask\[aq]s perspective (which
wasn\[aq]t part of the input).
prefix/mask,/mask1-mask2 states, all possible prefix/m with m between
mask1 and mask2 had been present in the input.
In some cases the result is not optimal or other \[dq]solutions\[dq] are
possible:
.IP
.nf
\f[C]
192.0.2.0/29,/31-31
192.0.2.0/30
192.0.2.0/30,/32-32
\f[R]
.fi
.PP
\f[C]-a4\f[R] is suitable as input for Juniper\[aq]s
\f[C]route-filter(-list)\f[R] with \f[C]upto\f[R] (prefix/mask1-mask2 =>
\f[C]route-filter prefix/mask1 upto /mask2\f[R]) or
\f[C]prefix-length-range\f[R] (prefix/mask,/mask1-mask2 =>
\f[C]route-filter prefix/mask prefix-length-range /mask1-/mask2\f[R]) to
exactly match input prefixes.
In some cases the result is not optimal or other \[dq]solutions\[dq] are
possible.
.IP
.nf
\f[C]
192.0.2.0/30-32
192.0.2.4/30,/31-31
\f[R]
.fi
.SS PS
.PP
PS1: And do not use this in your data structure lessons ...
there are better data structures for prefixes (radix tree / trie) than
an unbalanced tree with all intermediate nodes created ...
quick hack and so \[dq]easy\[dq] to understand aggregation, if you draw
it on a piece of paper ...
and still significant faster than most other aggregate tools.
.PP
PS2: Oh, yes, gcc knows 128bit integers, which would allow easier code
writing ...
but other compilers like Sun Studio don\[aq]t ...
.PP
PS3: This is somewhat old code ;-)
.SS Bugs
.PP
Please report bugs at <https://github.com/FvDxxx/pfxaggr/issues>
.SS Author
.PP
Markus Weber <[email protected]>