BIG-IP Konfiguration

BIG-IP

• (Beispiel für Route Domain 0)

Alle nachstehenden Befehle werden in tmsh auf BIG-IP ausgeführt. Passen Sie Objektnamen und IP-Adressen nach Bedarf an.

Allgemeine Informationen zur GRE-Tunnel-Konfiguration auf BIG-IP finden Sie unter Configuring a GRE Tunnel Using BIG-IP. Für die erstmalige Einrichtung der gerouteten Konfiguration mit der Cloud siehe K000147949.

tmsh

tmsh

[root@bigip:Active]# tmsh
root@(bigip)(cfg-sync Standalone)(Active)(/Common)(tmos)#

Äußere Self-IPs

GRE-Endpunkte

Dies sind die IPs auf jeder BIG-IP-Einheit, die als GRE-Tunnel- Endpunkte verwendet werden, typischerweise auf dem externen VLAN. Jede Einheit verfügt über eine eigene nicht-floating äußere Self-IP (traffic-group-local-only):

BIG-IP-A:

tmsh

create net self xc-ddos-v4-self-a \
  vlan external \
  traffic-group traffic-group-local-only \
  allow-service add { icmp:any gre:any } \
  address xBIGIP_A_OUTER_V4x/24

create net self xc-ddos-v6-self-a \
  vlan external \
  traffic-group traffic-group-local-only \
  allow-service add { icmp:any gre:any } \
  address xBIGIP_A_OUTER_V6x/64

BIG-IP-B:

tmsh

create net self xc-ddos-v4-self-b \
  vlan external \
  traffic-group traffic-group-local-only \
  allow-service add { icmp:any gre:any } \
  address xBIGIP_B_OUTER_V4x/24

create net self xc-ddos-v6-self-b \
  vlan external \
  traffic-group traffic-group-local-only \
  allow-service add { icmp:any gre:any } \
  address xBIGIP_B_OUTER_V6x/64

GRE-Tunnel

Jeder Tunnel verbindet eine BIG-IP-Einheit mit einem Cloud- Scrubbing-Center-Endpunkt. Erstellen Sie zwei Tunnel pro Einheit (jeweils einen zu jedem geografisch verteilten Scrubbing-Center), insgesamt vier logische Tunnel über das HA-Paar:

Tunnel C1-T1 — BIG-IP-A zu xCENTER_1x:

tmsh

create net tunnels tunnel xc-ddos-c1t1-v4 \
  local-address xBIGIP_A_OUTER_V4x \
  profile gre \
  remote-address xXC_C1_OUTER_V4x

create net tunnels tunnel xc-ddos-c1t1-v6 \
  local-address xBIGIP_A_OUTER_V6x \
  profile gre \
  remote-address xXC_C1_OUTER_V6x

Tunnel C2-T1 — BIG-IP-A zu xCENTER_2x:

tmsh

create net tunnels tunnel xc-ddos-c2t1-v4 \
  local-address xBIGIP_A_OUTER_V4x \
  profile gre \
  remote-address xXC_C2_OUTER_V4x

create net tunnels tunnel xc-ddos-c2t1-v6 \
  local-address xBIGIP_A_OUTER_V6x \
  profile gre \
  remote-address xXC_C2_OUTER_V6x

Tunnel C1-T2 — BIG-IP-B zu xCENTER_1x:

tmsh

create net tunnels tunnel xc-ddos-c1t2-v4 \
  local-address xBIGIP_B_OUTER_V4x \
  profile gre \
  remote-address xXC_C1_OUTER_V4x

create net tunnels tunnel xc-ddos-c1t2-v6 \
  local-address xBIGIP_B_OUTER_V6x \
  profile gre \
  remote-address xXC_C1_OUTER_V6x

Tunnel C2-T2 — BIG-IP-B zu xCENTER_2x:

tmsh

create net tunnels tunnel xc-ddos-c2t2-v4 \
  local-address xBIGIP_B_OUTER_V4x \
  profile gre \
  remote-address xXC_C2_OUTER_V4x

