ICMP naar bepaalde ip addressen niet mogelijk

[enveekaa]

Ik heb een beetje aan vreemd probleem op ons bedrijfsnetwerk, er zijn 4 ip addressen in subnet 192.168.1.0/24 die problemen hebben met icmp ping requests. ICMP requests vanuit een ander subnet komen altijd aan, deze worden netjes gerouteerd.

Het probleem doet zich dus enkel voor bij ICMP requests vanuit hetzelfde subnet. Pikant detail is dat die 4 ip addressen vanaf sommige servers wel te pingen zijn en vanaf andere weer niet, hier kan ik tot noch toe geen verband in vinden. We maken geen gebruik van ACLs op ip en/of mac niveau.

De reden dan ik expliciet praat over ICMP is omdat andere protocollen wel gewoon werken.
Voorbeeld: Ik kan 192.168.1.100 niet pingen (kon eerst wel) maar ik kan wel bij de webinterface.
Dit probleem heeft zich afgelopen maandag spontaan voorgedaan, we kwamen erachter toen enkele devices een alarm gaven in ons monitoring systeem.

Het netwerk bestaat uit een stack van 8 Cisco 3750's.
Subnet masks staan goed (allemaal /24).
Er staan geen firewalls aan op servers.
De ip adressen waar het omgaat: .56 .57 .93 en .94. De .56 en .57 zijn APC UPS devices, en de .93 en .94 zijn TVs.

[ Voor 33% gewijzigd door enveekaa op 12-08-2010 13:43 ]

[Uberprutser]

Gekeken of alle (stack) interfaces up/up staan? Allemaal zelfde instellingen? Werk je met aparte VLAN's en zo ja staan deze op alle switches goed gedefinieerd?

Eigenlijk zou je wanneer ze in zelfde subnet (en dus ook VLAN zitten) geen problemen moeten ondervinden met onderling pingen tenzij de poortjes op verschillende switches zitten.

In dat geval: Kijk eens op welke switch/poort een "probleemgeval" zit en kijk of wanneer je deze op dezelfde switch zet als de machine waarvandaan je probeert te pingen of deze dan wel aan komt.

En als laatste: Geen software actief (MS Firewall bijvoorbeeld) welke deze requests niet door laat? Bij mij was deze opeens actief en kon ik mijn TFTP server niet meer pingen.

Zo even een paar dingetjes die ik bedenk.

edit: Ik hoop dat een beetje overkomt wat ik denk, zit beetje onder de pillen nu dus schijn wat rare dingen uit te kramen.

[ Voor 8% gewijzigd door Uberprutser op 12-08-2010 14:11 ]

[enveekaa]

Bedankt voor het meedenken!

De stack-ring is intact (32g).

code:

         Stack Port Status             Neighbors
Switch#  Port 1     Port 2           Port 1   Port 2
--------------------------------------------------------
  1        Ok         Ok                3        2
  2        Ok         Ok                1        4
  3        Ok         Ok                5        1
  4        Ok         Ok                2        6
  5        Ok         Ok                7        3
  6        Ok         Ok                4        8
  7        Ok         Ok                8        5
  8        Ok         Ok                6        7

Het probleem kan niet zitten in een vlan wat niet goed is doorgezet omdat andere ip adressen wel te pingen zijn. Ik test nu vanaf een server met ip 192.168.1.29 en pingen gaat goed naar allerlei adressen in dit subnet behalve naar de .56 .57 .93 en .94

Op de server waar ik test staat de firewall uit, dat kan het dus ook niet zijn. Ik ga nog wel even kijken of het op elke member de niet te bereiken devices zitten en of ik hier een verband kan vinden.

Vanaf de stack zelf kan ik trouwens alle devices wel netjes pingen. Vaaag!

[ Voor 30% gewijzigd door enveekaa op 12-08-2010 14:18 ]

[Uberprutser]

Maar, zitten die allemaal op dezelfde switch of niet?

[TrailBlazer]

kloppen je arp tabellen op de pc waarvan je probeert te pingen wel met de werkelijke mac adressen van de server die je niet kan bereiken. Ik zit te denken aan proxy arp achtig iets.

