Security - Versatile Routing and Services with BGP: Understanding and Implementing BGP in SR-OS (2014)

Versatile Routing and Services with BGP: Understanding and Implementing BGP in SR-OS (2014)

Chapter 9. Security

While the use of BGP for delivering services within an Autonomous System has increased, it remains the de facto protocol for inter-AS route exchange, and as such BGP must run on routers that are at the extremity of an Autonomous System or administrative domain.

The point where the Autonomous System connects externally is frequently considered the security perimeter. Regardless of whether that external connection is a customer, a peering partner, a content provider, or something else, securing that perimeter against potential threats or attacks is of paramount importance. A number of mechanisms are in use today to implement security measures at the Autonomous System boundary, some simple and some a little more complex. This chapter looks at how BGP can be used both proactively and reactively to help secure the perimeter.

FlowSpec

BGP Flow Specification (FlowSpec) (RFC 5575) allows for encoding of flow specification information into Multi-Protocol BGP NLRI. A flow specification is an n-tuple consisting of several matching criteria such as source prefix, destination prefix, protocol, or ports that can be applied to IP traffic. Coupled with the flow specification information NLRI, Extended Community attributes provide the capability to define traffic filtering rules for the specified flow specification. The intention is to allow for automated creation of IP Filters to prevent intra-AS and inter-AS DDoS attacks, and to allow for redirection of traffic to other routing contexts (a “dirty” VRF) for the purpose of off-ramping to scrubbing devices.

Flow specifications are intended to be more specific routing entries to a unicast aggregate prefix that exists in the routing table. An aggregate unicast prefix may be received by peer m and installed in the RIB/FIB, but a flow specification rule may then be received by a different peer n that defines more specific flow rules resulting in a different forwarding behavior for this subset of traffic.

FlowSpec uses AFI 1 (IPv4) or AFI 2 (IPv6) with SAFI 133 (IPv4 dissemination of flow specification rules) or SAFI 134 (VPNv4 dissemination of flow specification rules) and all of these Address Families are supported in SR-OS. Unlike other Address Families, there is no strict requirement for the Next-Hop attribute to be present in UPDATE messages. If the application sourcing the UPDATE does not require Next-Hop information (that is, it is not in the data path), the Length of Next-Hop Address field in the MP_REACH_NLRI is set to zero and should be ignored on receipt.

Figure 9-1 FlowSpec NLRI

image

The FlowSpec NLRI consists of several optional sub-components encoded as <type, [operator, value]+> and these sub-components must follow strict type ordering if present. Table 9.1 lists the possible flow specification “match” criteria, and a given packet matches the flow specification only when it matches all of the components present in the flow specification. Because it is possible to encode multiple sub-components in the NLRI, the potential exists that more than one rule may match a particular flow. In this case, if the component types are different, the rule with the lowest numeric type value has higher precedence. If the component types are the same, a type-specific comparison is performed.

Table 9.1 Flow Specification Match Criteria

!

Type

Component

SR-OS Support

1

Destination Prefix

Yes

2

Source Prefix

Yes

3

IP Protocol

Yes

4

Port

Yes

5

Destination Port

Yes

6

Source Port

Yes

7

ICMP type

Yes

8

ICMP code

Yes

9

TCP flags

SYN/ACK

10

Packet Length

No

11

DiffServ Code Point

Yes

12

Fragment

Yes

With the traffic identified using the flow specification NLRI, the next step is to execute an action upon that traffic. To achieve this “filtering” action, a number of Extended Community attributes are defined as listed in Table 9.2. The Traffic Rate Extended Community contains a two-byte AS number followed by four bytes to specify the rate in bytes-per-second (in IEEE floating point format). A rate of zero is used to specify a drop action and is the only rate supported in SR-OS. The Traffic Action Extended Community consists of six bytes, of which only the two least significant bits of the last byte are currently defined. The “Terminal Action” or “T” bit, when set to 1, indicates that subsequent filtering rules should be applied and essentially represents a “next-entry” action. When this bit is set to zero, the evaluation of the traffic filter stops when this rule is applied. The “Sample” bit or “S” bit, when set to 1, enables traffic sampling and logging for this flow specification. The Redirect to VRF and Mark Traffic Class Extended Communities are self-explanatory with a Route Target value being used to define the target redirect VRF.