create net tunnels tunnel xc-ddos-c2t2-v6 \
  local-address xBIGIP_B_OUTER_V6x \
  profile gre \
  remote-address xXC_C2_OUTER_V6x

Tunnelnamen (xc-ddos-c1t1-v4 usw.) sind frei wählbar; verwenden Sie Ihre eigene Namenskonvention.

Tunnel-MTU festlegen

GRE-Kapselung erzeugt Overhead (24 Byte für äußeren IPv4-Header, 44 Byte für äußeren IPv6-Header). Ohne explizit festgelegte MTU werden Pakete nahe 1500 Byte fragmentiert oder verworfen. Legen Sie die Tunnel-MTU fest, um den Kapselungsoverhead zu berücksichtigen:

tmsh

modify net tunnels tunnel xc-ddos-c1t1-v4 mtu 1476
modify net tunnels tunnel xc-ddos-c1t1-v6 mtu 1456
modify net tunnels tunnel xc-ddos-c1t2-v4 mtu 1476
modify net tunnels tunnel xc-ddos-c1t2-v6 mtu 1456
modify net tunnels tunnel xc-ddos-c2t1-v4 mtu 1476
modify net tunnels tunnel xc-ddos-c2t1-v6 mtu 1456
modify net tunnels tunnel xc-ddos-c2t2-v4 mtu 1476
modify net tunnels tunnel xc-ddos-c2t2-v6 mtu 1456

Pfad-MTU

Die oben genannten Werte setzen eine Pfad-MTU von 1500 Byte im äußeren Netzwerk voraus. Passen Sie diese an, wenn die Pfad-MTU Ihres vorgelagerten Netzwerks kleiner ist. Stellen Sie sicher, dass ICMP „Destination Unreachable / Fragmentation Needed” (Typ 3, Code 4) auf keinem Zwischengerät blockiert wird, damit Path MTU Discovery (PMTUD) korrekt funktioniert.

GRE-Anti-Spoofing (vorgelagerte ACLs)

GRE (IP-Protokoll 47) bietet keine Authentifizierung. Jeder, der das äußere IP-Paar kennt, kann Datenverkehr in den Tunnel einschleusen. Wenden Sie ACLs auf dem vorgelagerten Router oder der Firewall an, um eingehenden GRE-Verkehr auf ausschließlich die erwarteten Cloud-Scrubbing-Center-Quell-IPs zu beschränken:

Cisco IOS

! Example upstream router ACL (Cisco IOS style)
ip access-list extended ALLOW-XC-GRE
  permit gre host xXC_C1_OUTER_V4x host xBIGIP_A_OUTER_V4x
  permit gre host xXC_C2_OUTER_V4x host xBIGIP_A_OUTER_V4x
  permit gre host xXC_C1_OUTER_V4x host xBIGIP_B_OUTER_V4x
  permit gre host xXC_C2_OUTER_V4x host xBIGIP_B_OUTER_V4x
  deny   gre any host xBIGIP_A_OUTER_V4x log
  deny   gre any host xBIGIP_B_OUTER_V4x log

Hinweis

Passen Sie die Syntax an Ihre Router-Plattform an. Dasselbe Prinzip gilt für IPv6-ACLs bei IPv6-GRE-Tunneln. Sowohl BIG-IP-A (xBIGIP_A_OUTER_V4x) als auch BIG-IP-B (xBIGIP_B_OUTER_V4x) äußere IPs müssen als GRE-Ziele erlaubt sein.

Innere Self-IPs (BGP-Peering)

Weisen Sie innere IP-Adressen (innerhalb des GRE-Tunnels) zu, die die BGP-Sitzung mit der Cloud aufbauen. Der allow-service-Wert muss tcp:179 (BGP) enthalten, damit die Peering-Sitzung hergestellt werden kann. Das Hinzufügen von icmp:any bei den inneren Self-IPs ermöglicht PMTUD und Erreichbarkeitstests durch den Tunnel:

Tunnel C1-T1 — BIG-IP-A zu xCENTER_1x:

tmsh

