Routing issue op HP Procurve 5412zl

[DukeBox]

Ik heb een probleem met routering op een procurve die niet doet wat ik wel.. en soms toch weer wel

Switch staat in routing mode, geconfigureerd met 3 (connected) VLAN's
VLAN 1: 192.168.242.254/24
VLAN 2: 172.25.7.254/24
VLAN 3: 172.25.9.254/24

En de volgende static routes:
0.0.0.0/0 192.168.242.200 metric 1 (default, internet)
172.25.0.0/23 172.25.9.1 metric 1 (vpn)

Nu doet zich het volgende voor bij VLAN 1:

code:

Tracing route to 172.25.0.1 over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.242.254
  2    <1 ms    <1 ms    <1 ms  192.168.242.200
  3    <1 ms    <1 ms    <1 ms  192.168.242.254
  4    <1 ms    <1 ms    <1 ms  172.25.9.1
  5     9 ms     9 ms     9 ms  172.25.0.1

Trace complete.

Ik heb de firewall op 192.168.242.200 de range 172.25.0.0/23 terug laten routeren naar 192.168.242.254 ik creëer wel een loop (ik weet het.. ) maar het vreemde is dat door het terug te sturen het daarna wel gewoon naar de juiste route gaat.

Nu het vreemde, een enkele keer gaat het wel goed (dit is wat ik ook verwacht had van de huidige configuratie):

code:

Tracing route to 172.25.0.1 over a maximum of 30 hops:

  1   <1 ms   <1 ms   <1 ms  192.168.242.254
  2   <1 ms   <1 ms   <1 ms  172.25.9.1
  3   9 ms    10 ms    9 ms  172.25.0.1

Trace complete.

VLAN 2 en 3 gaan wel altijd goed:

code:

Tracing route to 172.25.0.1 over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  172.25.7.254
  2    <1 ms    <1 ms    <1 ms  172.25.9.1
  3    10 ms     9 ms     9 ms  172.25.0.1

Trace complete.

code:

Tracing route to 172.25.0.1 over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  172.25.9.254
  2    <1 ms    <1 ms    <1 ms  172.25.9.1
  3     9 ms    10 ms     9 ms  172.25.0.1

Trace complete.

n.b. Ik heb het voorbeeld even geminimaliseerd qua configuratie maar er zijn meerdere vlans en routes geconfigureerd.. echter hebben die niets met dit probleem te maken. Indien deze info wel gewenst is kan ik deze later toevoegen.

Wat ik al getest/nagelopen heb/ben:

Op de hosts waarvandaan ik getest hebt zijn geen static routes aangemaakt, ook 1 gateway en geen extra opties middels dhcp.

Aangezien de gehele 5400series dezelfde firmware gebruikt en ook de lagere en hogere modellen vrijwel identiek lijken qua software dus om het gemakkelijk te houden ga ik er vanuit dat het niet aan het specifieke model ligt, desondanks heb ik de firmware wel geupdate naar de laatste versie.

De route tabel op de hosts is gelijk (eerste hop is ook altijd correct). Ook een enkel ip statisch opnemen op de procurve maakt niet uit.

Volgens mij komt het door dat de default dezelfde metric heeft als de andere static route. Zover ik kan vinden is het alleen niet mogelijk om deze aan te passen.. oftewel mijn vraag is heb ik iets fout gedaan of ben ik gewoon tegen iets aangelopen dat niet kan ?

[jvanhambelgium]

Mischien dat er wat settings op VLAN1 staan die nog ni goed zijn ? Mischien is VLAN1 een default vlan die eerder management is waardoor routing gedrag lichtjes anders is of een specifieke setting vereisen ?

[pistole]

maak je gebruik van access lists? (sh access-list)
En doe voor de volledigheid eens je volledige route tabel? (sh ip route)

Maak je nog gebruik van een routing protocol of vrrp?

[DukeBox]