[Remco]

Ja, vergelijk je ARP resolving eens op de server welke het niet doet, en van welke het wel doet.
Wellicht resolved hij verkeerd ?

Edit:
Maar ja, dan zou het andere verkeer natuurlijk ook niet mogelijk zijn op de andere poorten...

[ Voor 28% gewijzigd door Remco op 12-08-2010 15:19 ]

[enveekaa]

Ballebek schreef op donderdag 12 augustus 2010 @ 14:41:
Maar, zitten die allemaal op dezelfde switch of niet?

Nope, de server waar vanaf ik wil pingen zit op een andere member.

TrailBlazer schreef op donderdag 12 augustus 2010 @ 14:45:
kloppen je arp tabellen op de pc waarvan je probeert te pingen wel met de werkelijke mac adressen van de server die je niet kan bereiken. Ik zit te denken aan proxy arp achtig iets.

Ja die zijn in orde, ik heb ook al een clear arp-cache gedaan, maar zoals Remco ook al aangeeft komt ander (niet ICMP verkeer) wel gewoon aan.

Het lijkt erop dat de stack iets uithaalt met ICMP
Al betwijfel ik dat het in de config van de stack zit... beetje dubbel.

[ Voor 8% gewijzigd door enveekaa op 12-08-2010 17:42 ]

[TrailBlazer]

Stack zou geen invloed mogen hebben.,Je moet wel een hele aparte config hebben wil je ICMP naar specifieke hosts kunnen blokkeren. Dit is zeker niet iets wat je even fout instelt.

[deandb]

Heb je al eens een sniff gedaan met wireshark?

[mookie]

Ik heb niet iets concreets (de oplossing) toe te voegen, behalve dan dat ICMP niet gelijk staat aan TCP of UDP.
Allemaal gebruiken zij IP voor addressering, maar FTP gebruikt b.v. TCP, en TFTP gebruikt UDP, DNS zal meestal UDP gebruiken, Filesharing (poort 139 windows 2000 en hoger) gewoon TCP, webinterface (normaal http) gebruikt TCP....

ICMP is wel iets bijzonders.
Het is een protocol op zich, net zoals TCP en UDP dat is.

Het enige wat me zo te binnen schiet is dat je een ring hebt van 8 switches.
Ethernet/STP mag officieel maar 7 niveau's diep gaan.
Ik ben geen cisco man, maar normaal gesproken werkt zo'n ring gewoon met spanning tree.
Er is dus eigenlijk geen ring, want die ring wordt onderbroken door STP.
Daar waar hij verbroken is kan hij zo hersteld worden als hij ergens anders onderbroken wordt.

Als ik naar je lijstje kijk is je ring:

switch 1 -> switch 3 -> switch 5 -> switch 7 -> switch 8 -> switch 6 -> switch 4 -> switch 2 -> terug bij switch 1

Nou meen ik me te herinneren dat die 7 niveau's beginnen te tellen vanaf je guest, dus eigenlijk maar 6 switches diep mag gaan.

Stel nou dat als die host die je probeert te pingen, wel binnen de 7 lagen naar de router naar andere subnets kan, maar niet over de 7 lagen naar jou monitoring systeem kan.
Zelfs ik vind dit vergezocht en vraag me af of het klopt, maar je kunt het simpel testen door je computer in een andere switch in te pluggen (ff kijken welke er dicht bij zit) en nog eens proberen te pingen.
Vanaf de stack kun je wel pingen.
Misschien dat je net binnen de 7 lagen blijft?

Ballebek vroeg al of ze op dezelfde switch zaten (degene die je wel kunt pingen, en degene die je niet kunt pingen)

Nogmaals, ik ben geen cisco man, maar ik ken geen ring stack.
Of je stacked switches fysiek, met een stacking kaart zodat het echt 1 grote switch wordt, of je hangt alles met STP in een ring, en je voegt alle switches aan 1 stack toe met 1 stack commander (of hoe dat bij cisco ook heet) voor het management maar een stack voor management is niet een stack waarbij je b.v. 2x24 ombouwt tot 1 grote 48 poorts switch... dat zijn 2 andere dingen (sorry ik ken alleen HP switches...en die ook niet helemaal)

