Example for Configuring the BGP GTSM
On a BGP network, BGP GTSM is configured to protect routers against CPU-utilization attacks.
Networking Requirements
Attacks by bogus packets on networks cause overload and consumption of the limited resources (such as CPUs) of devices. For example, an attacker sends bogus BGP packets to a router continuously. When the router determines that the received packets are destined for the local device, the forwarding plane sends the packets to the control plane for BGP processing without checking the validity of the packets. This causes a high CPU usage rate to the router because the router keeps processing the packets.
The Generalized TTL Security Mechanism (GTSM) is designed to protect routers from CPU-utilization-based attacks by checking whether the TTL value in the header of an IP packet is within the predefined range.
As shown in Figure 1, DeviceA belongs to AS10; DeviceB, DeviceC, and DeviceD all belong to AS20. BGP operates on the network as shown in Figure 1, and the BGP GTSM is used to protect DeviceB from CPU-utilization attacks.
Configuration Notes
When configuring BGP GTSM, note the following:
GTSM must be enabled on both ends of a BGP connection.
The valid-ttl-hops value set on both ends of a BGP connection must be the same.
Configuration Roadmap
The configuration roadmap is as follows:
Configure OSPF on DeviceA, DeviceB, DeviceC, and DeviceD in AS20 for interworking.
Establish an EBGP connection between DeviceA and DeviceB; establish an IBGP full mesh between DeviceB, DeviceC, and DeviceD through the loopback interfaces.
Configure the GTSM on DeviceA, DeviceB, DeviceC, and DeviceD.
Data Preparation
To complete the configuration, you need the following data:
Router ID and AS numbers of DeviceA, DeviceB, DeviceC, and DeviceD
Valid TTL range between DeviceA and DeviceB, DeviceB and DeviceC, DeviceC and DeviceD, and DeviceB and DeviceD
Procedure
- Configure IP addresses for interfaces. The configuration details are not mentioned here.
- Configure OSPF. The configuration details are not mentioned here.
- Configure the IBGP full mesh.
# Configure DeviceB.
[~DeviceB] bgp 20 [*DeviceB-bgp] router-id 10.2.2.9 [*DeviceB-bgp] peer 10.3.3.9 as-number 20 [*DeviceB-bgp] peer 10.3.3.9 connect-interface LoopBack0 [*DeviceB-bgp] peer 10.3.3.9 next-hop-local [*DeviceB-bgp] peer 10.4.4.9 as-number 20 [*DeviceB-bgp] peer 10.4.4.9 connect-interface LoopBack0 [*DeviceB-bgp] peer 10.4.4.9 next-hop-local [*DeviceB-bgp] commit
# Configure DeviceC.
[~DeviceC] bgp 20 [*DeviceC-bgp] router-id 10.3.3.9 [*DeviceC-bgp] peer 10.2.2.9 as-number 20 [*DeviceC-bgp] peer 10.2.2.9 connect-interface LoopBack0 [*DeviceC-bgp] peer 10.4.4.9 as-number 20 [*DeviceC-bgp] peer 10.4.4.9 connect-interface LoopBack0 [*DeviceC-bgp] commit
# Configure DeviceD.
[~DeviceD] bgp 20 [*DeviceD-bgp] router-id 10.4.4.9 [*DeviceD-bgp] peer 10.2.2.9 as-number 20 [*DeviceD-bgp] peer 10.2.2.9 connect-interface LoopBack0 [*DeviceD-bgp] peer 10.3.3.9 as-number 20 [*DeviceD-bgp] peer 10.3.3.9 connect-interface LoopBack0 [*DeviceD-bgp] commit
- Configure EBGP connections.
# Configure DeviceA.
[~DeviceA] bgp 10 [*DeviceA-bgp] router-id 10.1.1.9 [*DeviceA-bgp] peer 10.1.1.2 as-number 20 [*DeviceA-bgp] commit
# Configure Device B.
[~DeviceB-bgp] peer 10.1.1.1 as-number 10 [*DeviceB-bgp] commit
# View the status of the peer connections.
<DeviceB> display bgp peer BGP local router ID : 10.2.2.9 Local AS number : 20 Total number of peers : 3 Peers in established state : 3 Peer V AS MsgRcvd MsgSent OutQ Up/Down State PrefRcv 10.3.3.9 4 20 8 7 0 00:05:06 Established 0 10.4.4.9 4 20 8 10 0 00:05:33 Established 0 10.1.1.1 4 10 7 7 0 00:04:09 Established 0You can view that the BGP connections between DeviceB and the other routers are set up.
- Configure the GTSM between DeviceA and DeviceB. The two routers are directly connected; therefore, the valid TTL range of the packets between them is [255, 255]. That is, the value of valid-ttl-hops is 1.
# Configure the GTSM on DeviceA.
[~DeviceA] bgp 10 [*DeviceA-bgp] peer 10.1.1.2 valid-ttl-hops 1 [*DeviceA-bgp] commit
# Configure the GTSM for the EBGP connections on DeviceB.
[~DeviceB] bgp 20 [*DeviceB-bgp] peer 10.1.1.1 valid-ttl-hops 1 [*DeviceB-bgp] commit
# View the configuration of the GTSM.
<DeviceB> display bgp peer 10.1.1.1 verbose BGP Peer is 10.1.1.1, remote AS 10 Type: EBGP link BGP version 4, Remote router ID 10.1.1.9 Group ID : 2 BGP current state: Established, Up for 00h49m35s BGP current event: RecvKeepalive BGP last state: OpenConfirm BGP Peer Up count: 1 Received total routes: 0 Received active routes total: 0 Advertised total routes: 0 Port: Local - 179 Remote - 52876 Configured: Active Hold Time: 180 sec Keepalive Time:60 sec Received : Active Hold Time: 180 sec Negotiated: Active Hold Time: 180 sec Keepalive Time:60 sec Peer optional capabilities: Peer supports bgp multi-protocol extension Peer supports bgp route refresh capability Peer supports bgp 4-byte-as capability Address family IPv4 Unicast: advertised and received Received: Total 59 messages Update messages 0 Open messages 2 KeepAlive messages 57 Notification messages 0 Refresh messages 0 Sent: Total 79 messages Update messages 5 Open messages 2 KeepAlive messages 71 Notification messages 1 Refresh messages 0 Last keepalive received: 2009-02-20 13:54:58 Minimum route advertisement interval is 30 seconds Optional capabilities: Route refresh capability has been enabled 4-byte-as capability has been enabled GTSM has been enabled, valid-ttl-hops: 1 Peer Preferred Value: 0 Routing policy configured: No routing policy is configuredYou can view that the GTSM is enabled, the number of valid TTL hops is 1, and the status of the BGP connection is Established.
- Configure the GTSM between DeviceB and DeviceC. The two routers are directly connected; therefore, the valid TTL range of the packets between them is [255, 255]. That is, the value of valid-ttl-hops is 1.
# Configure the GTSM on DeviceB.
[~DeviceB] bgp 20 [*DeviceB-bgp] peer 10.3.3.9 valid-ttl-hops 1 [*DeviceB-bgp] commit
# Configure the GTSM for the IBGP connections on DeviceC.
[~DeviceC-bgp] peer 10.2.2.9 valid-ttl-hops 1 [*DeviceC-bgp] commit
# View the configuration of the GTSM.
<DeviceB> display bgp peer 10.3.3.9 verbose BGP Peer is 10.3.3.9, remote AS 20 Type: IBGP link BGP version 4, Remote router ID 10.3.3.9 Group ID : 0 BGP current state: Established, Up for 00h54m36s BGP current event: KATimerExpired BGP last state: OpenConfirm BGP Peer Up count: 1 Received total routes: 0 Received active routes total: 0 Advertised total routes: 0 Port: Local - 54998 Remote - 179 Configured: Active Hold Time: 180 sec Keepalive Time:60 sec Received : Active Hold Time: 180 sec Negotiated: Active Hold Time: 180 sec Keepalive Time:60 sec Peer optional capabilities: Peer supports bgp multi-protocol extension Peer supports bgp route refresh capability Peer supports bgp 4-byte-as capability Address family IPv4 Unicast: advertised and received Received: Total 63 messages Update messages 0 Open messages 1 KeepAlive messages 62 Notification messages 0 Refresh messages 0 Sent: Total 69 messages Update messages 10 Open messages 1 KeepAlive messages 58 Notification messages 0 Refresh messages 0 Last keepalive received: 2009-02-20 13:57:43 Minimum route advertisement interval is 15 seconds Optional capabilities: Route refresh capability has been enabled 4-byte-as capability has been enabled Nexthop self has been configured Connect-interface has been configured GTSM has been enabled, valid-ttl-hops: 1 Peer Preferred Value: 0 Routing policy configured: No routing policy is configuredYou can view that the GTSM is enabled, the number of valid TTL hops is 1, and the status of the BGP connection is Established.
- Configure the GTSM between DeviceC and DeviceD. The two routers are directly connected; therefore, the valid TTL range of the packets between them is [255, 255]. That is, the value of valid-ttl-hops is 1.
# Configure the GTSM for the IBGP connections on DeviceC.
[~DeviceC] bgp 20 [*DeviceC-bgp] peer 10.4.4.9 valid-ttl-hops 1 [*DeviceC-bgp] commit
# Configure the GTSM for the IBGP connections on DeviceD.
[~DeviceD] bgp 20 [*DeviceD-bgp] peer 10.3.3.9 valid-ttl-hops 1 [*DeviceD-bgp] commit
# View the configuration of the GTSM.
<DeviceC> display bgp peer 10.4.4.9 verbose BGP Peer is 10.4.4.9, remote AS 20 Type: IBGP link BGP version 4, Remote router ID 10.4.4.9 Group ID : 1 BGP current state: Established, Up for 00h56m06s BGP current event: KATimerExpired BGP last state: OpenConfirm BGP Peer Up count: 1 Received total routes: 0 Received active routes total: 0 Advertised total routes: 0 Port: Local - 179 Remote - 53758 Configured: Active Hold Time: 180 sec Keepalive Time:60 sec Received : Active Hold Time: 180 sec Negotiated: Active Hold Time: 180 sec Keepalive Time:60 sec Peer optional capabilities: Peer supports bgp multi-protocol extension Peer supports bgp route refresh capability Peer supports bgp 4-byte-as capability Address family IPv4 Unicast: advertised and received Received: Total 63 messages Update messages 0 Open messages 1 KeepAlive messages 62 Notification messages 0 Refresh messages 0 Sent: Total 63 messages Update messages 0 Open messages 2 KeepAlive messages 61 Notification messages 0 Refresh messages 0 Last keepalive received: 2009-02-20 14:00:06 Minimum route advertisement interval is 15 seconds Optional capabilities: Route refresh capability has been enabled 4-byte-as capability has been enabled Connect-interface has been configured GTSM has been enabled, valid-ttl-hops: 1 Peer Preferred Value: 0 Routing policy configured: No routing policy is configuredYou can view that the GTSM is enabled, the number of valid TTL hops is 1, and the status of the BGP connection is Established.
- Configure the GTSM between DeviceB and DeviceD. The two routers are connected through DeviceC. Because of the hop of router C, the valid TTL range of the packets between the two routers is [254, 255]. That is, the value of valid-ttl-hops is 2.
# Configure the GTSM for the IBGP connections on DeviceB.
[~DeviceB-bgp] peer 10.4.4.9 valid-ttl-hops 2 [*DeviceB-bgp] commit
# Configure the GTSM on DeviceD.
[~DeviceD-bgp] peer 10.2.2.9 valid-ttl-hops 2 [*DeviceD-bgp] commit
# View the configuration of the GTSM.
<DeviceB> display bgp peer 10.4.4.9 verbose BGP Peer is 10.4.4.9, remote AS 20 Type: IBGP link BGP version 4, Remote router ID 10.4.4.9 Group ID : 0 BGP current state: Established, Up for 00h57m48s BGP current event: RecvKeepalive BGP last state: OpenConfirm BGP Peer Up count: 1 Received total routes: 0 Received active routes total: 0 Advertised total routes: 0 Port: Local - 53714 Remote - 179 Configured: Active Hold Time: 180 sec Keepalive Time:60 sec Received : Active Hold Time: 180 sec Negotiated: Active Hold Time: 180 sec Keepalive Time:60 sec Peer optional capabilities: Peer supports bgp multi-protocol extension Peer supports bgp route refresh capability Peer supports bgp 4-byte-as capability Address family IPv4 Unicast: advertised and received Received: Total 72 messages Update messages 0 Open messages 1 KeepAlive messages 71 Notification messages 0 Refresh messages 0 Sent: Total 82 messages Update messages 10 Open messages 1 KeepAlive messages 71 Notification messages 0 Refresh messages 0 Last keepalive received: 2009-02-20 14:01:27 Minimum route advertisement interval is 15 seconds Optional capabilities: Route refresh capability has been enabled 4-byte-as capability has been enabled Nexthop self has been configured Connect-interface has been configured GTSM has been enabled, valid-ttl-hops: 2 Peer Preferred Value: 0 Routing policy configured: No routing policy is configuredYou can view that the GTSM is enabled, the number of valid TTL hops is 2, and the status of the BGP connection is Established.
In this example, if the value of valid-ttl-hops of either DeviceB or DeviceD is smaller than 2, the IBGP connection cannot be established.
The GTSM must be enabled on both ends of the BGP connection at the same time.
- Check the configuration.
# Run the display gtsm statistics all command on DeviceB, and you can view the statistics about the GTSM on DeviceB. If the default action that is performed on the packets is "pass" and all the packets are valid, no packet is dropped.
<DeviceB> display gtsm statistics all GTSM Statistics Table ---------------------------------------------------------------- SlotId Protocol Total Counters Drop Counters Pass Counters ---------------------------------------------------------------- 0 BGP 17 0 17 0 BGPv6 0 0 0 0 OSPF 0 0 0 0 LDP 0 0 0 0 OSPFv3 0 0 0 0 RIP 0 0 0 1 BGP 0 0 0 1 BGPv6 0 0 0 1 OSPF 0 0 0 1 LDP 0 0 0 1 OSPFv3 0 0 0 1 RIP 0 0 0 2 BGP 0 0 0 2 BGPv6 0 0 0 2 OSPF 0 0 0 2 LDP 0 0 0 2 OSPFv3 0 0 0 2 RIP 0 0 0 3 BGP 0 0 0 3 BGPv6 0 0 0 3 OSPF 0 0 0 3 LDP 0 0 0 3 OSPFv3 0 0 0 3 RIP 0 0 0 4 BGP 32 0 32 4 BGPv6 0 0 0 4 OSPF 0 0 0 4 LDP 0 0 0 4 OSPFv3 0 0 0 4 RIP 0 0 0 5 BGP 0 0 0 5 BGPv6 0 0 0 5 OSPF 0 0 0 5 LDP 0 0 0 5 OSPFv3 0 0 0 5 RIP 0 0 0 7 BGP 0 0 0 7 BGPv6 0 0 0 7 OSPF 0 0 0 7 LDP 0 0 0 7 OSPFv3 0 0 0 7 RIP 0 0 0 ----------------------------------------------------------------
If the host PC simulates BGP packets of DeviceA to attack DeviceB, the packets are dropped because the TTL value is not 255 when the packets reach DeviceB. In the GTSM statistics on Device B, the number of dropped packets also increases.
Configuration Files
Device A configuration file
# sysname DeviceA # interface GigabitEthernet0/1/0 ip address 10.1.1.1 255.255.255.0 # bgp 10 router-id 10.1.1.9 peer 10.1.1.2 as-number 20 peer 10.1.1.2 valid-ttl-hops 1 # ipv4-family unicast undo synchronization peer 10.1.1.2 enable # return
Device B configuration file
# sysname DeviceB # interface GigabitEthernet0/1/0 ip address 10.1.1.2 255.255.255.0 # interface GigabitEthernet0/1/8 ip address 10.2.1.1 255.255.255.0 # interface LoopBack0 ip address 10.2.2.9 255.255.255.255 # bgp 20 router-id 10.2.2.9 peer 10.3.3.9 as-number 20 peer 10.3.3.9 valid-ttl-hops 1 peer 10.3.3.9 connect-interface LoopBack0 peer 10.4.4.9 as-number 20 peer 10.4.4.9 valid-ttl-hops 2 peer 10.4.4.9 connect-interface LoopBack0 peer 10.1.1.1 as-number 10 peer 10.1.1.1 valid-ttl-hops 1 # ipv4-family unicast undo synchronization import-route ospf 1 peer 10.3.3.9 enable peer 10.3.3.9 next-hop-local peer 10.4.4.9 enable peer 10.4.4.9 next-hop-local peer 10.1.1.1 enable # ospf 1 area 0.0.0.0 network 10.2.1.0 0.0.0.255 network 10.2.2.9 0.0.0.0 # return
Device C configuration file
# sysname DeviceC # interface GigabitEthernet0/1/0 ip address 10.2.1.2 255.255.255.0 # interface GigabitEthernet0/1/8 ip address 10.2.2.1 255.255.255.0 # interface LoopBack0 ip address 10.3.3.9 255.255.255.255 # bgp 20 router-id 10.3.3.9 peer 10.2.2.9 as-number 20 peer 10.2.2.9 valid-ttl-hops 1 peer 10.2.2.9 connect-interface LoopBack0 peer 10.4.4.9 as-number 20 peer 10.4.4.9 valid-ttl-hops 1 peer 10.4.4.9 connect-interface LoopBack0 # ipv4-family unicast undo synchronization peer 10.2.2.9 enable peer 10.4.4.9 enable # ospf 1 area 0.0.0.0 network 10.2.1.0 0.0.0.255 network 10.2.2.0 0.0.0.255 network 10.3.3.9 0.0.0.0 # return
Device D configuration file
# sysname DeviceD # interface GigabitEthernet0/1/0 ip address 10.2.2.2 255.255.255.0 # interface LoopBack0 ip address 10.4.4.9 255.255.255.255 # bgp 20 router-id 10.4.4.9 peer 10.2.2.9 as-number 20 peer 10.2.2.9 valid-ttl-hops 2 peer 10.2.2.9 connect-interface LoopBack0 peer 10.3.3.9 as-number 20 peer 10.3.3.9 valid-ttl-hops 1 peer 10.3.3.9 connect-interface LoopBack0 # ipv4-family unicast undo synchronization peer 10.2.2.9 enable peer 10.3.3.9 enable # ospf 1 area 0.0.0.0 network 10.2.2.0 0.0.0.255 network 10.4.4.9 0.0.0.0 # return