pistole schreef op vrijdag 04 september 2009 @ 20:59:
maak je gebruik van access lists? (sh access-list)

Nee, die is leeg.

En doe voor de volledigheid eens je volledige route tabel? (sh ip route)

code:

  Destination        Gateway         VLAN Type      Sub-Type   Metric     Dist.
  ------------------ --------------- ---- --------- ---------- ---------- -----
  0.0.0.0/0          192.168.242.200 242  static               1          1
  10.66.44.0/24      172.25.9.1      1    static               1          1
  10.222.12.0/24     50_VLAN         50   connected            1          0
  127.0.0.0/8        reject               static               0          0
  127.0.0.1/32       lo0                  connected            1          0
  172.25.0.0/23      172.25.9.1      1    static               1          1
  172.25.3.0/24      172.25.9.1      1    static               1          1
  172.25.4.0/24      172.25.9.1      1    static               1          1
  172.25.5.0/24      172.25.9.1      1    static               1          1
  172.25.6.0/24      172.25.9.1      1    static               1          1
  172.25.7.0/24      250_VLAN        250  connected            1          0
  172.25.8.0/24      172.25.9.1      1    static               1          1
  172.25.9.0/24      DEFAULT_VLAN    1    connected            1          0
  192.168.100.0/24   192.168.242.200 242  static               1          1
  192.168.242.0/24   242_VLAN        242  connected            1          0
  192.168.244.0/24   244_VLAN        244  connected            1          0

Maak je nog gebruik van een routing protocol of vrrp?

Nope, aleen ip routing is enabled, voor de rest heb je hoe dan ook een special licentie nodig.

Ik heb al heel wat ervaring met hp apparatuur maar ben nog nooit zoiets tegengekomen.. ik denk dat ik toch eens een call ga neerleggen bij HP.

[CyBeR]

De absoluut enige manier dat ik me kan bedenken dat dit gebeurt is als er een verschil zit tussen de lookups van de route in software vs. in hardware. Die horen nooit te verschillen dus da's sowieso een bug. Het zou ook inhouden dat de software 'm verkeerd route, maar wel de goede route in de route cache voor de hardware propt..

Doe eens een 'sh tech' ergens online zetten?

[ Voor 19% gewijzigd door CyBeR op 04-09-2009 21:34 ]

[DukeBox]

Ikzelf denk ook dat het een bug is.. met name omdat bij het retour zenden het enige verschil in de data de TTL is en deze dan wel de goede kant op gaat.
Hier is de sh tech (wist niet van het bestaan, dus hoe dan ook bedankt daarvoor ).
(ik heb wel de bedrijfs gegevens uit de logfile gehaald)

[ Voor 10% gewijzigd door DukeBox op 04-09-2009 23:53 ]

[CyBeR]

Software K.14.37 heeft een fout gefixt die lijkt op jouw probleem:

Routing (PR_0000040696) — CPU-generated packets may have the wrong next-hop MAC address; they are sent out of the appropriate IP interface and VLAN but this may cause SNTP, ping, and other host applications to fail.

[DukeBox]

Hmm, vreemd dat hp openview niet aangeeft dat er een nieuwere versie is... hoe dan ook het is niet exact het probleem maar heeft er wel veel van weg..
Ik laat wel even weten wat de uitkomst is.

[CyBeR]

Dat komt waarschijnlijk omdat je wel de nieuwste K.13.X draait, terwijl dit om K.14.X gaat.

[DukeBox]

Oh ok, moet ik nu nog ff kijken of openview die ook kan downloaden. tnx voor je hulp !

[ Voor 12% gewijzigd door DukeBox op 06-09-2009 00:34 ]

[DukeBox]

Eindelijk een update gedaan.. maar helaas.

Ik draai nu Software revision K.14.41 maar het probleem is nog niet verdwenen.
Toch heb ik wel iets ontdekt waardoor iemand misschien nog een goede tip heeft om na te lopen.

Zo zou het dus moeten zijn:

code:

Tracing route to 172.25.0.1 over a maximum of 30 hops:

  1   <1 ms   <1 ms   <1 ms  192.168.242.254
  2   <1 ms   <1 ms   <1 ms  172.25.9.1
  3   9 ms    10 ms    9 ms  172.25.0.1

Trace complete.

Zo gaat het in het begin (na een reboot van de switch).. maar daarna opeens:

code:

Tracing route to 172.25.0.1 over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.242.254
  2    <1 ms    <1 ms    <1 ms  192.168.242.200
  3    <1 ms    <1 ms    <1 ms  192.168.242.254
  4    <1 ms    <1 ms    <1 ms  192.168.242.200
  5    <1 ms    <1 ms    <1 ms  192.168.242.254
  6    <1 ms    <1 ms    <1 ms  192.168.242.200
  7    <1 ms    <1 ms    <1 ms  192.168.242.254
  8    <1 ms    <1 ms    <1 ms  192.168.242.200
  9    <1 ms    <1 ms    <1 ms  192.168.242.254
 10    <1 ms    <1 ms    <1 ms  192.168.242.200
[cut]

Oftewel een loop.. wanneer ik vervolgens in de switch inlog en een "clear arp" commando geef:

code:

[/cut]
 26    <1 ms    <1 ms    <1 ms  192.168.242.200
 27    <1 ms    <1 ms    <1 ms  192.168.242.254
 28    <1 ms    <1 ms    <1 ms  192.168.242.200
 29    15 ms     9 ms    10 ms  172.25.0.1

Trace complete.

Vervolgens gaat het weer enige tijd goed.. soms 30 min. soms een paar uur.. en dan gaat het weer verkeerd.
2e vreemde ding is dat als het verkeerd gaat het soms na een 30 min of een paar uur ook weer goed gaat.

Ik zelf heb een vermoeden dat de firewall (dat is de 192.168.242.200) misschien iets raars doet in het netwerk, dat is een SX-GATE van XnetSolutions met firmware level 5.1-1-1 misschien dat dat ergens een belletje doet rinkelen.

De volgende stap die voor mij overblijft is om die firewall te vervangen alhoewel ik geen verklaring kan vinden waarom....

[Verwijderd]

Heeft die firewall toevallig meerdere interfaces met hetzelfde IP? Of een dual ISP constructie oid. Zou het arp probleem kunnen veroorzaken.
Check de mac entries op het moment dat het goed én fout gaat? Lijkt me dat het daar mee te maken heeft

[Verwijderd]

Ik zie dit nog niet op HP ITRC staan

http://forums13.itrc.hp.c...oryhome.do?categoryId=269

Hier zitten ook een hoop goede Procurve gasten(ik helaas ook :lol:)

[DukeBox]

Verwijderd schreef op vrijdag 23 oktober 2009 @ 09:53:
Check de mac entries op het moment dat het goed én fout gaat? Lijkt me dat het daar mee te maken heeft

Dat vermoeden had ik ook, en ik had al enkele dagen een script lopen dat iedere 180 sec. een dump makte van de arp cache.

Uiteindelijk heeft dit ook geholpen met het vinden van de oorzaak

Binnen het netwerk is ook nog een huawei switch opgenomen voor een stuk of 70 clients (2x48 gestacked) wat bleek nu, iedere keer als er een 'who has' arp request langs kwam antwoorde die switch met zijn ip, ook als het betreffende ip-adres niet eens aan die switch zat. HP kwam zelf met de suggestie om ARP proxy uit te zetten op die switch.. en tada opgelost.

Allen heel erg bedank voor het meedenken !

Oh, ODT bedankt voor de (eigenlijk zeer logische) tip van het HP forum, zal het in gedachten houden voor een volgende keer (alhouwel ik op GoT eigenlijk altijd wel tot een oplossing ben gekomen).

[ Voor 10% gewijzigd door DukeBox op 23-10-2009 18:41 ]