Gebruik een statische route naar de Null0-interface voor luspreventie

Inleiding

In dit document wordt beschreven hoe een statische route naar de Null-interface routeringslussen kan voorkomen.

Voorwaarden

Vereisten

Er zijn geen specifieke voorwaarden van toepassing op dit document.

Gebruikte componenten

De informatie in dit document is gebaseerd op de software- en hardwareversies:

• Cisco IOS^®-software versie 12.3.

De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u zorgen dat u de potentiële impact van elke opdracht begrijpt.

Achtergrondinformatie

De Null-interface wordt meestal gebruikt om routeringslussen te voorkomen. Enhanced Interior Gateway Routing Protocol (EIGRP), bijvoorbeeld, creëert altijd een route naar de Null0-interface wanneer het een groep routes samenvat. Wanneer een routeringsprotocol wordt samengevat, betekent dit dat de router verkeer kan ontvangen voor elk IP-adres in die samenvatting.

Omdat niet alle IP-adressen altijd in gebruik zijn, bestaat het risico dat pakketten worden herleid in het geval dat standaardroutes worden gebruikt op de router die het verkeer voor de samenvatting ontvangt.

opdrachtsyntaxis

Een statische route naar Null0 is een normale statische route, behalve dat deze verwijst naar de Null0-interface, een virtuele Cisco IOS-interface.

Raadpleeg de sectie IP-route van Hoofdstuk: IP Routing Protocol-onafhankelijke opdrachten A tot en met R voor meer informatie over de opdracht IP-route.

In het volgende gedeelte wordt een voorbeeld gegeven van hoe u de opdracht ip-route kunt gebruiken om een statische route naar Null0 te maken.

Voorbeeld

Een veel voorkomend scenario waarbij u een statische route aan Null0 kunt toevoegen, is dat van een toegangsserver waarop veel clients inbellen. Dit scenario zorgt ervoor dat hostroutes worden geïnstalleerd in de routeringstabel voor de toegangsserver.

Om de bereikbaarheid van deze clients te garanderen, zonder het hele netwerk te overspoelen met hostroutes, hebben andere routers in het netwerk meestal een overzichtsroute die naar de toegangserver wijst. In dit type configuratie moet de toegangsserver dezelfde overzichtsroute hebben die verwijst naar de Null0-interface van de toegangsserver. Als dat niet het geval is, kunnen routeringslussen optreden wanneer externe hosts proberen IP-adressen te bereiken die momenteel niet zijn toegewezen aan een gekozen client, maar die deel uitmaken van de overzichtsroute. Dit komt omdat de toegangsserver de pakketten terugstuitert over de standaardroute van de toegangsserver naar het kernnetwerk, omdat de toegangsserver een specifieke hostroute voor de bestemming mist.

Neem dit voorbeeld:

Netwerktopologie

Een kleine ISP (ISP-R1) geeft een van de gebruikers een netwerkblok van 192.168.0.0/16. In dit voorbeeld verdeelde de gebruiker 192.168.0.0/16 in /24-netwerken en gebruikt op dit moment alleen 192.168.1.0/24 en 192.168.2.0/24. Op router ISP-R1 configureert de ISP een statische route voor 192.168.0.0/16 naar de gebruikersrouter (cust-R2). De ISP maakt vervolgens verbinding met een backbone-ISP, vertegenwoordigd door router BB-R3. Router BB-R3 verzendt een standaardroute naar ISP-R1 en ontvangt het netwerk 192.168.0.0/16 via BGP van ISP-R1.

Bereikbaarheid is nu gegarandeerd van internet (backbone ISP router BB-R3) naar de gebruiker router cust-R2 omdat cust-R2 heeft een standaard route geconfigureerd om te wijzen naar ISP-R1.

Als pakketten echter bestemd zijn voor netwerkblokken die niet in gebruik zijn buiten het bereik van 192.168.0.0/16, gebruikt de cust-R2-router de standaardroute naar ISP-R1 om die pakketten door te sturen.

De pakketten lopen vervolgens tussen ISP-R1 en cust-R2 totdat de TTL verloopt. Dit kan een enorme impact hebben op de CPU van de router en het linkgebruik.

Een voorbeeld van waar dit verkeer naar ongebruikte IP-adressen vandaan kan komen, kan denial of service-aanvallen zijn, het scannen van IP-blokken om kwetsbare hosts te vinden, enzovoort.

Relevante configuraties:

version 12.3
!
hostname cust-R2
!
ip subnet-zero
!
interface Loopback0
 ip address 10.2.2.2 255.255.255.255
!         
interface Ethernet0/0
 ip address 192.168.1.1 255.255.255.0
!
interface Ethernet1/0
 ip address 192.168.2.1 255.255.255.0
!
interface Serial2/0
 ip address 10.0.0.2 255.255.255.252