Bedenk je in dit geval wel dat ICMP wel degelijk iets anders is dan TCP of UDP.
ICMP is gebouwd om netwerk componenten (switches, hosts, guests etc) elkaar te voorzien van netwerk informatie. Ze geven het door als een route niet bereikbaar is, of dat je b.v. packet niet mag fragmenteren etc.

Ik ga er vanuit dat je een ring hebt die met STP ergens onderbroken is.
Als je host die geen ICMP lokaal terugstuurd nou op switch 1 zit, en je router naar andere subnets op switch 3, en jij zit met je monitoring systeem op switch 2, en tussen switch 2 en 1 is hij onderbroken, dan heb je vanaf switch 2 de switches 4, 6, 8, 7, 5, 3, 1 (plus je host) dus dat is 8 lagen dus jij krijgt geen ICMP want je mag maar 7 lagen.
Vanaf een ander subnet ga je door je default gateway (switch 1) vanaf switch 1 meteen naar 3 en terug en dat werkt wel.

Je zegt ook vanaf sommige servers wel, en vanaf de stack wel, maar vanaf je monitoring systeem niet.
Wellicht dat vanaf die servers die je kunt pingen, dat die minder dan 7 niveau's diep zitten?
Her en der lees ik zelfs dat het maar 5 niveau's diep mag zijn, maar ik ken niet beter dan 7, specifiek bij een ring.
http://home.caregroup.org...epage_out.asp?pageid=4671

Hoe dan ook,
- verklaar me voor gek
- plug je laptop in op dezelfde switch als die gekke hosts en probeer nog eens te pingen.

[TrailBlazer]

Als je een stack maakt wordt het gewoon één switch. STP is niet van toepassing op een gestackte 3750.

Die diameter van 7 is een nogal lastige berekening. Maar daar zitten nogal wat idiote aannames in voor de huidige switches. Ik geloof 2 BPDU kunnen verliezen en een processing delay van een seconde op iedere switch. Dit is uiteraard een bijzonder hypothetisch geval

[enveekaa]

TrailBlazer schreef op donderdag 12 augustus 2010 @ 19:07:
Stack zou geen invloed mogen hebben.,Je moet wel een hele aparte config hebben wil je ICMP naar specifieke hosts kunnen blokkeren. Dit is zeker niet iets wat je even fout instelt.

Mee eens, dat moet opvallen in de config.

mookie schreef op vrijdag 13 augustus 2010 @ 02:58:
Ik heb niet iets concreets (de oplossing) toe te voegen, behalve dan dat ICMP niet gelijk staat aan TCP of UDP.
Allemaal gebruiken zij IP voor addressering, maar FTP gebruikt b.v. TCP, en TFTP gebruikt UDP, DNS zal meestal UDP gebruiken, Filesharing (poort 139 windows 2000 en hoger) gewoon TCP, webinterface (normaal http) gebruikt TCP....

*knip*

Thanks voor je uitgebreide verhaal!
Een Cisco stack maakt idd geen gebruik van STP, logisch gezien wordt het echt 1 switch.
Het maakt niet uit of ik ping vanaf dezelfde member of een andere member, vanaf sommige servers werkt het wel en vanaf sommige servers niet Ik weet dat ICMP een apart protocol is, dus ICMP/IP en dat er geen
TCP aan te pas komt.

deandb schreef op donderdag 12 augustus 2010 @ 22:35:
Heb je al eens een sniff gedaan met wireshark?

Nee nog niet.
Jammer is alleen dat ik op de hosts die niet te pingen zijn niets kan installeren (zijn APC devices).
Ik ga maar even een hubje er tussen prakken en is kijken of die icmp request uberhaupt wel aankomt.

[ Voor 16% gewijzigd door enveekaa op 13-08-2010 10:11 ]

[TrailBlazer]

Hub is niet nodig natuurlijk. Gewoon een spanport aanmaken. Veel netter.

monitor session 1 source interface g1/0/1
monitor session 1 destination interface g1/0/2

[enveekaa]

