Opened 14 years ago

Closed 14 years ago

#37 closed incident (fixed)

routering node huub <=> stadhuis

Reported by: huub Owned by: ronald
Keywords: bridging Cc: ronald
Location: Generiek

Description

vanaf NodeHuub (172.17.16.1) werkt de routering naar stadhuis, maar andersom niet. De link is prima (via 172.16.3.210/209).
In de routetabel van stadhuis staat netjes de regel:
172.17.16.0/24 172.16.3.210 UGD 0 9989 sis2

maar een ping of een traceroute naar 172.17.16.1 geeft geen respons (ook niet de boodschap 'no route to host' overigens).

Op NodeHuub zie ik in de routetabel:
172.16.3.208/30 link#5 U 0 8736 sis4 =>
172.16.3.208/28 172.16.3.209 UGD 0 0 sis4
172.16.3.210 link#5 UHS 0 0 lo0

en in rc.node.local staat de regel:
ipv4_addrs_lo0="127.0.0.1/8 172.31.255.1/32"

Klopt die /8 ?

Change History (3)

comment:1 by huub, 14 years ago

De routering van stadhuis naar huub loopt nu via Cope en Vosko1, zie traceroute hieronder. Maar van sunny (proxy62) loopt het pad de kortere weg via de rechtstreekse link huub-stadhuis:

CNodeStadhuis# traceroute huub
traceroute to huub.wleiden.net (172.17.16.1), 64 hops max, 40 byte packets

1 172.16.1.154 (172.16.1.154) 3.227 ms 2.934 ms 2.356 ms
2 172.16.0.169 (172.16.0.169) 8.551 ms 8.741 ms 8.015 ms
3 172.16.4.10 (172.16.4.10) 8.809 ms 7.566 ms 7.987 ms
4 172.17.16.1 (172.17.16.1) 6.133 ms 6.814 ms 6.082 ms

sunny# traceroute stadhuis
traceroute to stadhuis.wleiden.net (172.17.141.1), 64 hops max, 52 byte packets

1 2proxy.CNodeHuub.wLeiden.NET (172.17.16.65) 0.515 ms 0.342 ms 0.339 ms
2 CNodeStadhuis.wLeiden.NET (172.17.141.1) 6.893 ms 8.788 ms 11.730 ms

sunny#

in reply to:  1 comment:2 by ronald, 14 years ago

Cc: ronald added
Keywords: bridging added
Owner: changed from rick to ronald
Status: newassigned

Replying to huub:

De routering van stadhuis naar huub loopt nu via Cope en Vosko1, zie traceroute hieronder. Maar van sunny (proxy62) loopt het pad de kortere weg via de rechtstreekse link huub-stadhuis:

Mea culpa! Heb woensdagavond (-nacht) nog wat zitten prutsen. Het was er nog niet van gekomen dit in een reactie op deze ticket te melden, sorry.

Wat heb ik gedaan? Zowel op de Ubiquiti bridge (nanostation?) aan de Stadhuis kant als op de Engenius bridge aan de kant van Huub het volgende commando uitgevoerd:

iwpriv ath0 wds 1

Met iwpriv ath0 get_wds had ik eerst vastgesteld dat deze vlag aan beide zijden op 0 stond. De wds vlag (wat iets anders is dan WDS mode!) is nodig voor transparent bridging tussen station (managed) en AP (master). Tenminste, als dit net zo werkt als bij MadWifi. Resultaat: ping van Stadhuis naar het master IP address van Huub (172.17.16.1) die het eerst niet meer deed, lukt nu wel, maar loopt kennelijk via een omweg. Ping naar de 2stadhuis interface van Huub gaat wel rechtstreeks.

Het vreemde is, dat Stadhuis wel lvrouted packets krijgt van Huub (van 172.16.3.210) maar hiervan geen tree bouwt.

Mijn veranderingen in de Engenius en Ubiquiti waren handmatig, staan niet in een of andere config file, en zijn dus weg als deze bridges ge-reboot worden. Indien gewenst, kan ik ze ook weer handmatig verwijderen. Roept u maar!

comment:3 by huub, 14 years ago

Resolution: fixed
Status: assignedclosed

Nadat alle wireless bridges in WDS mode zijn gezet lijkt dit probleem verholpen.

Note: See TracTickets for help on using tickets.