On 9/24/07, Boudewijn Visser <bvisser-nlnog at xs4all.nl> wrote:
[geen knips deze keer, aangezien deze reply van Arjan de lijst niet haalde, maar er wel voor bedoeld was]
Iets met de glazen bol van de bofh die op de listserver was gevallen, nadat hij er een tijdje boven had gehangen...
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.
Je wilt de functionaliteit van een firewall toch niet vergelijken met die van een brak willekeurig netwerk device die niet in staat is om op een fatsoenlijke manier met pakketjes om te gaan? Dat een fw het doet kan ik accepteren, maar van een bridge: neen.
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.
Klopt, maar da's zn taak en daarvoor zet je hem ook in. Maar als deze bewuste doos het zou doen (lees: unreachables sturen met het IP adres van een ander device) dan zou ik hem toch eerst een klap geven en vervolgens van 16-hoog uit het raam deurdonderen.* [spanning-tree?]
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.
Vergelijk het met een PtP ja, met als extra featurette dat de betreffende link alleen een IPv4 verbinding biedt, geen ethernet. Het doet nog wat spannende dingen met gedwongen ethernet switching enzo (middels een fixed laag-2 destination), waardoor frames alleen op vooraf bedoelde devices uitkomen. Arjan