create net self xc-ddos-c1t1-inner-v4 \
  vlan xc-ddos-c1t1-v4 \
  traffic-group traffic-group-local-only \
  allow-service add { tcp:179 icmp:any } \
  address xBIGIP_C1_T1_INNER_V4x/30

create net self xc-ddos-c1t1-inner-v6 \
  vlan xc-ddos-c1t1-v6 \
  traffic-group traffic-group-local-only \
  allow-service add { tcp:179 icmp:any } \
  address xBIGIP_C1_T1_INNER_V6x/64

Tunnel C2-T1 — BIG-IP-A zu xCENTER_2x:

tmsh

create net self xc-ddos-c2t1-inner-v4 \
  vlan xc-ddos-c2t1-v4 \
  traffic-group traffic-group-local-only \
  allow-service add { tcp:179 icmp:any } \
  address xBIGIP_C2_T1_INNER_V4x/30

create net self xc-ddos-c2t1-inner-v6 \
  vlan xc-ddos-c2t1-v6 \
  traffic-group traffic-group-local-only \
  allow-service add { tcp:179 icmp:any } \
  address xBIGIP_C2_T1_INNER_V6x/64

Tunnel C1-T2 — BIG-IP-B zu xCENTER_1x:

tmsh

create net self xc-ddos-c1t2-inner-v4 \
  vlan xc-ddos-c1t2-v4 \
  traffic-group traffic-group-local-only \
  allow-service add { tcp:179 icmp:any } \
  address xBIGIP_C1_T2_INNER_V4x/30

create net self xc-ddos-c1t2-inner-v6 \
  vlan xc-ddos-c1t2-v6 \
  traffic-group traffic-group-local-only \
  allow-service add { tcp:179 icmp:any } \
  address xBIGIP_C1_T2_INNER_V6x/64

Tunnel C2-T2 — BIG-IP-B zu xCENTER_2x:

tmsh

create net self xc-ddos-c2t2-inner-v4 \
  vlan xc-ddos-c2t2-v4 \
  traffic-group traffic-group-local-only \
  allow-service add { tcp:179 icmp:any } \
  address xBIGIP_C2_T2_INNER_V4x/30

create net self xc-ddos-c2t2-inner-v6 \
  vlan xc-ddos-c2t2-v6 \
  traffic-group traffic-group-local-only \
  allow-service add { tcp:179 icmp:any } \
  address xBIGIP_C2_T2_INNER_V6x/64

BGP

Verwenden Sie imish, um BGP für Route Domain 0 zu konfigurieren.

Konfiguration pro Einheit

Die imish-BGP-Konfiguration ist lokal für jede BIG-IP-Einheit. Jede Einheit konfiguriert nur Nachbarn für ihre eigenen Tunnel:

• BIG-IP-A konfiguriert C1-T1- und C2-T1-Nachbarn.
• BIG-IP-B konfiguriert C1-T2- und C2-T2-Nachbarn.

Die router-id muss pro Einheit eindeutig sein (verwenden Sie jeweils die äußere Self-IP der Einheit).

1. imish für RD 0 aufrufen:

   bash

   tmsh run /util imish -r 0

2. Privilegierten Modus und Konfigurationsmodus aufrufen:

   imish

   localhost.localdomain[0]> enable
   localhost.localdomain[0]# configure terminal

3. Beispiel-BGP-Konfiguration:

Platzhalterwerte ersetzen

• xCUSTOMER_ASNx — Ihre öffentliche ASN, die bei ARIN (oder dem entsprechenden RIR) registriert ist. Eine öffentliche ASN ist erforderlich für geroutetes DDoS, da die Cloud Ihre Präfixe global ankündigt. Eine private ASN (64512-65534 / 4200000000-4294967294) ist nur akzeptabel, wenn der SOC das Peering mit privater ASN für Ihre Bereitstellung explizit unterstützt.
• xF5_XC_ASNx — Cloud-ASN (wird vom SOC bereitgestellt).
• xBGP_PASSWORDx — das vereinbarte BGP-MD5-Passwort (oder das „Default Secret” in der Konsole). Verwenden Sie dieses Passwort niemals für andere Dienste wieder.