Table 9.2 Traffic Filtering Action Extended Communities

!

Type

Extended Community

SR-OS Support

0x8006

Traffic Rate

Yes

0x8007

Traffic Action

Yes

0x8008

Redirect to VRF

Yes

0x8009

Mark Traffic Class

Yes

To demonstrate the use of FlowSpec, I'll use the network topology illustrated in Figure 9-2. Routers R1, R2, R3, and R4 form part of AS 64496 and are IBGP peered with RR1 for IPv4 and FlowSpec Address Families. Router R1 is externally peered with R5 in AS 64510 and is learning prefix 172.16.0.0/20. Router R4 has a directly connected network of 172.31.100.0/24 while router R3 has a directly connected network of 172.31.200.0/24. Both have hosts connected at .1 and both routers are advertising their relevant prefixes into IBGP, which is in turn advertised to R5. In summary, there is IP connectivity between R5 and both internal hosts. A FlowSpec route-server is connected to router R2 using EBGP and is also configured to support IPv4 and FlowSpec Address Families.

Figure 9-2 FlowSpec Test Topology

image

The FlowSpec Address Family must be explicitly configured between the relevant peers to allow correct propagation of flow specification information. As with other Address Families, if this family is being added to an existing peer (or group of peers) it must be negotiated as a capability in an OPEN message and therefore triggers a NOTIFICATION/OPEN exchange.

Because router R1 is the peering router, it is the point where I'll apply the FlowSpec filters at ingress. To do this, simply enter the keyword flowspec in the sap ingress node as shown in Output 9-2. If no valid FlowSpec routes are present, this action essentially represents a “permit all” action.

Let's do some mitigation! First I'll show an example of a straightforward drop action at ingress (a blackhole mitigation), and then I'll show a redirect to VRF.

Output 9-1: flow-ipv4 Configuration

router

bgp

group "IBGP"

family ipv4 flow-ipv4

peer-as 64496

neighbor …

Output 9-2: FlowSpec Configuration at R1

service

ies 10 customer 1 create

interface "to-AS64510" create

address 192.168.0.2/30

sap 1/1/3:9.1 create

ingress

flowspec

exit

exit

exit

no shutdown

exit

Attack Mitigation with Blackhole Action

For the blackhole action mitigation, assume you learn that host 172.17.0.1 has launched a TCP-based attack on the internal host 172.31.100.1 (connected to R4). The decision is to simply drop traffic from this source prefix toward this destination prefix at the peering router, so the FlowSpec originator sources the relevant flowspec route into the network. Debug 9-1 shows the FlowSpec route as it is received at the peering router R1. Note the presence of the FlowSpec NLRI with the flow specification matching source/destination IP address and port, and the Extended Community indicating a traffic rate of zero. Also note the absence of the Next-Hop attribute.

Debug 9-1: “Drop” FlowSpec Route Received at R1

2 2013/06/21 10:26:52.76 UTC MINOR: DEBUG #2001 Base Peer 1: 192.0.2.12

"Peer 1: 192.0.2.12: UPDATE

Peer 1: 192.0.2.12 - Received BGP UPDATE:

Withdrawn Length = 0

Total Path Attr Length = 63

Flag: 0x90 Type: 14 Len: 14 Multiprotocol Reachable NLRI:

Address Family FLOW_IPV4

NLRI len: 13

dest_pref 172.31.100.1/32

src_pref 172.17.0.1/32

ip_proto [ == 6 ]

Flag: 0x40 Type: 1 Len: 1 Origin: 0

Flag: 0x40 Type: 2 Len: 6 AS Path:

Type: 2 Len: 1 < 64509 >

Flag: 0x40 Type: 5 Len: 4 Local Preference: 100

Flag: 0x80 Type: 9 Len: 4 Originator ID: 192.0.2.23

Flag: 0x80 Type: 10 Len: 4 Cluster ID:

192.0.2.12