!--- This interface leads to ISP-R1.

!
ip classless
ip route 0.0.0.0 0.0.0.0 10.0.0.1

!--- Default route going to ISP-R1.

!
end

version 12.3
!
hostname ISP-R1
!
ip subnet-zero
!
interface Loopback0
 ip address 10.1.1.1 255.255.255.255
!
interface Serial0/0
 ip address 10.0.0.1 255.255.255.252

!--- Interface to cust-R2.

!
interface Serial1/0
 ip unnumbered Loopback0

!--- Interface going to BB-R3.

!
router bgp 65501
 no synchronization
 network 192.168.0.0 mask 255.255.0.0

!--- ISP-R1 injects 192.168.0.0/16 into BGP to 
!--- advertise it to BB-R3.

 neighbor 10.3.3.3 remote-as 65503
 neighbor 10.3.3.3 ebgp-multihop 255
 no auto-summary
!
ip classless
ip route 10.3.3.3 255.255.255.255 Serial1/0
ip route 192.168.0.0 255.255.0.0 Serial0/0

!--- The first route is necessary for the eBGP 
!--- session to BB-R3 to come up.
!--- The route to 192.168.0.0/16 points towards cust-R2.

!
!
end

version 12.3
!
hostname BB-R3
!
ip subnet-zero
!
!
interface Loopback0
 ip address 10.3.3.3 255.255.255.255
!
interface Serial2/0
 ip unnumbered Loopback0

!--- This interface goes to ISP-R1.

!
router bgp 65503
 no synchronization
 bgp log-neighbor-changes
 neighbor 10.1.1.1 remote-as 65501
 neighbor 10.1.1.1 ebgp-multihop 255
 neighbor 10.1.1.1 default-originate 

!--- BB-R3 injects a default route into BGP and 
!--- sends it to ISP-R1.

 no auto-summary
!
ip classless
ip route 10.1.1.1 255.255.255.255 Serial2/0

!--- This route points to ISP-R1 and is 
!--- used to establish the eBGP peering.

!
end

Pakketstroom

Opmerking: Sommige foutopsporingsopdrachten werden ingeschakeld op de routers om de pakketstroom beter te illustreren, met name het foutopsporingspakket en het foutopsporingsIP-icmp. Schakel deze opdrachten niet in een productieomgeving in, tenzij u de gevolgen volledig begrijpt.

BB-R3#ping ip 192.168.20.1 repeat 1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 192.168.20.1, timeout is 2 seconds:

*Oct  6 09:36:45.355: IP: tableid=0, s=10.3.3.3 (local), d=192.168.20.1 (Serial2/0), routed via FIB
*Oct  6 09:36:45.355: IP: s=10.3.3.3 (local), d=192.168.20.1 (Serial2/0), len 100, sending.
Success rate is 0 percent (0/1)
BB-R3#
*Oct  6 09:36:50.943: ICMP: time exceeded rcvd from 10.0.0.1

BB-R3 verzendt een enkel ICMP-verzoek naar een IP-adres binnen het 192.168.0.0/16-blok dat niet wordt gebruikt op cust-R2.

BB-R3 ontvangt een ICMP tijd overschreden terug van ISP-R1.

Op ISP-R1:

18:50:22: IP: tableid=0, s=10.3.3.3 (Serial1/0), d=192.168.20.1 (Serial0/0), routed via RIB
18:50:22: IP: s=10.3.3.3 (Serial1/0), d=192.168.20.1 (Serial0/0), g=192.168.20.1, len 100, forward
18:50:22: IP: tableid=0, s=10.3.3.3 (Serial0/0), d=192.168.20.1 (Serial0/0), routed via RIB
18:50:22: IP: s=10.3.3.3 (Serial0/0), d=192.168.20.1 (Serial0/0), g=192.168.20.1, len 100, forward
18:50:22: IP: tableid=0, s=10.3.3.3 (Serial0/0), d=192.168.20.1 (Serial0/0), routed via RIB
18:50:22: IP: s=10.3.3.3 (Serial0/0), d=192.168.20.1 (Serial0/0), g=192.168.20.1, len 100, forward
18:50:22: IP: tableid=0, s=10.3.3.3 (Serial0/0), d=192.168.20.1 (Serial0/0), routed via RIB

Het eerste pakket wordt ontvangen op seriële 1/0 op ISP-R1 van BB-R3 en wordt doorgestuurd naar cust-R2 op seriële 0/0 zoals verwacht.

Hetzelfde pakket komt terug bij ISP-R1 op serial0/0 en wordt onmiddellijk verzonden vanuit dezelfde interface, naar cust-R2, vanwege deze route:

ISP-R1#show ip route 192.168.20.1
Routing entry for 192.168.0.0/16, supernet
  Known via "static", distance 1, metric 0 (connected)
  Advertised by bgp 65501
  Routing Descriptor Blocks:
  * directly connected, via Serial0/0
      Route metric is 0, traffic share count is 1

Wat gebeurt er op cust-R2 waardoor het dit verkeer terugstuurt naar ISP-R1?

Op cust-R2:

*Oct  6 09:41:43.495: IP: s=10.3.3.3 (Serial2/0), d=192.168.20.1 (Serial2/0), g=10.0.0.1, len 100, forward
*Oct  6 09:41:43.515: IP: tableid=0, s=10.3.3.3 (Serial2/0), d=192.168.20.1 (Serial2/0), routed via RIB
*Oct  6 09:41:43.515: IP: s=10.3.3.3 (Serial2/0), d=192.168.20.1 (Serial2/0), g=10.0.0.1, len 100, forward
*Oct  6 09:41:43.555: IP: tableid=0, s=10.3.3.3 (Serial2/0), d=192.168.20.1 (Serial2/0), routed via RIB

Je kunt zien dat cust-R2 deze pakketten terugstuurt naar ISP-R1, vanwege deze route:

cust-R2#show ip route 192.168.20.1 longer-prefixes 
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is 10.0.0.1 to network 0.0.0.0

cust-R2#

Router cust-R2 heeft geen route naar 192.168.20.1 omdat dit netwerk niet in gebruik is in het gebruikersnetwerk, dus de beste route naar 192.168.20.1 is de standaardroute die verwijst naar ISP-R1.Het resultaat is dat de pakketten lopen tussen ISP-R1 en cust-R2 totdat de TTL verloopt.

Als het ICMP-verzoek naar een IP-adres binnen een netwerk was gegaan dat in gebruik is, zou dit resultaat niet optreden.

Als het ICMP-verzoek bijvoorbeeld betrekking had op 192.168.1.x, dat rechtstreeks is aangesloten op cust-R2, zou er geen looping zijn opgetreden:

cust-R2#show ip route 192.168.1.1
Routing entry for 192.168.1.0/24
  Known via "connected", distance 0, metric 0 (connected, via interface)
  Routing Descriptor Blocks:
  * directly connected, via Ethernet0/0
      Route metric is 0, traffic share count is 1

De oplossing voor dit probleem is het configureren van een statische route naar Null0 voor 192.168.0.0/16 op cust-R2.

cust-R2#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
cust-R2(config)#ip route 192.168.0.0 255.255.0.0 Null0
cust-R2(config)#end
cust-R2#
*Oct  6 09:53:18.015: %SYS-5-CONFIG_I: Configured from console by console

cust-R2#show ip route 192.168.20.1
Routing entry for 192.168.0.0/16, supernet
  Known via "static", distance 1, metric 0 (connected)
  Routing Descriptor Blocks:
  * directly connected, via Null0
      Route metric is 0, traffic share count is 1

Als u nu het ICMP-verzoek van BB-R3 opnieuw verzendt naar 192.168.20.1, stuurt cust-R2 dit verkeer naar Null0, waardoor een ICMP onbereikbaar wordt gegenereerd.

BB-R3#ping ip 192.168.20.1 repeat 1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 192.168.20.1, timeout is 2 seconds:
U
Success rate is 0 percent (0/1)
BB-R3#
*Oct  6 09:54:33.051: ICMP: dst (10.3.3.3) host unreachable rcv from 10.0.0.2

Er kunnen situaties zijn waarin het gebruik van een samenvattende statische route naar Null0 niet haalbaar is. Bijvoorbeeld als in het vorige voorbeeld:

• Blok 192.168.1.0/24 is verbonden met een andere router die via ISDN naar cust-R2 belt

• ISP-R1 wijst 192.168.0.0/16 niet toe, maar alleen 192.168.1.0/24

• De ISDN-verbinding wordt verbroken

Opmerking: Het resultaat zou zijn dat pakketten in transit of toepassingen die proberen dit blok van IP-adressen te bereiken, dezelfde routeringslus maken die eerder is beschreven.

Opmerking: Als u deze routeringslus wilt herstellen, moet u de opdracht ip route 192.168.1.0 255.255.255.0 Null0 200 gebruiken om een drijvende statische route naar Null0 te configureren voor 192.168.1.0/24. De 200 in het commando is de administratieve afstand. Zie Administratieve afstand beschrijven voor meer informatie.

Opmerking: Omdat u een grotere beheerafstand gebruikt dan welk routeringsprotocol dan ook, installeert cust-R2 een drijvende statische route als de route naar 192.168.1.0/24 via de ISDN-link inactief wordt. Pakketten worden vervolgens naar Null0 verzonden totdat de ISDN-koppeling actief wordt.

Gerelateerde informatie

• Cisco Technical Support en downloads