De reden dat ik het met een hub doe is dat ik de stack even helemaal wil uitsluiten.
Al verwacht ik niet dat als de ik mbv een spanport het icmp pakketje voorbij zie komen dat het dan niet op de lijn zit.. maar je weet nooit

[enveekaa]

Heb er even een hub tussen gezet en ik zie op het device wat ik aan het pingen ben een icmp request en icmp reply. Op de machine waar ik de ping doe zie ik de request maar de reply komt niet terug.

code:

Captured packet op 10.20.5.23 
23  1.711395    10.20.5.23  10.20.5.57  ICMP    Echo (ping) request

Captured packets op 10.20.5.57 
3762    241.813362  10.20.5.23  10.20.5.57  ICMP    Echo (ping) request
3763    241.815591  10.20.5.57  10.20.5.23  ICMP    Echo (ping) reply

Ping request komt dus aan, er wordt netjes een reply gestuurd en die komt niet aan.

[enveekaa]

Aha! Het src mac adres van het icmp pakketje klopt niet.

code:

Ethernet II, Src: HewlettP_5a:7b:5d (00:16:35:5a:7b:5d), Dst: American_7a:5d:75 (00:c0:b7:7a:5d:75)

In het pakketje staat 00:16:35:5a:7b:5d terwijl de interface 00:16:35:5a:7b:5e is. De arp tabel op de stack klopt wel.

Het lijkt erop dat het alleen mis gaat als de source interface uit een team bestaat.

code:

ZMCORE01#show mac address-table interface gi 6/0/16
          Mac Address Table
-------------------------------------------

Vlan    Mac Address       Type        Ports
----    -----------       --------    -----
 202    0016.355a.7b5e    DYNAMIC     Gi6/0/16
Total Mac Addresses for this criterion: 1
ZMCORE01#show mac address-table interface gi 7/0/16
          Mac Address Table
-------------------------------------------

Vlan    Mac Address       Type        Ports
----    -----------       --------    -----
 202    0016.355a.7b5d    DYNAMIC     Gi7/0/16

Server A zit aangesloten op poort gi6/0/16 en gi6/0/17.
Op de server in een team gecreeerd met mac 0016.355a.7b5e.
In het src mac veld van het icmp pakketje staat 0016.355a.7b5d.
Als ik een van de twee team interfaces disable werkt de ping wel.

Kan dus de conslusie trekken dat het in de teaming zit.... maar waarom werkt het pingen naar andere devices wel, of teaming enabeld is.

[ Voor 74% gewijzigd door enveekaa op 13-08-2010 15:42 ]

[MrFX]

heb je toevallig SLB loadbalancing aangezet op je server?

[enveekaa]

Teaming staat op TLB op dit moment.

Uiteindelijk willen we wel gebruik gaan maken van LACP (802.3ad) maar dit werkte tot voorkort ook als een zonnetje.

[ Voor 62% gewijzigd door enveekaa op 13-08-2010 15:54 ]

[MrFX]

Kun je de config van je switchporten (welke connecten naar je server) eens posten? maak je gebruik van LACP of etherchannels?

[MrFX]

Je zou IEEE 802.3ad link aggregation teaming eens kunnen proberen.

[enveekaa]

code:

interface GigabitEthernet6/0/16
 description ONMER02-P1
 switchport access vlan 202
 switchport mode access
 spanning-tree portfast
end

interface GigabitEthernet7/0/16
 description ONMER02-P2
 switchport access vlan 202
 switchport mode access
 spanning-tree portfast
end

Op dit moment maken geen gebruik van LACP of etherchannels, de teaming wordt nu geregeld door de HP nic drivers.

[ Voor 3% gewijzigd door enveekaa op 13-08-2010 16:12 ]

[MrFX]

trouwens dit kom ik net tegen en vermoedelijk zul je hier wel iets aan hebben.

ftp://ftp.compaq.com/pub/...an_filename=TeamingWP.pdf

[enveekaa]

Thanks, subtiele hint?

[ Voor 22% gewijzigd door enveekaa op 13-08-2010 16:15 ]

[MrFX]