Flag: 0xc0 Type: 16 Len: 8 Extended Community:

rate-limit: 0:0

"

The presence of the FlowSpec route in the RIB-IN with the NLRI subcomponents can be validated as shown in Output 9-3, while the application of the dynamic filter can be seen in Output 9-4. Note that the FlowSpec dynamic filter will be applied on every interface/SAP that is configured with the flowspec keyword. An attempt to source TCP packets from router R5 to host 172.31.100.1 proves unsuccessful, and the presence of ingress matches indicates that the filter is dropping packets and functioning as anticipated.

image

Static (explicitly configured) filters and dynamic filters (applied by FlowSpec) can coexist on an ingress interface. Preference is given to static filter while dynamic filters are applied at the end of the filter as fSpec-0-entry.

Output 9-3: RIB-IN for FlowSpec Routes at R1

*A:R1# show router bgp routes flow-ipv4

==============================================================================

BGP Router ID:192.0.2.22 AS:64496 Local AS:64496

==============================================================================

Legend -

Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid

Origin codes : i - IGP, e - EGP, ? - incomplete, > - best, b - backup

==============================================================================

BGP FLOW IPV4 Routes

==============================================================================

Flag Network Nexthop LocalPref MED

As-Path

------------------------------------------------------------------------------

u*>i -- 0.0.0.0 100 None

64509

Community Action: rate-limit: 0:0

NLRI Subcomponents:

Dest Pref : 172.31.100.1/32

Src Pref : 172.17.0.1/32

Ip Proto : [ == 6 ]

------------------------------------------------------------------------------

Routes : 1

==============================================================================

Output 9-4: Application of FlowSpec Filter at R1

*A:R1# show filter ip fSpec-0

======================================================================

IP Filter

======================================================================

Filter Id : fSpec-0 Applied : Yes

Scope : Template Def. Action : Forward

Radius Ins Pt: n/a

CrCtl. Ins Pt: n/a

RadSh. Ins Pt: n/a

Entries : 1 (insert By Bgp)

Description : IPv4 BGP FlowSpec filter for the Base router

----------------------------------------------------------------------

Filter Match Criteria : IP

----------------------------------------------------------------------

Entry : 32767 - inserted by BGP FLowSpec

Description : (Not Specified)

Log Id : n/a

Src. IP : 172.17.0.1/32

Src. Port : n/a

Dest. IP : 172.31.100.1/32

Dest. Port : n/a

Protocol : 6 Dscp : Undefined

ICMP Type : Undefined ICMP Code : Undefined

Fragment : Off Src Route Opt : Off

Sampling : Off Int. Sampling : On

IP-Option : 0/0 Multiple Option: Off

TCP-syn : Off TCP-ack : Off

Option-pres : Off

Match action : Drop

Ing. Matches : 3 pkts (258 bytes)

Egr. Matches : 0 pkts

======================================================================

Attack Mitigation with Redirect to VRF Action

After successfully mitigating a number of attacks, the example Service Provider has invested in a threat mitigation infrastructure. To direct targeted traffic toward this infrastructure, target traffic is off-ramped toward the scrubbing center at the point of ingress to the network using a “dirty VRF” and only returned back to the network after it has been scrubbed. In this case, the “dirty VRF” must exist on the router at which the filter is applied, and it must have Route Target import values that match the Route Target values signaled in the FlowSpec route. in addition, there must be some other minimal routing information within the redirect VRF (a mitigation-route) to attract the off-ramp traffic toward the scrubbing center. I won't cover that further because I'm not trying to describe a complete solution, just the operation of FlowSpec.

In this mitigation, the threat management infrastructure has detected an anomaly in the traffic profile between source 172.18.0.1 and internal host 172.31.200.1 and the possibility exists that an attack is underway. The decision is made to redirect all traffic between this source and destination to the scrubbing center, so the redirect-to-VRF FlowSpec route is sent from the FlowSpec originator. Debug 9-2 shows the route as it is received at router R1. On this occasion the Flowspec match criteria has changed, and the Extended Community indicates a redirect to a VRF with Route Target value 64496:100. This is a VPRN configured at R1 with service ID 100.

