On 12/30/14 4:49 AM, Stuart Henderson wrote: > On 2014-12-28, Daniel Ouellet <[email protected]> wrote: >> When all is done it will be ospf over vether over gif tunnel > > Does vether give any benefit here? I think that you should just be able > to route the addresses over the gif interface without the extra layer > of indirection (and overhead from carrying ethernet headers). > > The classic use case for vether is where you are bridging an ethernet > at one location to a router at another (without needing to connect to a > physical network at the second location).
Hi Stuart. This is still a work in progress and all is in the lab so things are changing. The Vether was to eliminate get MTU aspect after reading Theo paper on the setup in Calgary. At this point I have taken out the vether and the bridge, making it simpler. But I have to say there is some much to read on the net and many choices that coming with the simplest and most efficient one is not always easy. It sure if fun to play around and tests things, even if at time I pull my hairs a bit like I did with ikev2. Even GIF I wasn't sure and did start with GRE instead. Much easier to setup with Cisco router, or I should say, the only one that works with Cisco, but then I decided to scrap Cisco all together from the picture! That's for taking the time to answer this regardless. Te only answer I got. Always nice to see you interested in some weird things still. (:> I have lots more coming down, but may well be boring for most. I am testing now the processing with different encryption supported on Iked with and without the ASE instruction set enable or disable on Xeon processor to see for various setup's. One interesting things I am working on as well is a way, or try to find a way to do the queue and have decent QoS on lines like Fios and the like where you really have no QoS what so ever. Yes you can do outgoing, not much you can do on the incoming, but I am looking at how I could for example limit the incoming traffic a bit lower then what's there to not have congestion and not provide QoS, but at a minimum allow the important traffic to come in easier then in congested line. Like I am playing with 75/75Mb Fios at home for testing, except there is plenty of time where that 75 Mb goes down to 2 or 3 Mb, most of the time down to 35/12 and I have seen rare occasion, but it happen, where it went as low as 750K. I am not sure of what I will do, but one idea was as I do have both GIF for not encrypted traffic when I actually use it to carry over routable IP's on a single not fix one and ipsec tunnel as well where may be a health check would identify congestion and then restrict the incoming lower then what the connection is at that time to permit the critical one to work. I am not sure I explain it well as it's work in progress as well, but fun and yes so far I have success, or mostly success anyway. In short is a way to dynamically adjust the queue in pf to adapt itself to the capacity available that is always changing and always keeping it someone what lower and allowing what I would call a poor man QoS by default, even if that's not the case at all! One fun part was to change the remote part of the GIF configuration automatically when the local outside IP's is changing on Fios or Comcast for example. (:> Same with Iked oppose to use npppd. Anyway, thanks for your input, it's a;ways well received. (:> Daniel
