Closed mcr closed 9 years ago
You are correct; the route shouldn't be there.
Also, while we're are it: Do you think this scenario is relevant? Since nobody seemed to care about it I was planning to purge it from the documentation starting from Jool 3.3. I was wondering if there is a reason left that makes it worth the time people spends reading it. I originally meant it to convey Jool's independence to any number of interfaces, but a recent proofreader recently rolled his eyes at it.
And one more thing: I'm truly awful at predicting release dates, but all that's left is a weekend of trying to come up with test cases we might have not yet considered, and tying some loose ends in the documentation. I'd say Jool 3.3 will be wrapped in a few days.
The addition of Stateless NAT64 has prompted considerable documentation rewrites, and perhaps you might want to jump to 3.3's documentation right away. Here's a snapshot, if you so desire.
Oh, and if you want to run it, it's at the testing branch.
I think that the example is valuable, because it shows the configuration in another fashion. I think that the 192.0.2.2 IP is somehow "default" --- at least, when I configured a system as shown by example 1, but using my own IP choices, that the traffic came out as 192.0.2.2, which didn't work. If that is in fact, default in the module, that needs to be stated more explicitely.
The configuration of A includes the last line setting the default route. Why? I think that A should see B's address (192.0.2.1) as an interface route, and be happy with that. Or am I missing something? C's traffic will get translated to B's address.