- Auto RP operations and implementations:
Candidate RPs send RP announcements to the 224.0.1.39 multicast group,
and the mapping agents send RP discovery messages to the 224.0.1.40
multicast group
Administrative scoping can be configured to limit the scope of the RP announcements
Auto-RP
Automatic
route processing (Auto-RP) is a feature that automates the distribution
of group-to-RP mappings in a PIM network. This feature has thest
benefits:
- It is easy to use multiple RPs within a network to serve different group ranges.
- It allows load splitting among different RPs.
- It facilitates the arrangement of RPs according to the location of group participants.
- It avoids inconsistent, manual RP configurations that might cause connectivity problems.
Multiple
RPs can be used to serve different group ranges or to serve as hot
backups for each other. To ensure that Auto-RP functions, configure
routers as candidate RPs so that they can announce their interest in operating as an RP for certain group ranges.
Additionally,
a router must be designated as an RP-mapping agent that receives the
RP-announcement messages from the candidate RPs, and arbitrates
conflicts. The RP-mapping agent sends the consistent group-to-RP
mappings to all remaining routers. Thus, all routers automatically
determine which RP to use for the groups they support.
auto-rp candidate-rp
To
configure a router as a Protocol Independent Multicast (PIM) rendezvous
point (RP) candidate that sends messages to the well-known
CISCO-RP-ANNOUNCE multicast group (224.0.1.39), use the
auto-rp candidate-rp command in PIM configuratiion mode. To return to the default behavior, use the
no form of this command.
auto-rp candidate-rp type interface-path-id
scope ttl-value [
group-list access-list-name] [
interval seconds]
no auto-rp candidate-rp type interface-path-id
scope ttl-value [
group-list access-list-name] [
interval seconds]
- Cisco IP NGN Infrastructure Layer
- BGP security and optimization options are used in the core and IP edge portions of the service provider network.
- Some options are used on the customer edge devices, as well.
- Threats in Service Provider Environments
- Threats to the BGP of the service provider:
- BGP relies on TCP as its transport protocol.
- BGP is susceptible to the same attacks that apply to any TCP-based protocol (DoS attacks).
- BGP is the most frequently targeted routing protocol, since it is used across the Internet.
- Service providers should take extreme caution to mitigate risks of exploiting BGP routing protocol.
- Inadvertent mistakes during BGP configuration can be serious and can have worldwide consequences.
- Attacks can be performed against a customer, usually using a form of DDoS:
- Such attacks can cause collateral damage to the infrastructure of the service provider, due to large amounts of traffic.
- Countermeasures should be taken to prevent damage to the service provider.
- BGP Threats Summary
- BGP routing table manipulation:
- An attacker is able to alter the content of the BGP table.
- BGP route spoofing:
- An attacker announces the prefix of the (spoofed) victim to reroute traffic for the victim to itself.
- BGP DoS:
- An attacker sends large amount of unexpected BGP traffic to the BGP router to expend hardware resources (CPU, memory).
- BGP Countermeasures Overview
- BGP Neighbor Authentication: BGP Table Manipulation
- BGP TTL Security Check: BGP Table Manipulation and BGP DoS
- BGP Maximum Prefix: BGP DoS
- CoPP: BGP Table Manipulation and BGP DoS
BGP route spoofing can be prevented using filtering based on prefixes and AS path.
- BGP Route Limiting
- All filtering mechanisms specify only what you are willing to accept but not how much.
- A misconfigured BGP neighbor can send a huge number of prefixes, which can exhaust the memory of a router or overload the CPU (several Internet-wide incidents have already occurred).
- BGP maximum prefixes limiting is used to establish a hard limit on the number of prefixes received from a neighbor.
- It is enabled by default on Cisco IOS XR Software to impose limitations for different address families.
- BGP router terminates peering when a number of maximum prefixes is exceeded.
- A router can be configured to:
- Generate a logging message when a specified percentage of the maximum prefixes is reached
- Reestablish BGP peering after a specified time
- Generate a logging message when the maximum prefix limit is exceeded, instead of terminating BGP peering
- Configuration
- IOS:
router bgp 123
neighbor 209.165.201.130 remote-as 234
neighbor 209.165.201.130 maximum-prefix 10 70 restart 5 ! Enable BGP route limiting for IPv4
!
neighbor 2001:db8:128::130 remote-as 234
address family ipv6 unicast
neighbor 2001:db8:128::130 activate
neighbor 2001:db8:128::130 maximum-prefix 10 70 restart 5 ! Enable BGP route limiting for IPv6
- IOS XR:
router bgp 123
neighbor 209.165.201.134
remote-as 345
address-family ipv4 unicast
maximum-prefix 100000 80 restart 5 ! Enable BGP route limiting for IPv4
!
neighbor 2001:db8:132::134
remote-as 345
address-family ipv6 unicast
maximum-prefix 10000 80 restart 5 ! Enable BGP route limiting for IPv6
- Verification
- Displays BGP neighbor information
RP/0/RSP0/CPU0
E2#show bgp neighbor 209.165.201.134
BGP neighbor is 209.165.201.134
Remote AS 345, local AS 123, external link
Maximum prefixes allowed 100000
Threshold for warning message 80%, restart interval 5 min
- Logging messages displayed when limit is exceeded
RP/0/RSP0/CPU0:Oct 11 13:31:23.697 : bgp[1048] : %ROUTING-BGP-4-MAXPFXEXCEED : No. of IPv4 Unicast prefixes received from 209.165.201.134 : 100001 exceed limit 100000
RP/0/RSP0/CPU0:Oct 11 13:31:23.697 : bgp[1048] : %ROUTING-BGP-5-ADJCHANGE : neighbor 209.165.201.134 Down - Peer exceeding maximum prefix limit (CEASE notification sent - maximum number of prefixes reached) (VRF: default)
- BGP Neighbor Authentication
- BGP neighbors can be authenticated before establishing a TCP session:
- HMAC-MD5 is used.
- Cisco IOS XR supports HMAC-SHA1 with key chains.
- To calculate a hash, part of an IP and an entire TCP header with data is used together with a pre-shared key.
- Every TCP segment is authenticated and the hash is prepended as TCP option 19.
- The hash is calculated on the receiving BGP router and compared with the received hash.
- BGP TTL Security Check
- Takes into account that valid EBGP sessions are established between connected interfaces or loopback interfaces
- Enforces that received TTL should match a specified value
- Can prevent DoS attack from non-directly connected neighbors by setting the received TTL to 254 or 253
- When enabled, sets TTL of outgoing BGP packets to 255