Debug 9-2: “Redirect to VRF” FlowSpec Router at R1

3 2013/06/21 10:26:52.75 UTC MINOR: DEBUG #2001 Base Peer 1: 192.0.2.12

"Peer 1: 192.0.2.12: UPDATE

Peer 1: 192.0.2.12 - Received BGP UPDATE:

Withdrawn Length = 0

Total Path Attr Length = 60

Flag: 0x90 Type: 14 Len: 11 Multiprotocol Reachable NLRI:

Address Family FLOW_IPV4

NLRI len: 10

dest_pref 172.31.200.1/32

src_pref 172.18.0.1/32

Flag: 0x40 Type: 1 Len: 1 Origin: 0

Flag: 0x40 Type: 2 Len: 6 AS Path:

Type: 2 Len: 1 < 64509 >

Flag: 0x40 Type: 5 Len: 4 Local Preference: 100

Flag: 0x80 Type: 9 Len: 4 Originator ID: 192.0.2.23

Flag: 0x80 Type: 10 Len: 4 Cluster ID:

192.0.2.12

Flag: 0xc0 Type: 16 Len: 8 Extended Community:

redirect-to-vrf:64496:100

"

Confirmation is made that the dynamic filter is correctly applied in Output 9-5. Note that SR-OS automatically associates the signaled Route Target value with the configured service ID with that Route Target import value in the Fwd Rtr/SvcID field. Finally, with the dynamic filter in place, an attempt to source IP packets from router R5 to host 172.31.200.1 proves unsuccessful, and the presence of ingress matches indicates that the filter is redirecting packets to VPRN 100 and functioning as anticipated.

Output 9-5: “Redirect to VRF” Dynamic Filter at R1

*A:R1# show filter ip fSpec-0

======================================================================

IP Filter

======================================================================

Filter Id : fSpec-0 Applied : Yes

Scope : Template Def. Action : Forward

Radius Ins Pt: n/a

CrCtl. Ins Pt: n/a

RadSh. Ins Pt: n/a

Entries : 1 (insert By Bgp)

Description : IPv4 BGP FlowSpec filter for the Base router

----------------------------------------------------------------------

Filter Match Criteria : IP

----------------------------------------------------------------------

Entry : 49151 - inserted by BGP FLowSpec

Description : (Not Specified)

Log Id : n/a

Src. IP : 172.18.0.1/32

Src. Port : n/a

Dest. IP : 172.31.200.1/32

Dest. Port : n/a

Protocol : Undefined Dscp : Undefined

ICMP Type : Undefined ICMP Code : Undefined

Fragment : Off Src Route Opt : Off

Sampling : Off Int. Sampling : On

IP-Option : 0/0 Multiple Option: Off

TCP-syn : Off TCP-ack : Off

Option-pres : Off

Match action : Forward

Fwd Rtr/SvcId: 100

Ing. Matches : 3 pkts (258 bytes)

Egr. Matches : 0 pkts

======================================================================

FlowSpec validation is enabled at the BGP, group, or neighbor level using the command flowspec-validate. It can be useful when FlowSpec routes are advertised between Autonomous Systems, and a trust relationship exists between those Autonomous Systems. This allows a FlowSpec route-server from outside the Autonomous System to install a dynamic filter on a router within the local Autonomous System, only if the originator of that FlowSpec route is also the originator of the destination prefix in the FlowSpec NLRI. This allows the dynamic filter to be installed at the point closest to the source of the attack.

Output 9-6: flowspec-validate Configuration

bgp

group "EBGP"

family ipv4 flow-ipv4

neighbor 192.168.0.4

peer-as 64510

flowspec-validate

exit

exit

no shutdown

By way of a short example, the FlowSpec originator connected to R4 sends a FlowSpec route for destination prefix 172.31.250.0/24. This flow information contains a destination prefix that is not advertised in unicast IPv4 by the FlowSpec originator (or by any BGP speaker). As a result, R4 considers the FlowSpec route inactive. Note the 1/0/0 value in the Rcv/Act/Sent column against FlowIPv4 in Output 9-7.