was niet als hint bedoeld maar in mijn zoektocht kwam ik het tegen ik heb hem gelijk ook zelf even opgeslagen. In het verleden hebben we aardig wat gezeik gehad met nic teaming dus is dit pdfje is een aanwinst voor ons allen

[ Voor 4% gewijzigd door MrFX op 13-08-2010 16:36 ]

[enveekaa]

Wat ik zo vreemd blijf vinden is het feit dat ik het ene device wel kan pingen en het andere device niet.

[MrFX]

enveekaa schreef op vrijdag 13 augustus 2010 @ 16:33:
Wat ik zo vreemd blijf vinden is het feit dat ik het ene device wel kan pingen en het andere device niet.

Dat is van zoveel factoren afhankelijk. Zijn de nics in de devices allemaal hetzelfde, hebben ze de zelfde settings, dezelfde firmware en dezelfde tcp/ip stack. Dat soort vragen komen bij mijn dan naar voren maar dit soort dingen kunnen aardig wat tijd kosten.

[enveekaa]

In die pdf die je hebt gepost staat wel een intressant stukje over TLB, pagina 51 sectie 4.13-f.

If Blue chooses to transmit from the Primary port, Red will receive a PING Reply from Blue with a source MAC
address of B, destination MAC address of A, a source IP address of 1.1.1.2 and a destination IP address of
1.1.1.1. However, if Blue chooses to transmit from the Non-Primary port, Red will receive a PING reply from Blue
with a source MAC address of E, destination MAC address of A, a source IP address of “1.1.1.2” and a
destination IP address of 1.1.1.1. Either way, Red only distinguishes that it received a PING reply from the Layer
3 address, 1.1.1.2 (refer to “Transmit Load Balancing Methods (algorithms)” for a complete discussion). The user
sees the PING reply message printed on the screen. This completes the entire conversation.

TLB staat bij ons op automatic en bepaald aan de hand van aantal regels welke interface er wordt gebruikt om te transmitten. Afhankelijk van deze keuze is ook het source mac adres. Dat verklaart dus hoe er verschillende mac adressen langs komen.

Vreemde is dat ping replies naar het ene mac adres wel worden ontvangen en ping replies naar het andere mac adres niet. In de HP tooling zie ik dat nic 2 op transmit only staat, die zal dus geen packets ontvangen. Toevallig heeft deze het mac adres wat ik op de lijn zie als ik probeer te pingen naar een niet node die dus niet lijkt te antwoorden.

Dit staat op in 4.3.3

Transmit Load Balancing mode, previously known as Adaptive Load Balancing (ALB), incorporates all the features
of NFT, plus Transmit Load Balancing. In this mode, two to eight ports may be teamed together to function as a
single virtual network port. The load-balancing algorithm used in TLB allows the server to load balance traffic
transmitted from the server. However, traffic received by the server is not load balanced, meaning the Primary
teamed port is responsible for receiving all traffic destined for the server (refer to Figure 4-12). As with NFT, there
are two types of team members, Primary and Non-Primary ports. The Primary port transmits and receives frames
and the non-Primary ports only transmit frames.

Er kan dus maar 1 nic ontvangen, in het stukje hierboven wordt toch echt aangegeven dat het source mac adres van verschillende interfaces kan zijn.

[ Voor 48% gewijzigd door enveekaa op 13-08-2010 17:49 ]

[Vicarious]

enveekaa schreef op vrijdag 13 augustus 2010 @ 16:33:
Wat ik zo vreemd blijf vinden is het feit dat ik het ene device wel kan pingen en het andere device niet.

deze manier van teaming maakt voor elk IP-adres dat hij leert een andere sessie aan. De ene stuurt hij via de ene interface naar buiten, de ander via de andere. Het kan dus zijn dat het via die ene interface wel goed gaat en die andere niet. Het ontvangen kan hij namelijk niet load balancen omdat je geen LACP etherchannel gemaakt hebt.

[enveekaa]

Ja dat realiseerde ik me ook toen ik de de details van TLB las. Echter is het niet logisch dat hij als src mac adres het adres meegeeft van de interface die dus alleen mag transmitten, die interface zal de icmp reply nooit ontvangen.

