Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: nsp: ipv6

L2 VLANs, intermediate network and L3 management (LONG)

 

 

nsp ipv6 RSS feed   Index | Next | Previous | View Threaded


steve at ibctech

Aug 20, 2008, 10:48 PM

Post #1 of 3 (1367 views)
Permalink
L2 VLANs, intermediate network and L3 management (LONG)

Hi all,

It seems as of the last couple of months or so that I've been nearly the
only one to ask questions on this list, so I hope I'm breaking the
silence with a very winded but reasonable, and hopefully simple question.

Please bear with me if you will, with the understanding that I've read,
numerous times, and understand the RFC4861 and RFC4862 specifications,
but have never had the need to use them with any implementation as of yet.

I'm now in a position where I *think* I'd like to, but to me, it's a new
territory.

---

Scenario (IN == Intermediary Network that does not allow q-in-q and
provides a tagged VLAN for each CP):

vlan 501 -- CPE 1
/
/
CO -- IN -- vlan 502 -- CPE 2
\
\
vlan 503 -- CPE 3


CO is a Catalyst switch that has a Cisco .1q trunk port that carries all
VLANs via a single fibre converter from the intermediary network (PUC).

Another port on the switch then trunks to a single Cisco router
interface, where each VLAN has its own sub-int. My network is small, but
I would classify this router to be in the 'access layer'.

For political and logistical purposes, the 'default-gateway' of most
client device that connects to this portion of our network is the router
at the CO side as mentioned above. Each CPE has its own prefix which has
its own sub int on the router.

---

Problem:

The Cat switch is in place so that we can administratively put one of
the ports into 'sw ac vlan xxx' to trace problems.

That said, if we need to reach portions of the client network via Layer
3, we need to manually configure an IP address within their VLANs scope
in order to do anything useful. I don't want to do this.

--

Question:

With a very good understanding of the specifications, but with no
experience whatsoever, could anyone provide pros/cons and/or
configuration examples on what I'm thinking?

I was thinking that I could almost leave all the v4 info statically
set/routed and left alone, so I don't have to ask the client for (or
reserve) addresses for management purposes. (A couple of clients are
Layer-2 with 1918 in-and-out, and a couple others I have eBGP with
private ASs as they connect to multiple physical ingress methods to our
network).

In this regard, with the lack of CPE that our (and I believe most other
SP) clients have that comply with 4861 and 4862 (or IPv6 in general),
I'm thinking I could use this to my advantage.

Perhaps I can tune the router to provide us with dynamic management
layer-3 info without any manual configuration, and without the IPv4
space the client has been assigned interfered with.

--

Thoughts:

- set each VLAN sub-int on the router a EUI-64 address
- inform the router that each sub-int needs to perform on-link prefix
advertisement
- I enable VLAN access on a switchport, plug in a laptop, and
immediately am on link with CO and CP ends, L2 *and* L3 (we have
equipment at the client prem for this purpose, another Cisco switch)

--

Summary:

Will this work?

Will using IPv6 as a dynamic management 'hack' work in this regard?

Can someone introduce to me a config from a Cisco that displays portions
of the 4861 and 4862 specs?

If you've read this far, I appreciate it. Honestly, I'm typing with a
high fever and without having slept properly for a few days due to being
very ill.

Without being able to sleep, I really have nothing better to do at this
time than to poke the people who breath IPv6 for information ;)

Thanks all,

Steve


david.freedman at uk

Aug 21, 2008, 2:05 AM

Post #2 of 3 (1305 views)
Permalink
RE: L2 VLANs, intermediate network and L3 management (LONG) [In reply to]

<snip>
>Summary:
>
>Will this work?
>
>Will using IPv6 as a dynamic management 'hack' work in this regard?

Sure, if you have access to all the kit, you can manage via link local, no need
to configure anything specific.

This would mean though that you have to be on the router in order to reach the CPE.

The alternative is to use ULA (RFC4193) as global but this could be problematic as you deploy
v6 authentic global addresses to your clients, they will want real addressing, you would have to overlap.

Now, if we hadn't deprecated the site local scope.......

>If you've read this far, I appreciate it. Honestly, I'm typing with a
>high fever and without having slept properly for a few days due to being
>very ill.

Good luck, and hope you get better :)

Dave.


steve at ibctech

Aug 21, 2008, 5:14 AM

Post #3 of 3 (1290 views)
Permalink
Re: L2 VLANs, intermediate network and L3 management (LONG) [In reply to]

David Freedman wrote:

> >Will using IPv6 as a dynamic management 'hack' work in this regard?
>
> Sure, if you have access to all the kit, you can manage via link local,
> no need
> to configure anything specific.

Thanks for the feedback David. The thought of using link local addresses
never even crossed my mind.

> This would mean though that you have to be on the router in order to
> reach the CPE.

Not very feasible.

> The alternative is to use ULA (RFC4193) as global but this could be
> problematic as you deploy
> v6 authentic global addresses to your clients, they will want real
> addressing, you would have to overlap.

This method does not appear to be scalable. My handful of fibre clients
is going to grow too rapidly to have to go back and re-organize/manage
ULAs just for management purposes.

> Now, if we hadn't deprecated the site local scope.......

LOL, most of the RFCs, BCPs and drafts I've read have included the
deprecated site local scope, but since I've hopped on the IPv6 train
after the fact, I've never contemplated a scenario where it would be
used. This would be a perfect example...

With the comments you made, I'm thinking it makes the most sense simply
to overlap the IPv4 with a proper IPv6 /48 to each VLAN, even though the
clients will not be using it yet. I can get my management requirements
resolved, and when my providers finally provide native IPv6, then things
will already be in place.

I guess today I'll be finding out how auto configuration works in
practice. It's a great piece of the specification, I've just not had the
need for it until now.

Cheers,

Steve

nsp ipv6 RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.