Output 9-7: Inactive FlowSpec Route at R4

*A:R4# show router bgp summary | match "Neighbor" post-lines 6

Neighbor

AS PktRcvd InQ Up/Down State|Rcv/Act/Sent (Addr Family)

PktSent OutQ

-------------------------------------------------------------------------

10.10.10.1

64509 73 0 00h00m15s 2/1/0 (IPv4)

7 0 1/0/0 (FlowIPv4)

Now the FlowSpec Originator also sources an IPv4 UPDATE for prefix 172.31.250.0/24. Because this is the best path that R4 has toward that unicast prefix, and it is the same as the originator of the FlowSpec route, the FlowSpec route now can be considered active.

Output 9-8: Active FlowSpec Route at R4

*A:R4# show router bgp summary | match "Neighbor" post-lines 6

Neighbor

AS PktRcvd InQ Up/Down State|Rcv/Act/Sent (Addr Family)

PktSent OutQ

-------------------------------------------------------------------------

10.10.10.1

64509 78 0 00h00m08s 3/2/0 (IPv4)

11 0 1/1/0 (FlowIPv4)

Remote Triggered Blackholing

Unicast RPF (URPF) is an optional and configurable feature whereby the source address of an ingress IP packet is verified against the routing table to verify that it was received on the router's best path to that source address. URPF (RFC 3704) helps to mitigate problems with spoofed IP addresses that lack a verifiable IP source address (or rapidly changing source IP addresses). It is an optional security mechanism that can be used to dynamically create filters on external interfaces, not using explicitly defined filter rules like FlowSpec, but instead using the routing table to create a blackhole for traffic with specific destination addresses.

SR-OS supports two modes of URPF; strict and loose. In the strict mode a lookup is made in the routing-table for the source IP address, and verification is made that the best route to the source is over the interface from which the packet arrived. If not, the packet is dropped. In the loose mode a lookup is made in the routing-table for the source IP address, and verification is made that a route exists in the routing-table, but not necessarily over the interface over which the packet arrived. The loose mode of URPF helps to deal with problems in strict mode in the presence of asymmetry where redundant paths are available to a given source address.

URPF is an integral part of providing an optional security mechanism at the network boundary (that is, facing external peers) using Remote-Triggered Black-Hole (RTBH) filtering. The loose mode of URPF is sufficient for RTBH filtering and is applied at interface level using the commandurpf-check as shown in Output 9-9.

Output 9-9: URPF Configuration

service

ies 10 customer 1 create

interface "to-AS64510" create

urpf-check

mode loose

exit

exit

The next step to enabling RTBH capability is to configure a static-route for a 32-bit IPv4 address with a destination of blackhole.

Output 9-10: Static Route to Black-Hole for RTBH Filtering

router

autonomous-system 64496

static-route 192.0.2.254/32 black-hole

When the URPF check and static route to blackhole are in place, it is possible to announce bogons or other known bad source addresses into IPv4 IBGP (with the well-known attribute “no-export”) so that they are learned by routers with external interfaces. When announcing these prefixes, the BGP Next-Hop attribute should correspond with the preconfigured static-route to black-hole.

To show an example, I'll use the same topology I used for FlowSpec (Figure 9-2) where router R1 is externally peered with router R5 in AS 64510. Router R1 is learning the prefix 172.16.0.0/20 from R5 and is advertising the internal prefixes 172.31.100.0/24 and 172.31.200.0/24 to R5. URPF in loose mode is enabled at R1 on the external interface toward R5, and a static route to black-hole is configured for prefix 192.0.2.254.

In the example, I want to ensure that no traffic enters the network at R1 from R5 with a source-address of 10.0.0.0/8. To achieve this, router R2 (or any other internal router) sources a BGP UPDATE for prefix 10.0.0.0/8 and sets the Next-Hop to 192.0.2.254 to reconcile with the static route to blackhole at R1.

Output 9-11: RTBH Dynamic Filter

*A:R1# show router bgp routes 10.0.0.0/8

============================================================================

BGP Router ID:192.0.2.22 AS:64496 Local AS:64496

============================================================================

Legend -

Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid

