EIGRP van hogere metriek naar lagere metriek manipuleren

Inleiding

Dit document beschrijft het probleem met de uitgebreide metrische manipulatie van de route van Interior Gateway Routing Protocol (EIGRP) waar de gewijzigde metriek niet van kracht wordt wegens bekend gedrag EIGRP.

Achtergrond

Het probleem werd opgemerkt in één van de plaatsingen Intelligent WAN (IWAN) waar de netwerkexploitant probeerde om de voorkeur van de verkeersweg met een EIGRP vertragingsmetriek op de takrouters te beïnvloeden. De wegvoorkeur werd beïnvloed door de distribute-lijst onder configuratie EIGRP en door aanpassing van de metrische vertraging. Onderzoek de topologie die in Figuur 1 wordt getoond.

Afbeelding 1 - WAN-topologie

In deze topologie, probeert de netwerkexploitant om route-manipulatie met distribute-lijst op alle takrouters in beide gegevenscentra uit te voeren om voorkeur aan de prefixes te verstrekken om een bepaalde verbinding als aangewezen weg te nemen. Bijvoorbeeld, prefix 10.2.0.0/16 in DC2 is de aangewezen route op de spaak router in deze opeenvolging van voorkeur: DC2-BR2, DC2-BR1, DC1-BR2, DC1-BR2, DC1-BR1. Met andere woorden, de voorkeur om verkeer voor de spaakrouter te verzenden, bijvoorbeeld Spoke-1, zou eerst naar de DC2-BR2 router, dan DC2-BR1 router, dan naar DC1-BR2, en tenslotte naar de DC1-BR1 router zijn. De netwerkoperator heeft ook een EIGRP-vertraging geconfigureerd op de DCI-interface op DC1-SW1-knooppunt.

Een steekproefconfiguratie van de DC1-BR1 router voor metrische manipulatie EIGRP wordt hier getoond:

! Configuration from DC1-BR1 router
router eigrp TEST
 !
 address-family ipv4 unicast autonomous-system 100
 !
 af-interface default
 passive-interface
 exit-af-interface
 !
 af-interface Tunnel100
 summary-address 10.0.0.0 255.0.0.0
 summary-address 10.2.0.0 255.255.0.0
 no passive-interface
 no split-horizon
 exit-af-interface
 !
 af-interface GigabitEthernet0/0/1
 no passive-interface
 exit-af-interface
 !
 af-interface GigabitEthernet0/0/3
 no passive-interface
 exit-af-interface
 !
 topology base
 distribute-list route-map set-metric-Gig out GigabitEthernet0/0/1
 distribute-list route-map set-metric-tag-all out Tunnel100
 exit-af-topology
 network 10.1.2.0 0.0.0.255
 network 10.1.10.0 0.0.0.3
 network 10.1.123.0 0.0.3.255
 eigrp router-id 10.1.0.11
 exit-address-family 
!
route-map set-tag-all deny 10
 match tag 102 201 202
!
route-map set-tag-all permit 100
 match ip address prefix-list set-spoke-delay-4000
 set metric 100000 4000 255 1 1500
 set tag 101
!
route-map set-tag-all permit 300
 match ip address prefix-list set-spoke-delay-1000
 set metric 100000 1000 255 1 1500
 set tag 101
!
route-map set-tag-all permit 400
 match ip address prefix-list set-spoke-delay-2000
 set metric 100000 2000 255 1 1500
 set tag 101
 
!
ip prefix-list set-spoke-delay-4000 seq 100 permit 10.2.0.0/16
. . . 
! 

De Tunnel100 is een Dynamische VPN-tunnel (DMVPN) naar de Spoke-router via de INET-link. In de vorige configuratie is het prefix 10.2.0.0/16 ingesteld met de vertraging 4000. Op dezelfde manier wordt de vertraging ingesteld op 1000, 2000 en 3000 op respectievelijk DC2-BR2, DC2-BR1 en DC1-BR2 knooppunten voor hetzelfde prefix om de voorkeursvolgorde in te stellen. Hoewel het voorbeeld een DMVPN-tunnel voor demonstratiedoeleinden gebruikt, is het probleem niet afhankelijk van de interface.

Probleem

Het probleem wordt gezien op de spoke routers, waar het prefix 10.2.0.0/16 met verschillende metriek wordt gezien wanneer het wordt ontvangen van DC2 takrouters maar heeft de zelfde metriek wanneer ontvangen van DC1 takrouters. Deze output van de spoke router toont dit gedrag:

Spoke-1# show ip eigrp topology 10.2.0.0/16 | in delay
        Total delay is 60000000000 picoseconds  (from DC 2 BR2)
        Total delay is 100020000000 picoseconds  (From DC 1 BR1)
        Total delay is 70000000000 picoseconds  (From DC 2 BR1)
        Total delay is 100020000000 picoseconds  (From DC 1 BR2)

Dit gedrag zorgt ervoor dat de voorkeur niet achter elkaar wordt gegeven voor de paden die worden ontvangen van DC1-BR1 en DC1-BR2 routers.

Oplossing

De hoofdoorzaak van het probleem was dat de netwerkexploitant een metriek probeerde in te stellen op een lagere absolute waarde (lagere metriek) dan de ontvangen waarde. Dit kan worden geverifieerd met de show ip eigrp events bevel op de DC1 takrouters. De output toont aan dat de route-kaart probeert om metriek aan een waarde te manipuleren lager dan wat eigenlijk voor het prefix bestaat.

DC1-BR1# show ip eigrp events
. . .
06:47:11.891 Can't reduce rtmap metric, old/new: metric(2950430720) metric(1972633600)
. . .

Merk op dat voor om het even welk routeringsprotocol, u metrisch nooit kunt verminderen aangezien het zou betekenen dat u een interface met negatieve kosten hebt. Dit zou op zijn beurt de luspreventie voorwaarden verslaan en kan inconsistentie in het netwerk veroorzaken. De oplossing van het probleem kan op twee verschillende manieren worden gedaan:

• Verminder de vertragingswaarde in het pad voor het ontvangen prefix. In het vorige geval, hielp de vermindering van de EIGRP vertragingswaarde op de interface DCI het probleem verlichten.
• Configureer een hogere absolute metriek wanneer u metrische manipulatie uitvoert.