However, traffic received by the server is not load balanced, meaning the Primary
teamed port is responsible for receiving all traffic destined for the server (refer to Figure 4-12).

Dan zou de netwerk driver dus alle pakketen moeten voorzien van 1 en hetzelfde mac adres, van de interface die ook 'mag' ontvangen. Alhoewel dit ook weer wordt tegengesproken in de manual..

Maandag zie ik wel verder Weekend!

[ Voor 28% gewijzigd door enveekaa op 13-08-2010 23:33 ]

[Wim-Bart]

Een rare vraag. Is de machine gecloned, dus image van gemaakt en vandaar uit geïnstalleerd. Want wij hebben het zelde probleem gehad met teaming waarbij twee servers zelfde MAC adres hadden door het clonen. Je kunt het team MAC adres zien in de teaming instellingen waar je hem ook opnieuw kunt genereren.

Ook een tip, gebruik je TLB en je wijzigd de configuratie (adapter toevoegen of uit team halen) of je vervangt een adapter altijd controleren of je Team MAC adres identiek is aan het MAC adres van de "primaire" adapter. Desnoods hele team weggooien en opnieuw aanmaken.

[enveekaa]

Wim-Bart schreef op zondag 15 augustus 2010 @ 05:18:
Een rare vraag. Is de machine gecloned, dus image van gemaakt en vandaar uit geïnstalleerd. Want wij hebben het zelde probleem gehad met teaming waarbij twee servers zelfde MAC adres hadden door het clonen. Je kunt het team MAC adres zien in de teaming instellingen waar je hem ook opnieuw kunt genereren.

Het zijn geen gecloonde machines.

Ook een tip, gebruik je TLB en je wijzigd de configuratie (adapter toevoegen of uit team halen) of je vervangt een adapter altijd controleren of je Team MAC adres identiek is aan het MAC adres van de "primaire" adapter. Desnoods hele team weggooien en opnieuw aanmaken.

Eens kieken
Update: In Windows hebben beide interfaces hetzelfde mac adres. Dat is volgens mij by design, dat doet de HP software.

[ Voor 7% gewijzigd door enveekaa op 16-08-2010 10:02 ]

[enveekaa]

Voor de geïnteresseerde, er is een support case aangemaakt bij HP;
Ik ga er gewoon vanuit dat dit op te lossen is met een driver update of een settings hier en daar.

Dit is de probleem omschrijving die tot stand is gekomen met een HP technician;

Test 1
Ping from 10.20.5.9 to 10.20.5.57 has source mac 00:16:35:5a:7b:5d, this is the mac of the tx only interface.
Ping reply is sent back to 00:16:35:5a:7b:5d and is not received by the TLB based network team on the 10.20.5.9.

Test 2
Ping from 10.20.5.9 to 10.20.5.23 has source mac 00:16:35:5a:7b:5d, this is also the mac of the tx only interface.
Somehow the ping reply is sent back to 00:16:35:5a:7b:5e and is received by the TLB based network team on the 10.20.5.9.

The interface with mac 00:16:35:5a:7b:5e is the primary interface of the team and therefor test 2 seems fine. Test 1 however returns the ping reply to the wrong mac, this mac belongs to the tx only interface.

TCP/IP traffic works fine from 10.20.5.9 to all recources, ICMP/IP seems to have some troubles.

[enveekaa]

Ik heb het opgegeven, ook met een HP netwerk engineer niet echt verder gekomen.
Na een aantal remote sessies besloten er maar gewoon een lacp link van te maken, en dat werkt prima.

[Vicarious]

enveekaa schreef op dinsdag 31 augustus 2010 @ 09:38:
Ik heb het opgegeven, ook met een HP netwerk engineer niet echt verder gekomen.
Na een aantal remote sessies besloten er maar gewoon een lacp link van te maken, en dat werkt prima.

Let wel goed op de eventlog. Als je daar regelmatig events in voorbij ziet komen dat de LACP teaming (heel even) verbroken is kun je wel eens problemen krijgen. Zorg dus ook dat je drivers up to date zijn e.d.

[enveekaa]

De drivers op de server heb ik vorige week geupdate naar de laastste versie. Thanks voor de tip.