Origin codes : i - IGP, e - EGP, ? - incomplete, > - best, b - backup

============================================================================

BGP IPv4 Routes

============================================================================

Flag Network LocalPref MED

Nexthop Path-Id Label

As-Path

----------------------------------------------------------------------------

u*>i 10.0.0.0/8 100 None

192.0.2.254 None -

No As-Path

----------------------------------------------------------------------------

Routes : 1

============================================================================

When packets arrive at R1's external interface, the URPF check verifies that the packet is received over the router's best path to that source address. In this case, the prefix 10.0.0.0/8 is known with Next-Hop 192.0.2.254 with a preferred path to blackhole. Hence, ingress packets are discarded because of the URPF check as shown in Output 9-12.

Output 9-12: URPF-Check Failure Verification

*A:R1# show router interface "to-AS64510" detail | match uRPF

uRPF Chk : enabled uRPF Chk Mode : loose

uRPF Ipv6 Chk : disabled

uRPF Chk Fail Pk*: 5 uRPF Fail Bytes : 420

uRPF Fail V4 Pk : 5 uRPF Fail V4 Byt : 420

uRPF Fail V6 Pk : 0 uRPF Fail V6 Byt : 0

Bogons, other known “bad” source prefixes, now can be announced into IBGP from a centralized route-server with the same Next-Hop address to create a dynamic method of generating filters on external interfaces.

Generalized TTL Security Mechanism

Generalized TTL Security Mechanism (GTSM) (RFC 5082) is designed to protect a router from CPU-utilization-based attacks. GTSM is based on the fact that most external peering sessions are established between directly adjacent routers, and therefore uses the expected TTL value from the peer to provide a simple and robust form of defense against packets from other devices that are not directly connected.

GTSM suggests that the TTL is set to 255 (the maximum possible for IP) and thereafter rejects any protocol packets that come in from configured peers that do not have an inbound TTL of 255.

GTSM is enabled at group or neighbor level using the command ttl-security followed by a configurable TTL value. When configured to 255 as in the example shown in Output 9-13, BGP accepts incoming IP packets from a peer only if the TTL value is equal to 255 and responds to OPEN messages with a TTL value of less than 255 with a NOTIFICATION message, thereby not participating in the OPEN exchange and not allowing the BGP session to be established.

Output 9-13: GTSM Configuration

bgp

group "EBGP"

family ipv4

neighbor 192.168.0.4

peer-as 64510

ttl-security 255

exit

exit

no shutdown

image

A prerequisite for GTSM is that per-peer-queuing is enabled. Per Peer CPM Queuing implements separate hardware queues in the CPM on a per-peer basis for BGP peers. These queues are serviced on a round-robin basis guaranteeing fairness for all peers to CPU resource. This also provides some level of protection against a DoS attack.

Auto-Generation of Filters for BGP Peers

When implementing security policies, most operators have a requirement to constrain what source/destination IP address ranges and protocols/ports can obtain access to a router's CPU resources. With Alcatel-Lucent IPD products, this is typically implemented using Control and Processing Module (CPM) or Input Output Module (IOM) filters. The former uses hardware-based policers and optionally queues on the actual CPM (Route Processor) to block/allow packets when they have crossed the switch fabric and reached the CPM. The latter implements filtering on the linecard, which when applied on ingress, can block packets from leaving the ingress linecard.

When operators configure and apply filters, the address ranges that are used for internal control-plane and management-plane purposes are typically known and represent a one-time configuration. However, when a router is peering externally with a number of peers that are frequently being updated, the process of manually updating filters can become rather onerous (not to mention they are open to misconfiguration). Auto-generation of filters for BGP peers is a feature that can remove this operational overhead. It allows for configuration of an IPv4 or IPv6 prefix “match-list” with specified criteria as part of a filter. When the router's BGP peering configuration changes, and that change matches the specified criteria, the address prefixes are automatically updated. In turn all CPM and IOM filters that use the match-list are also updated.

To allow for these automatic and “touch-less” filter updates, the configured IPv4/IPv6 address prefix match-lists must be able to define acceptable ranges of allowable peer groups or neighbor addresses. To support this, regular expressions can be used to match against peer groups or specific BGP neighbors.

