From: Gustavo Novais (gustavo.novais@novabase.pt)
Date: Tue Jul 26 2005 - 20:07:24 GMT-3
Hello
Often (as is my case now) we find that the solution for a specific
problem is tunneling. In this case specific, I have a area 115 which is
connected to a tottaly stubby area 15, which in turn is connected to
area 1, which in turn is connected to area 0. (twisted minds who
invented this scenario)
(Area115)---SW1---(area 15 TS)---R2---(Area1)---R5----Backbone
So to solve this, what I have done (one possible solution) is to vlink
R2 to R5, and tunneled Sw1 to R2, putting the tunnel interfaces on both
ends on area 115.
In order to do this I had to invent a new IP addressing to put on the
tunnel interfaces. My question is, can we do that on a lab environment?
Honestly I think not. So, how can we work around this not using new IP
addressing? IP unnumbered seems obvious, but the problem here is that
the source interface belongs already to another area, area 15. As area
15 is totally stubby we can only see a default coming from R2, so at the
first moment we start running OSPF over the tunnel, we will see
specifically our tunnel source ( reminding that no matter what the
metric, a specific route is always preferred over a default route)
through the tunnel and everything will collapse due to recursive
routing. The only solution I found to this was to use tunnel source and
destination as physical directly connected interfaces VLAN on SW1 and
F0/0 on R2. But as I said earlier those interfaces already belong to an
area... so how will we use IP innumbered here to extend area 115 (which
needs to be connected to the backbone, or like, as is R2 through
Vlink).?
It was just a question I put to myself as I happily invented new
networks as I saw fit, and thought " what about in the lab?"
Any thoughts are welcome.
Thank you
Gustavo
This archive was generated by hypermail 2.1.4 : Sun Sep 04 2005 - 17:00:31 GMT-3