| Previous | Table of Contents | Next |
Building Complex Regular Expressions
The special characters in table 5-4 can be used to build complex but very practical regular expressions. The caret (^) and ($) dollar sign are used to match the regular expression pattern against the beginning and the end of the input string. Other characters such as the asterisk (*), the plus sign (+), and the question mark (?) enable you to repeat the patterns inside the regular expression.
The following example matches any number of occurrences of the letter "a," including none:
- • a* is equivalent to any of the following: (nothing), a, aa, aaa, aaaa, and so on.
The following example requires that at least one letter "a" be present in the string to be matched:
- • a+ is equivalent to a, aa, aaa, aaaa, and so on.
The following is an example of a list that may or may not contain the letter "a:"
- • ba?b is equivalent to bb or bab.
To repeat instances of multiple-character patterns, the pattern is enclosed in parentheses; for example, the expression (ab)+ is equivalent to ab or abab.
The underscore character (_) matches the beginning of a string (^), the end of a string ($), parentheses (), space, braces, comma, or underscore. The dot character matches a single character, including a white space. Figure 5-26, table 5-5, and table 5-6 illustrate how characters can be strung together to create a useful regular expression.
)
Figure 5-26 Network topology for complex regular expression example.
Consider the network topology illustrated in figure 5-26. AS400, AS300, AS200, AS100, and AS50 are originating the routes NetA, NetB, NetC, NetD, and NetE, respectively. RTA in AS50 is receiving updates about all these networks from its neighbors AS100 and AS300. After running its BGP decision process, RTA has picked the best path to reach these networks according to table 5-5.
| Network | AS_path | |
|---|---|---|
| NetA | 300 400 | |
| NetB | 300 | |
| NetC | 100 200 | |
| NetD | 100 | |
| NetE | empty | |
Table 5-6 reflects the regular expressions that would be used to create possible route filtering arrangements that RTA could apply when propagating routes to the NAP.
| Routes to be Advertised from RTA to the NAP | Expression | Path Info | Outcome |
|---|---|---|---|
| Local routes only | ^$ | empty | NetE |
| All routes | .* | all paths | NetA, NetB, NetC, NetD, NetE |
| Routes that originated from directly connected customers | ^300$ ^100$ | 300 100 | NetB, NetD |
| Connected customer routes and their customers' routes | ^300_ ^100_ | 300 400 300 100 200 100 | NetA, NetB, NetC, NetD |
| Routes that originated in AS200 | _200$ | 100 200 | NetC |
| Routes that passed via AS100 | _100_ | 100 200 100 | NetC, NetD |
Notes:
The ^$ expression indicates an empty path list, which is actually the local routes. The ^ and $ define the border of the string, and the underscore, such as in _200$, limits the AS number to being exactly 200 and not 1200 or 2200.
Filtering based on AS_path information is quite effective because it filters all the routing updates that belong to the AS_path at the same time. Without this type of filtering, thousands of routes would have to be listed individually.
Peer Groups
A BGP peer group is a group of BGP neighbors that share the same update policies. Instead of defining the same policies for each individual neighbor, you define a peer group name and assign policies to the peer group itself. An administrator, for example, setting policies toward its BGP peers will most probably set the same policies toward the majority of its peers, and therefore will define them as a peer group.
Not only do peer groups save the operator from repetitive configuration of each BGP peer, they save the BGP router itself from the effort of parsing the policies sequentially for each neighbor. With peer groups, the router formulates the UPDATE once, based on the policies of the peer group, and then floods the same UPDATE to all the neighbors that fall within the group.
In figure 5-27, RTA has three internal peers with which it has the same internal policies. RTA also has three external peers with which it has the same policies. RTA's configuration includes two sets of peer groups, one for inside the AS and one for outside the AS. Each peer group contains the set of policies that RTA has toward its peers. These policies could be a set of IP prefix filters or AS_path filters and possible attribute manipulation. After the peer groups have been defined, these policies are applied to the neighbors that make up the peer group.
)
Figure 5-27 Peer group implementation.
Due to the route update optimization that peer groups offer, some restrictions need to be followed for peer groups to work correctly with external BGP peers. If the following guidelines are not followed, loss of routing information could occur.
When the peer group consists of external neighbors (EBGP), the following restrictions must apply:
- • The hub router (such as RTA in figure 5-27) cannot be a transit router for the external ASs. In other words, updates from one EBGP neighbor in the peer group should not be passed to other EBGP neighbors in the same peer group.
- • All the EBGP peer group members should belong to the same IP subnet.
Peer Group Exceptions
Exceptions occur when some neighbors inside a peer group have slightly different policies from other neighbors. Additional policies can be added to the neighbor to complement the set of policies that fall within the peer group. Assume that RTA requires an additional set of filters to be set toward its peer RTB. RTA can apply the extra filters toward RTB while still keeping RTB within the external peer group.
Troubleshooting:
Example: Ch. 10, pp. 312-315. Peer Groups
| Previous | Table of Contents | Next |