Output 9-14 provides a simple example of the match-list using regular expressions. The ip-prefix-list command creates a context where both static IPv4 address prefixes and auto-generated IPv4 address prefixes can be configured, and may co-exist (a similar context ipv6-prefix-list exists for configuration of static and auto-generated IPv6 address prefixes).Within the ip-prefix-list context, static address prefixes are configured using the command prefix followed by a prefix/length (not shown in this example), whereas auto-generated address prefixes are configured within theapply-path context. Within this context, the bgp-peers command defines matching criteria for allowable address prefixes using regular expressions if required. This example has bgp-peers statements in the list. The first permits any BGP neighbor from the peer group IBGP (note “. *” is used to match against any neighbor); while the second permits any BGP neighbors from the peer group EBGP as long as the first three octets of the peer IP address are 192.168.0.

Output 9-14: IP-Prefix Match-List

filter

match-list

ip-prefix-list "BGP-PEERS" create

description "Auto-Update of CPM filter for BGP peers"

apply-path

bgp-peers 1 group "IBGP" neighbor ".*"

bgp-peers 2 group "EBGP" neighbor "192.168.0"

exit

exit

exit

exit

The match-list is then referenced in CPM-filter or IOM-filter entries as shown in Output 9-15, which gives an example of the former. Within each entry the src-ip command references the ip-prefix-list configured previously. Two entries are present to allow for either party to initiate the BGP session.

Output 9-15: CPM-Filter with Prefix-Lists

security

cpm-filter

default-action drop

ip-filter

entry 100 create

action accept

match protocol tcp

src-ip ip-prefix-list "BGP-PEERS"

src-port 179 65535

exit

exit

entry 101 create

action accept

match protocol tcp

dst-port 179 65535

src-ip ip-prefix-list "BGP-PEERS"

exit

exit

no shutdown

exit

exit

exit

Output 9-16 shows the auto-generated IPv4 prefixes based on two things:

· The bgp-peers statements configured in the match-list

· The configured BGP peers in the base routing context and how they have been referenced (in this case the CPM filter entries 100 and 101)

On this router there are three statically configured peers. The first is peer 192.0.2.12 in group IBGP, and the second and third are peers 192.168.0.1 and 192.168.1.1 in group EBGP. An address prefix is auto-generated for the first peer (192.0.2.12) because the regular expression permitted all peers in group IBGP. An address prefix is also auto-generated for the second peer (192.168.0.1) in group EBGP because its peering address falls within the defined range where the first three octets are 192.168.0. However, the third configured peer (192.168.1.1) does not fall within the regular expression configured for the peer group EBGP, and therefore an address prefix (and subsequent filter entry) is not generated for this peer. As a result, this peer does not have access to the CPM, and the BGP session cannot be established, as shown in Output 9-17.

Output 9-16: Auto-Generated IPv4 Prefixes

*A:R1# show filter match-list ip-prefix-list "BGP-PEERS"

===================================================================

Filter Match IP Prefix Lists

===================================================================

ip-prefix-list "BGP-PEERS"

===================================================================

apply-path (bgp-peers) prefixes:

-------------------------------------------------------------------

192.0.2.12/32 192.168.0.1/32

-------------------------------------------------------------------

NUM prefixes: 2

References:

-------------------------------------------------------------------

Cpm-filter entry 100 Src-Ip

Cpm-filter entry 101 Src-Ip

-------------------------------------------------------------------

NUM references: 2

===================================================================

Output 9-17: BGP Neighbor Summary

*A:R1# show router bgp summary | match Neighbor post-lines 12

Neighbor

AS PktRcvd InQ Up/Down State|Rcv/Act/Sent (Addr Family)

PktSent OutQ

-------------------------------------------------------------------------

192.0.2.12

64496 176 0 00h00m11s 3/0/1 (IPv4)

9 0

192.168.0.1

64510 147 0 01h12m46s 1/1/1 (IPv4)

150 0

192.168.1.1

64509 83 0 00h02m06s Connect

146 0