EIGRP stub met leak-map

[xelnaha]

Hallo mede tweakers,

Ivm legacy hebben we een datacenter core switch welke geconfigureerd is als eigrp stub, welke twee neighbors heeft richting ons WAN.

topology:


WAN Router 1 <--> CORE router (EIGRP stub)

Deze switch dient op dit moment ook als gateway voor onze corporate omgeving. Dit wordt nu uit elkaar getrokken d.m.v L3 connectie:

nieuwe topology:

WAN Router 1 <--> CORE router (EIGRP stub) <--> nieuwe Router

Uiteraard zal ze core switch de netwerken van de nieuwe router niet doorgeven. We onderzoeken op dit moment twee zaken:

core switch omzetten naar normale eigrp en geen stub
leak map gebruiken


Mijn vraag richt zich op dit moment voornamelijk op de leak map implementatie. Normaliter zullen er geen queries gestuurd worden naar een stub router. is dit nog steeds het geval als er een leak-map geconfigureerd wordt? De documentatie op cisco is hier naar mijn idee niet echt duidelijk over en google levert een pletora aan info over eigrp stub, maar niet over de leak-map en query gedrag.

[Bl@ckbird]

Zit er een Smartnet op de switch?
Dan kan je een TAC case openen, Severity 4.

[xelnaha]

Bl@ckbird schreef op maandag 21 september 2015 @ 14:41:
Zit er een Smartnet op de switch?
Dan kan je een TAC case openen, Severity 4.

Hi Bl@ckbird,

Ik heb e.a. in lab kunnen uitwerken en zie dat elk netwerk dat gematched wordt door de leak-map gequeried wordt. Met een route-map die standaard alle prefixen matched, wordt de router effectief dus geen stub meer.

[wallywally]

xelnaha schreef op maandag 21 september 2015 @ 13:48:


Uiteraard zal ze core switch de netwerken van de nieuwe router niet doorgeven. We onderzoeken op dit moment twee zaken:

Je kan hem toch instellen als STUB-connected? Zodat alle directly connected in je routing tabel komen?

Edit; ik lees verkeerd, nvm

Waarom niet via "normaal EIGRP" je routes adverteren en summarizen op de nieuwe router dan?

[ Voor 15% gewijzigd door wallywally op 21-09-2015 16:43 ]

[xelnaha]

Dat is optie 1, maar we blijkbaar was er een race condition ergens ( weet nog niet wat precies) derhalve optie 2 mocht optie 1 niet geschikt blijken

[wallywally]

Ik zou dat stukje opstelling nabouwen in GNS3, en kijken wat er gebeurt.

Tip van de schildpad.

[TrailBlazer]

waarom niet gewoon OSPF erbij zitten en migreren naar een niet proprietary protocol.

[ik222]

TrailBlazer schreef op woensdag 23 september 2015 @ 15:54:
waarom niet gewoon OSPF erbij zitten en migreren naar een niet proprietary protocol.

Dat zou ook mijn aanpak zijn inderdaad, geen idee uiteraard van de rest van de topologie maar dat lijkt me niet zo lastig.

[xelnaha]

wallywally schreef op dinsdag 22 september 2015 @ 10:47:
Ik zou dat stukje opstelling nabouwen in GNS3, en kijken wat er gebeurt.

Tip van de schildpad.

Dat hebben we uiteindelijk ook gedaan en kunnen nabootsen, en zie ook mijn reactie --> voor de prefixen in the leakmap worden wel queries uitgevoerd.

TrailBlazer schreef op woensdag 23 september 2015 @ 15:54:
waarom niet gewoon OSPF erbij zitten en migreren naar een niet proprietary protocol.

Omdat we niet direct een lokaal probleem willen oplossen met een migratie wereldwijd

[ Voor 28% gewijzigd door xelnaha op 28-09-2015 15:28 ]

[TrailBlazer]

tja met die instelling blijf je met die ouwe meuk zitten