= AvdO = BV = AvdO = BV
[geen knips deze keer, aangezien deze reply van Arjan de lijst niet haalde, maar er wel voor bedoeld was]
[knip wireless bridge, speelt met DSCP en doet ook TTL decrement] -snip- Mee eens, dwz, ik vind het wel TTL decrementen, en dan niet sturen van unreachables ook verkeerd gedrag, en kan er niet echt een argument voor verzinnen waarom je het zou willen. Het enige wat me nu voor de geest komt is dat de * * * in de traceroute een indicatie geeft dat het pad tussen twee hops "bijzonder" is [radio<->ethernet] en geen gewone PtP of ether segment.
Wat Steven ook al zei ja, dat was mijn argument ook. De reden dat het kreng geen unreachables stuurt is me ook nog vaag, maar zit waarschijnlijk in de hoek van a) het is een semi laag-twee device dus waarom ICMP's sturen in de dataplane of b) we hebben in de controlplane voor het gemak OOK maar alle binnenkomende ICMP's dichtgezet, want dat is zo lekker veilig... (must resist.....)
(of je er wat mee kunt, een aantal opinies pro of con van nlnog, is iets anders..).
Het geeft in ieder geval een indicatie of mijn mening al dan niet het stempel 'absurd' verdient.
*cue voor-de-hand-liggende-inkoppertjes*
Ik ben nooit vies van makkelijke inkoppertjes, maar dit is t? :-)
Feitelijk is laag-3 manipulatie door een laag-2 device al een beetje verdacht, maar er zijn genoeg situaties waar het nodig of handig is, zoals wanneer het voor de hand liggende L3 device om technische of organistorische redenen niet zelf de L3 manipulaties kan doen.
Sja, het hele device is uberhaupt al een beetje een gek ding, maar het gaat te ver om alle design issues hier te bespreken. Neem van me aan dat er al meer dingen zijn waar enkele wenkbrauwen over opgetrokken zijn. Maar het ding wordt in eerste instantie als laag-2 beestje neergezet door $vendor en in mijn optiek is het dat ook. Ware het niet dat het dus op een paar punten laag-3 aware is en daar op wederom een paar punten ook op kan acteren, zoals het beschreven DSCP verhaal, wat laag-3 filtering, etc. Maar qua IP forwarding is het ding gewoon geen laag-3 device en in mijn optiek moet je dan uberhaupt van de TTL afblijven. Wat mij dwarsboomt in die stelling is RFC791 die dus gewoon simpel zegt : in IP rommelen = TTL verlagen. Gevalletje vlees noch vis.
Als de bridge wel icmp unreachables moet sturen is de vraag natuurlijk met welk ip adres.
Dat is dus de grap, het ding heeft maar *een* IP adres, in de control plane, in een heel ander subnet (en in de uiteindelijke setup ook in een heel ander vlan).
En dat is natuurlijk om allerlei redenen onzin of zinloos om te gebruiken, als icmp source. (Want de kans is heel groot dat zo'n adres er toch niet door komt, om allerlei redenen. Hoe beter je netwerk in elkaar zit, des te kleiner die kans)
Een redelijke keuze zou het IP adres van het upstream (qua richting van het ontvangen verkeer) device zijn, maar dat kan natuurlijk verwarring geven nadat de volgende hop (dat upstream device) dan hetzelfde antwoord geeft.
Hmm, unreachables sturen met een IP adres dat niet aan jou toebehoort? Dat lijkt me niet wenselijk.
Normaal niet, maar _als_ je hier iets moet sturen, is dit beter dan het mgmt adres. En al helemaal als dat mgmt ip in een veilige, gefilterde, rfc1918 etc etc reeks zit. Een firewall die reject ipv dropt doet niets anders, een rst terug sturen met als source het adres van de bedoelde destination. Weet niet zeker wat een fw doet als hij icmp terug moet sturen; port unreachable van de destination of admin prohibited van zichzelf. Maar een firewall in een L2 setup heeft weinig keus, die moet ook alles "spoofen" aan rejects. Nu maakt de gemiddelde fw admin het v???l veiliger door drop ipv reject te kiezen, en is het voor hen uberhaupt geen vraag, maar dat is weer een andere discussie.
Anyway, in dit geval is dus geen TTL decrement m.i. de betere keuze. (wel zou het ding spanning-tree moeten [kunnen] doen... ).
Waarom? In de onderhavige setup is daar totaal geen noodzaak voor noch is het wenselijk.
Ok, ik ken die setup niet. Maar als ik L2 bridge hoor, dan denk ik aan "moet loopfree zijn", met als extra reminder de context van TTL decrement, die op L3 loopend verkeer uiteindelijk moet stoppen. Maar inderdaad, in een pure PtP setup is het niet nodig. Boudewijn
Arjan