BIG-IP-A (router-id xBIGIP_A_OUTER_V4x, Nachbarn C1-T1 + C2-T1):

imish

router bgp xCUSTOMER_ASNx
  no synchronization
  bgp log-neighbor-changes
  no auto-summary
  bgp router-id xBIGIP_A_OUTER_V4x
  bgp graceful-restart restart-time 120
  redistribute kernel route-map route-to-cloud-ipv4

  neighbor cloud peer-group
  neighbor cloud remote-as xF5_XC_ASNx
  neighbor cloud description cloud-peer-group
  neighbor cloud password xBGP_PASSWORDx
  neighbor cloud timers 10 30
  neighbor cloud soft-reconfiguration inbound
  neighbor cloud version 4
  neighbor cloud capability graceful-restart
  neighbor cloud send-community
  neighbor cloud ttl-security hops 1
  neighbor cloud maximum-prefix 10 warning-only
  neighbor cloud prefix-list deny-all in
  neighbor cloud prefix-list route-to-cloud-ipv4 out

  neighbor xXC_C1_T1_INNER_V4x peer-group cloud
  neighbor xXC_C1_T1_INNER_V4x description cloud-c1-t1-v4

  neighbor xXC_C2_T1_INNER_V4x peer-group cloud
  neighbor xXC_C2_T1_INNER_V4x description cloud-c2-t1-v4

  address-family ipv6
    redistribute kernel route-map route-to-cloud-ipv6
    neighbor cloud activate
    neighbor cloud soft-reconfiguration inbound
    neighbor cloud capability graceful-restart
    neighbor cloud prefix-list deny-all6 in
    neighbor cloud prefix-list route-to-cloud-ipv6 out
    neighbor xXC_C1_T1_INNER_V6x peer-group cloud
    neighbor xXC_C1_T1_INNER_V6x description cloud-c1-t1-v6
    neighbor xXC_C2_T1_INNER_V6x peer-group cloud
    neighbor xXC_C2_T1_INNER_V6x description cloud-c2-t1-v6
  exit-address-family

ip prefix-list deny-all deny 0.0.0.0/0 le 32
ip prefix-list route-to-cloud-ipv4 permit xPROTECTED_PREFIX_V4x

ipv6 prefix-list deny-all6 deny ::/0 le 128
ipv6 prefix-list route-to-cloud-ipv6 permit xPROTECTED_PREFIX_V6x

ip route xPROTECTED_NET_V4x xPROTECTED_MASK_V4x null0 201
ipv6 route xPROTECTED_PREFIX_V6x null0 201

route-map route-to-cloud-ipv4 permit 10
  match ip address prefix-list route-to-cloud-ipv4
  set origin igp

route-map route-to-cloud-ipv6 permit 10
  match ipv6 address prefix-list route-to-cloud-ipv6
  set origin igp

BIG-IP-B (router-id xBIGIP_B_OUTER_V4x, Nachbarn C1-T2 + C2-T2):

imish

router bgp xCUSTOMER_ASNx
  no synchronization
  bgp log-neighbor-changes
  no auto-summary
  bgp router-id xBIGIP_B_OUTER_V4x
  bgp graceful-restart restart-time 120
  redistribute kernel route-map route-to-cloud-ipv4

  neighbor cloud peer-group
  neighbor cloud remote-as xF5_XC_ASNx
  neighbor cloud description cloud-peer-group
  neighbor cloud password xBGP_PASSWORDx
  neighbor cloud timers 10 30
  neighbor cloud soft-reconfiguration inbound
  neighbor cloud version 4
  neighbor cloud capability graceful-restart
  neighbor cloud send-community
  neighbor cloud ttl-security hops 1
  neighbor cloud maximum-prefix 10 warning-only
  neighbor cloud prefix-list deny-all in
  neighbor cloud prefix-list route-to-cloud-ipv4 out

  neighbor xXC_C1_T2_INNER_V4x peer-group cloud
  neighbor xXC_C1_T2_INNER_V4x description cloud-c1-t2-v4

  neighbor xXC_C2_T2_INNER_V4x peer-group cloud
  neighbor xXC_C2_T2_INNER_V4x description cloud-c2-t2-v4

  address-family ipv6
    redistribute kernel route-map route-to-cloud-ipv6
    neighbor cloud activate
    neighbor cloud soft-reconfiguration inbound
    neighbor cloud capability graceful-restart
    neighbor cloud prefix-list deny-all6 in
    neighbor cloud prefix-list route-to-cloud-ipv6 out
    neighbor xXC_C1_T2_INNER_V6x peer-group cloud
    neighbor xXC_C1_T2_INNER_V6x description cloud-c1-t2-v6
    neighbor xXC_C2_T2_INNER_V6x peer-group cloud
    neighbor xXC_C2_T2_INNER_V6x description cloud-c2-t2-v6
  exit-address-family

