Gebruik een statische route naar de Null0-interface voor luspreventie

Inleiding

Dit document beschrijft hoe een Statische Route naar de Ongeldige interface routing loops 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^®softwarerelease 12.3.1

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.

Conventies

Raadpleeg Cisco Technical Tips Conventions (Conventies voor technische tips van Cisco) voor meer informatie over documentconventies.

Achtergrondinformatie

De ongeldige interface wordt typisch gebruikt voor het verhinderen van routinglijnen. Enhanced Interior Gateway Routing Protocol (EIGRP) maakt bijvoorbeeld altijd een route naar de Null0-interface wanneer een groep routes wordt samengevat. Wanneer een routeringsprotocol samenvat, betekent dit dat de router verkeer kan ontvangen voor elk IP-adres binnen die samenvatting. Omdat niet alle IP-adressen altijd in gebruik zijn, is er een risico van looping pakketten als de 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 naar de Null0-interface wijst, die een virtuele Cisco IOS-interface is. Raadpleeg het gedeelte over de IP-route van Hoofdstuk: IP Routing Protocol-Independent Commands A door R voor meer informatie over de opdracht voor de IP-route. De volgende sectie presenteert een voorbeeld van hoe te om het ip routebevel te gebruiken om een statische route aan Null0 te creëren.

Voorbeeld

Een gemeenschappelijk scenario waar u een statische route aan Null0 kunt toevoegen is dat van een toegangsserver die vele cliënten het draaien binnen heeft. Dit scenario veroorzaakt dat de gastheerroutes worden geïnstalleerd in de toegangsserver die lijst routing. Om bereikbaarheid aan deze cliënten te verzekeren, terwijl niet overstromend het volledige netwerk met gastheerroutes, hebben andere routers in het netwerk typisch een summiere route die aan de toegangsserver richt. In dit type configuratie, moet de toegangsserver die zelfde summiere route hebben die aan de toegangsserver Null0 interface richt. Als dit niet het geval is, kan routing loops voorkomen wanneer externe hosts proberen IP-adressen te bereiken die momenteel niet zijn toegewezen aan een gedraaid client, maar die deel uitmaken van de summiere route. Dit komt doordat de toegangsserver de pakketten terug over de standaardroute van de toegangsserver in het kernnetwerk zou stuiteren, omdat de toegangsserver een specifieke hostroute voor de bestemming ontbeert.

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, vormt ISP een statische route voor 192.168.0.0/16 naar de gebruikersrouter (cust-R2). De ISP verbindt vervolgens met een backbone ISP, vertegenwoordigd door router BB-R3. De 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 de internetrouter (backbone ISP router BB-R3) tot de gebruikersrouter cust-R2, omdat cust-R2 een standaardroute heeft die is geconfigureerd om naar ISP-R1 te wijzen. Als pakketten echter bestemd zijn voor netwerkblokken die niet in gebruik zijn uit het bereik 192.168.0.0/16, dan 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 grote impact hebben op de router CPU en link gebruik. 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 debug-opdrachten waren ingeschakeld op de routers om de pakketstroom beter te illustreren, met name debug ip-pakket en debug ip icmp. Schakel deze opdrachten niet in in een productieomgeving 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 verstuurt één ICMP-verzoek naar een IP-adres binnen het blok 192.168.0.0/16 dat niet wordt gebruikt op cust-R2. BB-R3 ontvangt een ICMP-tijd die door ISP-R1 is overschreden.

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. Het zelfde pakket komt terug bij ISP-R1 op seriële0/0 en wordt onmiddellijk gestuurd uit de zelfde interface, naar cust-R2, wegens 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 dat ervoor zorgt dat dit verkeer wordt teruggestuurd naar ISP-R1?

Bij 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#

De 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 naar ISP-R1 wijst.

Het resultaat is dat de pakketlus tussen ISP-R1 en cust-R2 doorloopt totdat de TTL verloopt.

Als het ICMP-verzoek naar een IP-adres in 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 verbonden met cust-R2, zou er geen lusing hebben plaatsgevonden:

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 om een statische route aan Null0 voor 192.168.0.0/16 op cust-R2 te vormen.

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 naar 192.168.20.1 opnieuw verstuurt, verstuurt cust-R2 dit verkeer naar Null0, wat een ICMP teweegbrengt die onbereikbaar is om gegenereerd te worden.

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, indien in het vorige voorbeeld:

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

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

• Er wordt een verbinding met ISDN verbroken

Opmerking: het resultaat zou zijn dat pakketten in doorvoer of toepassingen die proberen dit blok IP-adressen te bereiken, dezelfde routinglus maken die eerder is beschreven.

Opmerking: om deze routing loop te repareren, moet u de ip route 192.168.1.0 255.255.255.0 Null0 200 opdracht gebruiken om een zwevende statische route te configureren naar Null0 voor 192.168.1.0/24. De 200 in de opdracht is de administratieve afstand. Raadpleeg Wat is administratieve afstand? voor meer informatie.

Opmerking: omdat we een hogere administratieve afstand gebruiken dan elk routeringsprotocol, als de route naar 192.168.1.0/24 via de ISDN-link inactief wordt, installeert cust-R2 een zwevende statische route. De pakketten worden dan verzonden naar Null0 tot de verbinding van ISDN actief wordt.

Gerelateerde informatie

• Cisco Technical Support en downloads