'\" et .TH BGPGREP 1 @VERSION@ BGPGREP "User Commands" .\" .SH NAME @UTILITY@ \(em filter and print BGP data within MRT dumps .SH SYNOPSIS .LP .nf @UTILITY@ \fB[\fIOPTIONS\fB]\fR... \fB[\fIFILES\fB]\fR... \fB[\fIEXPRESSION\fB] .fi .SH DESCRIPTION The .IR @UTILITY@ utility reads each possibly compressed Multithreaded Routing Toolkit (MRT) dump file specified by .IR FILES and formats its contents to standard output. .IR @UTILITY@ may optionally evaluate a predicate defined by .IR EXPRESSION over every MRT record containing a BGP message. Whenever such predicate evaluates as false the relevant BGP message is discarded from output (see the .IR EXAMPLES section below). .P .IR EXPRESSION predicates only affect BGP messages output, other kind of information, such as state changes, is always printed by .IR @UTILITY@ regardless of any filtering rule. .P .IR @UTILITY@ prints diagnostics to standard error, it detects and tolerates data corruption as much as possible. Corruption within a BGP message causes only the affected message to be dropped. Unrecoverable corruption within the entire MRT dump file causes the whole file to be dropped, .IR @UTILITY@ will then move to the next file in .IR FILES , if any. .P Such events are always reported with reasonable diagnostic errors. Parsed data up to the corruption point may still be printed to standard output. .SH OPTIONS .IR @UTILITY@ expects its options before the .IR FILES list. This is due to the fact that .IR @UTILITY@ must distinguish between options and its expression predicate (see the .IR OPERANDS section below, for details on how .IR @UTILITY@ makes such distinction). .P The following options are supported: .IP "\fB\-\-dump\-bytecode\fP" 10 Debug option, causes .IR @UTILITY@ to dump its filtering engine bytecode to standard error before starting MRT dump files processing. .IP "\fB\-\-no\-color\fP" 10 .IR @UTILITY@ may ease visualization by surrounding some output with color escape sequences, on terminals that support this feature. This option forces colored text output off. .IP "\fB\-h or \-\-help\fP" 10 Prints a short help message, summarizing .IR @UTILITY@ functionality. .IP "\fB\-?\fP" 10 Equivalent to .BR \-h . .SH OPERANDS .IR @UTILITY@ interprets all its operands up to but not including the first operand that starts with a `\-' , or is a `(' or a `!', as the .IR FILES operand. Each of these operands are pathnames to a MRT dump file to be processed. An actual `\-' is a placemarker to read uncompressed MRT data from standard input at that point during processing (see .IR STDIN section below). .P The first operand that starts with a `\-' , or is a `(' or a `!', and any subsequent arguments, are interpreted as an .IR EXPRESSION predicate. Legal predicates are composed of the following terms: .IP "\fB\-type\ \fImsg\-type\fR" 10 Evaluates as true if the BGP message type matches .IR `msg\-type' . Message types may be provided by a human readable type name, as defined by .IR "RFC 4271" ", " "Section 4" (e.g. OPEN, UPDATE), or any other relevant RFC defining the message type (e.g. ROUTE_REFRESH). An explicit numeric code may also be provided (e.g. 1 as an equivalent to OPEN). .IP "\fB\-attr\ \fIattribute\-type\fR" 10 Evaluates as true if the BGP message is an UPDATE containing a path attribute of type .IR `attribute\-type' . The attribute type may be specified by a human readable name, as defined by .IR "RFC 4271" ", " "Section 5.1" (e.g. AS_PATH, ATOMIC_AGGREGATE), or any other relevant RFCs defining the interesting path attribute (e.g. COMMUNITY). An explicit numeric code may also be provided (e.g. 8 as an equivalent to COMMUNITY), which is especially useful to specify non-standard path attributes. .IP "\fB\-aspath\ \fIpattern\fR" 10 Evaluates as true if the BGP message is an UPDATE with an AS_PATH that matches the regular expression specified by .IR `pattern' . See the .IR "AS_PATH REGULAR EXPRESSIONS" section below for details. .IP "\fB\-peer\ \fIpeer\-expression\fR" 10 Evaluates as true if .IR `peer\-expression' matches the peer that provided the BGP data. This term matches the PEER field as displayed by the .IR "LINE ORIENTED OUTPUT" format (see section below for details). Supported peer matching expressions are documented in the .IR "PEER MATCHING EXPRESSIONS" section below. .IP "\fB\-loops\fR" 10 Evaluates as true if BGP message is an UPDATE whose AS_PATH contains loops. .IP "\fB\-exact\ \fIprefix\-expression\fR" 10 Evaluates as true if BGP message is an UPDATE and contains at least one of the relevant networks of interest specified in .IR `prefix\-expression' . See .IR "PREFIX MATCHING EXPRESSIONS" section for details. .IP "\fB\-supernet\ \fIprefix\-expression\fR" 10 Similar to .BR \-exact , but evaluates as true if BGP message contains supernets of the relevant networks of interest, or the actual networks themselves. .IP "\fB\-subnet\ \fIprefix\-expression\fR" 10 Similar to .BR \-exact, but evaluates as true if BGP message contains subnets of the relevant networks of interest. .IP "\fB\-related\ \fIprefix\-expression\fR" 10 Similar to .BR \-exact but evaluates as true if BGP message contains prefixes related to the relevant networks of interest. A related network is defined to be either a subnet or a supernet of the specified prefix. .IP "\fB\-timestamp\ \fItime\-expression\fP" 10 Evaluates as true if the timestamp at which the BGP data was originated or collected matches the specified .IR 'time\-expression' . Accepted expressions are described in the .IR "TIMESTAMP MATCHING EXPRESSIONS" section. .IP "\fB\-communities\ \fIcommunities\-expression\fP" 10 Evaluates as true if BGP message is an UPDATE whose path attributes contains at least one community specified within .IR 'communities\-expression' , see the .IR "COMMUNITY MATCHING EXPRESSIONS" section below for details. .IP "\fB\-all\-communities\ \fIcommunities\-expression\fP" 10 Similar to .BR \-communities , but requires all communities inside .IR `communities\-expression' to be present inside UPDATE message path attributes. .P Terms can be combined with the following operators (in order of decreasing precedence): .IP "(\ \fIexpression\fR\ )" 10 Evaluates as true if expression is true, may be used to explicitly control precedence. .IP "\fB!\ \fIexpression\fR\ or\ \fB-not\ \fIexpression\fR" 10 Negation of expression; the unary NOT operator. .IP "\fIexpression\ \fB[\-a]\ \fIexpression\fR\ or\ \fIexpression \fB[\-and]\ \fIexpression\fR" 10 Conjunction of expressions; the AND operator is implicit if no other operator is provided inbetween two consecutive expressions, but can be made explicit by explicitly inserting the .BR \-a or .BR \-and operators. The second expression is not evaluated if the first one is false. .IP "\fIexpression\ \fB\-o\ \fIexpression\fR\ or\ \fIexpression\ \fB\-or\ \fIexpression\fR" 10 Alternation of expressions; the OR operator. The second expression is not evaluated if the first one is true. .SH "AS_PATH REGULAR EXPRESSIONS" .IR @UTILITY@ uses a specialized regular expression (regexp) style pattern matching approach for AS_PATH. .P AS_PATH regular expressions support most features found in string pattern matching, except backreferences, classes and counted repetition. .P ASN are specified by a numeric value, for example 19819 represents AS19819. In their simplest form, AS_PATH expressions match an ASN sequence against the merged BGP data AS_PATH (as specified by .IR "RFC 4893" ), indipendently by its starting position. In the same way a regexp would match a string of characters. For example `19819 172' matches AS_PATH `AS121 .BR AS19819 .BR AS172 AS1111'. .P The following features, commonly found in regular expressions, are supported by .IR @UTILITY@ : .IP "\fIComplements" 10 The prefix `!' operator can be used to match any but the specified ASN, for example `!871' matches any ASN but AS871. .IP "\fIAnchors" 10 `^' and `$' assume a special meaning, they match with the beginning and the end, respectively, of the AS_PATH. This allows to assert a particular position within the AS_PATH at which an ASN sequence is supposed to appear. .IP "\fIGrouping and alternation" 10 Groups can be defined inside regexp by enclosing them inside parentheses, for example `( 202 397 )' defines a group with the single ASN sequence `AS202 AS397'. The alternation operator `|' provides additional flexibility, allowing multiple sequences inside groups, like `( 202 397 | 1111 5439 )', which would match both `AS1921 .BR AS202 .BR AS397 ' and `AS2431 .BR AS1111 .BR AS5439 AS79'. Alternation can be used even outside groups and alternatives may very well be more than two. Groups may be nested. .IP "\fIMetacharacters" 10 The `.' metacharacter can be used to match any ASN in its position. The metacharacters `*', `?' and `+' are repetition operators, they can be used to match the preceding ASN or group multiple times in different ways. `191*' matches AS191 zero or more times, `191?' matches AS191 zero or one time, while `191+' matches AS191 one or more times. .P These features may be combined at will to provide powerful expressions, for example `^ !432' matches any AS_PATH that does not start with AS432. .P Extensive usage examples can be found in the .IR EXAMPLES section. .SH "PEER MATCHING EXPRESSIONS" Peer matching expressions specify a set of relevant peers, either by providing their IP address, their ASN, or both. The constructed set is then matched against the peer providing the BGP data inside the MRT input files. .P Allowed constructs are: .IP "\fIpeer\-asn\fR" 10 Only peer ASN is matched for equality. .IP "\fIpeer\-address\fR" 10 Only peer IP address is matched for equality. .IP "\(dq\fIpeer\-address\ \fIpeer\-asn\fR\(dq" Both peer IP address and ASN are tested for equality. .P When both IP address and ASN are provided, the match should be quoted so that it is understood to be a single match as opposed to one match by peer address followed by another match by peer ASN. .P Multiple peer matches can be provided at the same time by enclosing them in parentheses, for example `( \(aq199036\(aq \(aq173.2.2.1 7566\(aq )' matches both peer AS199036 and peer AS7566 with IP address 173.2.2.1. .P Whenever a peer matching expression is expected, a filepath to a text file may be specified in its place. In this case .IR @UTILITY@ will read the peer matches directly from file. Matches inside file may be separated by either spaces or newlines. No parentheses are necessary, though quoting may still be necessary for matches specifying both peer address and ASN. Typical C and C++ style comments are supported within the file. .P See the .IR EXAMPLES section for usage examples. .SH "COMMUNITY MATCHING EXPRESSIONS" COMMUNITY matching expressions define a set of interesting communities. Communities may be specified in any of the following ways: .IP \[bu] A well-known COMMUNITY name (e.g. BLACKHOLE for COMMUNITY 0xFFFF029A). .IP \[bu] A hexadecimal numeric COMMUNITY code (e.g. 0xFFFFFF01 for NO_EXPORT). .IP \[bu] The canonical representation of a COMMUNITY as two fields separated by `:', such as `65535:65282' for NO_ADVERTISE. In this form either one of the two field, but not both, may be left unspecified by marking it with `*'. In this case, communities will be matched only against the specified portion. For example `65535:*' matches any COMMUNITY whose first two octets match 65535. .P Multiple communities may be listed by enclosing them in parentheses, for example `( \(aq65535:*\(aq \(aq0:*\(aq )' matches any reserved COMMUNITY as per .IR "RFC 1997" . .P Whenever a community matching expression is expected, a filepath to a text file may be provided in its place. In this case .IR @UTILITY@ will parse the communities from the file itself. Each COMMUNITY inside file may be separated by either spaces or newlines. No parentheses are required. Typical C and C++ style comments are supported within the file. .P See the .IR EXAMPLES section for usage examples. .SH "PREFIX MATCHING EXPRESSIONS" Prefix matching expressions define a set of interesting networks. Networks are specified as prefixes in their CIDR notation, for example 193.0.0.0/16 or 2001:67c::/32. If prefix length is not defined explicitly, it is taken to be the full IP address length, that is 32 for IPv4 addresses and 64 for IPv6 addresses. .P Prefix matching can be restricted to announcements or withdrawals. Syntax is: .IP "\fB+\fIprefix\fR" 10 Restrict matching to announcements only. .IP "\fB-\fIprefix\fR" 10 Restrict matching to withdrawals only. .P If none of `+' or `-' is prepended, then matching takes place on both announcements and withdrawals. .P Multiple prefixes can be specified at the same time by enclosing them in parentheses, for example: `( \(aq+193.0.0.0/16\(aq \(aq2001:67c::/32\(aq )'. .P Whenever a prefix matching expression is expected, a filepath to a text file may be specified in its place. In this case .IR @UTILITY@ will parse the relevant prefixes from the file itself. Inside file, prefixes may be separated by either spaces or newlines. No parentheses are required. Typical C and C++ style comments are supported within the file. .P See the .IR EXAMPLES section for usage examples. .SH "TIMESTAMP MATCHING EXPRESSIONS" Timestamp matching expressions define a time point and a matching direction. Expressions are matched either to the MRT header timestamp, in case of BGP4MP and ZEBRA records (commonly referred to as updates), or to the ORIGINATED field in case of TABLE_DUMPV2 or TABLE_DUMP snapshots (commonly referred to as RIB snapshots). Timestamps may be specified in either of the two following formats: .IP \[bu] A .IR "Unix timestamp" in its explicit numeric representation, such as `1622725323', which is equivalent to `2021\-06\-03 13:02:03 GMT'. Microsecond resolution may be added appending a followed by the subsecond part, such as `1622725323.000030'. .IP \[bu] A human readable .IR "RFC 3339" UTC timestamp. This format is commonly found in JSON. For example `1985\-04\-12T23:20:50.52Z' . .P Matching direction may be any of the following: .IP "\fB>=\fItimestamp\fR" 10 Matches if BGP data was originated after or exactly at the relevant timestamp. .IP "\fB>\fItimestamp\fR" 10 Matches if BGP data was originated after the relevant timestamp. .IP "\fB=\fItimestamp\fR" 10 Matches if BGP data was originated exactly at the relevant timestamp. .IP "\fB<\fItimestamp\fR" 10 Matches if BGP data was originated before the relevant timestamp. .IP "\fB<=\fItimestamp\fR" 10 Matches if BGP data was originated before or exactly at the relevant timestamp. .P If no matching direction is provided, `=' is implicitly assumed. See the .IR EXAMPLES section for usage examples. .SH "LINE ORIENTED OUTPUT" .IR @UTILITY@ prints each MRT record into multiple lines, each one representing either .BR "ROUTE INFORMATION" or .BR "BGP SESSION STATUS" . .P .BR "ROUTE INFORMATION" can be either an announcement, a route withdrawn or a routing table (RIB) snapshot. Each .BR "ROUTE INFORMATION" line is a sequence of the following `|' separated fields: .RS 4 .sp .RS 4 .nf TYPE|PREFIXES|PATH ATTRIBUTES|PEER|TIMESTAMP|ASN32BIT .fi .P .RE .P Fields have the following meaning: .IP "\fBTYPE\fR" 4 Single character describing the route information type, may be `=' (RIB snapshot entry), `+' (announcement), or `-' (withdrawn). .IP "\fBPREFIXES\fR" 4 The list of prefixes carried into the message. If the information is an announcement, then this enumerates the prefixes within NLRI and MP_REACH_NLRI fields. If the information is a withdrawn, then this enumerates the prefixes within WITHDRAWN_ROUTES and MP_UNREACH_NLRI fields. If the information is a RIB snapshot entry, then this is the prefix related to the current RIB entry. Multiple prefixes are separated by a single space. .IP "\fBPATH ATTRIBUTES\fR" 4 This is a `|' separated list of the most common BGP path attributes characterizing a route. Each field is left empty if the corresponding path attribute is not present in the collected BGP data (e.g. route announcements without optional attributes, or route withdrawals). The currently displayed path attributes are: .RS 4 .sp .RS 4 .nf AS_PATH|NEXT_HOP|ORIGIN|ATOMIC_AGGREGATE|AGGREGATOR|COMMUNITIES .fi .P .RE .P If the BGP peer does not support ASN32BIT capability, then the AS_PATH field contains the result of the merging procedure between AS_PATH and AS4_PATH attributes, according to .IR "RFC 4893" , and the AGGREGATOR field contains the AS4_AGGREGATOR attribute (if present). Otherwise, AS_PATH and AGGREGATOR fields contain the respective attribute. .P NEXT_HOP field contains either the NEXT_HOP attribute (IPv4) or the next hop address(es) listed into the MP_REACH_NLRI attribute (IPv6), as described in .IR "RFC 4760" . .P ORIGIN contains the corresponding attribute encoded as a single character, `i' (IGP), `e' (EGP), `?' (INCOMPLETE). .P ATOMIC_AGGREGATE field contains .BR "AT" if the attribute is set, it is left empty otherwise. .P COMMUNITIES field contains both COMMUNITY ( .IR "RFC 1997" ) and LARGE_COMMUNITY ( .IR "RFC 8092" ) displayed in their canonical representation. Well\-known communities are displayed according to their IANA assigned names (e.g. NO_EXPORT instead of `65535:65281'). .P .RE .IP "\fBPEER\fP" 4 The BGP peer that provided the BGP message. If the peer uses the ADD\-PATH extension ( .IR "RFC 7911" ) to announce BGP data, then it is displayed as `peer\-address peer\-asn path\-id', otherwise as `peer\-address peer\-asn'. .IP "\fBTIMESTAMP\fP" 4 Displays the Unix epoch time at which the information was collected. If extended timestamp information is available, the Unix Epoch time is followed by a `.' and the microsecond precision is appended right after it. Timestamp is displayed as a raw numerical value. .IP "\fBASN32BIT\fP" 4 May be either 1, if BGP data has ASN32BIT capability, or 0. .P .RE The .BR "BGP SESSION STATUS" is encoded as a BGP session state change according to .IR "RFC 6936" ", " "Section 4.4.1" . The format of a line representing a state change is the following: .RS 4 .sp .RS 4 .nf #|OLD_STATE-NEW_STATE|||||||PEER|TIMESTAMP|ASN32BIT .fi .P .RE .P Each field has the following format: .IP "\fBOLD_STATE\-NEW_STATE\fP" 4 Represents the old and new state of the BGP session respectively, according to the BGP Finite State Machine states numerical codes. .IP "\fBPEER, TIMESTAMP, ASN32BIT\fP" 4 Have identical format and meaning with regards to the .BR "ROUTING INFORMATION" case. .P .RE Each line produced always has the same `|' character count, in both .BR "ROUTING INFORMATION" 's and .BR "BGP SESSION STATUS" 's case. This facilitates the task of writing simple scripts that manipulate .IR @UTILITY@ 's output text. .SH "EXIT STATUS" The following exit values are returned: .IP "\00" 6 All input data was scanned successfully, and data was written to output correctly. .IP >0 6 Errors were detected in input data, write error occurred, or an unrecoverable error occurred (such as out of memory errors). .SH STDIN The standard input is used only if no .IR FILES arguments are provided, or when any of the specified .IR FILES arguments is `\-' , in which case MRT data is read from standard input at that point, up to an . .P Whenever .IR @UTILITY@ reads from standard input, MRT data is assumed to be uncompressed. .SH "INPUT FILES" .IR @UTILITY@ supports most MRT dump formats as written by the majority of Route Collecting projects (see the .IR STANDARDS section below for additional references). MRT dumps may be provided either in their plain uncompressed form, or as files compressed by .IR gzip (1), .IR bzip2 (1), or .IR xz (1). .IR @UTILITY@ performs appropriate decompression on the fly. File extension is used, in a case insensitive way, to discriminate among supported compression formats. If the file extension is not recognized, or there is no extension, then it is assumed to be uncompressed. .SH STDOUT The standard output is used to print a human readable text representation of BGP message data, nothing else shall be written to the standard output. .IR @UTILITY@ may detect and treat as error whenever the standard output is a regular file, and is the same file as any of the .IR FILES arguments. The default output format used by .IR @UTILITY@ is documented in the .IR "LINE ORIENTED OUTPUT" section. .SH STDERR The standard error is used only for diagnostic messages and error reporting. Any BGP message output is exclusive to standard output. .SH EXAMPLES This section contains some useful examples, starting from trivial ones, demonstrating basic .IR @UTILITY@ usage, to more complex ones employing sophisticated filtering predicates. Examples in this section use paranoid quoting, since this a worthwhile habit that eliminates potential pitfalls introduced by shell expansion. .IP \[bu] The following is the simplest way to invoke .IR @UTILITY@ : .nf \& .in +2m @UTILITY@ .in \& .fi It formats and prints all the BGP data it inside the uncompressed MRT input data it receives from standard input. .IP \[bu] The following command: .nf \& .in +2m @UTILITY@ -- -peer \(aq199036\(aq .in \& .fi finds all BGP data announced by peer AS199036, taking MRT input data implicitly from standard input. Notice how an explicit `\-\-' is necessary for .IR @UTILITY@ to interpret .BR \-peer as an actual .IR EXPRESSION operand, rather than incorrectly mistaking it for .IR OPTIONS. .IP \[bu] The following is equivalent to the previous example: .nf \& .in +2m @UTILITY@ ./rib.1.bz2 -peer \(aq199036\(aq .in \& .fi but takes MRT input data from a .IR bzip (1), compressed file. The file argument removes the necessity of an explicit `\-\-' to separate .IR FILES and .IR EXPRESSION operands. .IP \[bu] The following command: .nf \& .in +2m @UTILITY@ ./updates.*.gz -aspath \(aq^199036\(aq .in \& .fi finds every message whose first ASN in AS_PATH is AS199036, inside all .IR gzip (1) compressed files resulting from the glob expansion. .IP \[bu] The following command: .nf \& .in +2m @UTILITY@ ./updates.*.gz -aspath \(aq3333$\(aq .in \& .fi is similar to the previous example, but uses .IR "AS_PATH REGULAR EXPRESSIONS" to find every BGP message whose last ASN in AS_PATH is AS3333. .IP \[bu] The following command: .nf \& .in +2m @UTILITY@ ./updates.*.gz -aspath \(aq174 3356\(aq .in \& .fi demonstrates yet another basic use of .IR "AS_PATH REGULAR EXPRESSIONS" to find every BGP message whose AS_PATH crosses link AS174 AS3356. Notice how the argument of .BR \-aspath needs quoting. .IP \[bu] The following command demonstrates a more advanced use of .IR "AS_PATH REGULAR EXPRESSIONS": .nf \& .in +2m @UTILITY@ ./updates.*.gz -aspath \(aq174 (2603+|202+|303+) 3356\(aq .in \& .fi It finds every BGP message whose AS_PATH crosses AS174 and AS3356, through one intermediate ASN among AS2603, AS202, or AS303. It also takes care of possible prepending for the inbetween ASN. .IP \[bu] The following commands are equivalent: .nf \& .in +2m @UTILITY@ ./updates.*.gz -aspath \(aq^7854 .* 5032$\(aq -or -aspath \(aq109 .* 9081$\(aq @UTILITY@ ./updates.*.gz -aspath \(aq^7854 .* 5032$ | ^109 .* 9081$\(aq .in \& .fi They both find every BGP message whose AS_PATH starts at AS7854 and terminates at AS5032, or starts at AS109 and terminates at AS9081. The second being the most efficient. This example illustrates the use of alternation inside .IR "AS_PATH REGULAR EXPRESSIONS" to test multiple patterns at the same time. .IP \[bu] The following example: .nf \& .in +2m @UTILITY@ ./rib.*.xz -subnet \(aq192.65.0.0/16\(aq -aspath \(aq174 137\(aq .in \& .fi finds all subnets of 192.65.0.0/16 crossing link AS174 AS137. It combines two .IR EXPRESSION terms with an implicit AND operator, since no explicit .BR \-and and no .BR \-or was provided, as detailed by the .IR OPERANDS section. .IP \[bu] The following commands are equivalent: .nf \& .in +2m @UTILITY@ ./rib.*.gz \e( -subnet \(aq193.0.0.0/16\(aq -or -subnet \(aq2001:67c::/32\(aq \e) -aspath \(aq3333$\(aq @UTILITY@ ./rib.*.gz -subnet \e( \(aq193.0.0.0/16\(aq \(aq2001:67c::/32\(aq \e) -aspath \(aq3333$\(aq .in \& .fi They both print every message containing subnets of 193.0.0.0/16 or 2001:67c::/32 destinated to AS3333, the second being a more efficient alternative. In the latter, notice the use of `(' and `)' inside .BR \-subnet to provide multiple arguments. This behavior is further explained in the .IR "PREFIX MATCHING EXPRESSIONS" section, and is common to most matching expressions provided by .IR @UTILITY@ . .IP \[bu] The following command: .nf \& .in +2m @UTILITY@ ./rib.*.bz2 -peer \(aq202\(aq -timestamp \(aq>=2012-10-01\(aq -timestamp \(aq<2012-11-01\(aq -loops .in \& .fi is another example combining multiple .IR EXPRESSION terms to achieve complex filtering. It scans all .IR bzip2 (1) compressed MRT input files resulting from glob expansion, and prints every BGP message provided by peer AS202 during the month of October, 2012 containing loops in its AS_PATH. Notice how multiple .BR \-timestamp terms can be combined to effectively define bounded time ranges. .IP \[bu] The following command: .nf \& .in +2m @UTILITY@ ./rib.*.bz2 -communities \e( \(aq0:*\(aq \(aq65535:*\(aq \e) -peer \(aq185.169.236.135 201\(aq .in \& .fi prints all the BGP messages containing reserved communities, provided by peer AS201 with IP address 185.169.236.135. .IP \[bu] The following command: .nf \& .in +2m @UTILITY@ ./rib.*.bz2 -all-communities ./commlist.tpl -subnet ./netlist.tpl .in \& .fi demonstrates the use of filepath arguments for .BR \-all\-communities and .BR \-subnet .IR EXPRESSION terms. .IR bgpgrep will parse the two text files and use their contents as arguments. This is especially useful to create templates containing relevant networks, communities, or peers and reuse them across various runs. .SH "APPLICATION USAGE" The .IR @UTILITY@ utility and its filtering engine have been designed for performance. Providing predicates has the double role of cleaning the output of irrelevant data, without resorting to complex scripting, and avoid wasting time to decode useless data. Therefore .IR @UTILITY@ can gain a lot performance\-wise when provided with restrictive predicates, that cut away significant amounts of BGP data from its input files. .P .IR @UTILITY@ deliberately mimics the .IR find (1) utility operands convention, in an attempt to feel familiar to the experienced shell user and provide a powerful .IR EXPRESSION syntax that feels both expressive and readable. Though, many of .IR find (1)'s subtleties also apply to .IR bgpgrep . When writing .IR EXPRESSION , it should be noted that `!', `(', `<' and `>' have special meaning to the shell, and should be quoted accordingly. .IR @UTILITY@ provides the alternative .BR \-not syntax for the unary NOT .BR ! operator that avoids the problem. Still, care should be used with other .IR EXPRESSION terms arguments. When in doubt use explicit quotes, as demonstrated in the .IR EXAMPLES section. .P .IR @UTILITY@ attempts to provide descriptive output for syntax errors that should help with most of these problems. .P Another common source of errors is the distinction between .IR FILES and .IR EXPRESSION . .IR bgpgrep treats any operand starting with `\-' and followed by at least one character as the beginning of an .IR EXPRESSION , and an actual `\-' as a placeholder for standard input (see .IR STDIN and .IR OPERANDS sections for details). In the unlikely event of having to deal with files that may generate ambiguity (e.g. a file named `\-'), make the file reference explicit by prepending `./' (e.g. `./\-' to reference a file named `\-' in the current directory). If the .IR FILES list should be left empty, but an .IR EXPRESSION should still be applied, then provide an explicit `\-\-' to mark the empty file list, as shown in the .IR EXAMPLES section. .SH SEE ALSO .IR awk (1), .IR grep (1) .SH STANDARDS The .IR @UTILITY@ utility conforms to: .IP \[bu] 2m .IR "RFC 6396" " \-" "Multi\-Threaded Routing Toolkit (MRT) Routing Information Export Format" .IP \[bu] 2m .IR "RFC 8050" " \- " "Multi\-Threaded Routing Toolkit (MRT) Routing Information Export Format with BGP Additional Path Extensions" .IP \[bu] 2m .IR "IANA Border Gateway Protocol (BGP) Well\-known Communities" ". Updated list of well\-known communities as of 2021\-05\-07." .SH AUTHOR .IR @UTILITY@ was written by .UR lcg@\:inventati.\:org Lorenzo Cogotti .UE . .IR @UTILITY@ is an evolution over .IR bgpscanner originally developed by the same author at the Institute of Informatics and Telematics of the Italian National Research Council (IIT\-CNR), with significant contributions by the Isolario project development team at the time.