ip prefix-list deny-all deny 0.0.0.0/0 le 32
ip prefix-list route-to-cloud-ipv4 permit xPROTECTED_PREFIX_V4x

ipv6 prefix-list deny-all6 deny ::/0 le 128
ipv6 prefix-list route-to-cloud-ipv6 permit xPROTECTED_PREFIX_V6x

ip route xPROTECTED_NET_V4x xPROTECTED_MASK_V4x null0 201
ipv6 route xPROTECTED_PREFIX_V6x null0 201

route-map route-to-cloud-ipv4 permit 10
  match ip address prefix-list route-to-cloud-ipv4
  set origin igp

route-map route-to-cloud-ipv6 permit 10
  match ipv6 address prefix-list route-to-cloud-ipv6
  set origin igp

Erläuterung der wichtigsten BGP-Einstellungen:

• timers 10 30 — Keepalive alle 10 s, Hold-Time 30 s. Der Standardwert (60 / 180) ist für DDoS-Mitigation-Failover zu langsam. Stimmen Sie die Timer-Werte mit dem SOC ab, damit beide Seiten übereinstimmen.
• ttl-security hops 1 — Aktiviert GTSM (RFC 5082). Da die BGP-Sitzungen Single-Hop über den GRE-Tunnel sind, verhindert dies Remote-BGP-Spoofing durch die Anforderung TTL = 255 bei eingehenden BGP-Paketen.
• maximum-prefix 10 warning-only — Defense-in-Depth-Schutzmaßnahme. Auch wenn die eingehende Präfixliste alle Routen ablehnt, erzeugt dies eine Warnung, wenn der Peer unerwartet Präfixe sendet.
• redistribute kernel — Fügt die null0-Statikrouten über die Route-Map in BGP ein. Eine Alternative ist die Verwendung expliziter network- Anweisungen (z. B. network xPROTECTED_PREFIX_V4x), die präziser sind, da nur das exakte Präfix angekündigt wird, unabhängig von anderen Kernel-Routen. Beide Ansätze funktionieren; redistribute kernel mit einer strikten Route-Map wird hier der Flexibilität halber gezeigt.

BFD (Bidirectional Forwarding Detection)

Wenn Ihre BIG-IP-Version BFD über GRE-Tunnel unterstützt, aktivieren Sie es für eine Sub-Sekunden-Fehlererkennung:

neighbor cloud fall-over bfd

BFD ermöglicht schnellere Konvergenz als BGP-Keepalive-Timer allein. Bestätigen Sie die BFD-Unterstützung mit Ihrer BIG-IP-Version und dem SOC, bevor Sie es aktivieren.

Die null0-Statikrouten mit höherer administrativer Distanz (201) stellen sicher, dass die Präfixe in der Kernel-Routing-Tabelle vorhanden sind, sodass sie über BGP an die Cloud weitergegeben werden können, ohne das normale Routing unter normalen Bedingungen (ohne Angriff) zu beeinflussen. Wenn das geschützte Präfix bereits aus einer anderen Quelle mit niedrigerer administrativer Distanz in der Routing-Tabelle vorhanden ist, ist die null0-Route nicht aktiv und die Weiterverteilung kann fehlschlagen — überprüfen Sie dies nach der Konfiguration mit show ip route.