From: Anthony Pace (anthonypace@fastmail.fm)
Date: Tue May 25 2004 - 11:47:31 GMT-3
I saw this thread regarding the preservation of VLANS across a WAN
backbone and it reminded me of something I did several years ago. It used
a CAT5000 LANE card but the configuration was much more vanilla than
LANE. It simply glued VLANs to PVC's on both sides of the ATM link and
you essentially had one big VLAN. I don't know the official name for
this but it was helpful in a situation where routing was not desirable.
It was necessary for device-1 on VLAN-10 (east coast) to arp for device-2
on VLAN-10 (west coast).
I use an LS1010 in these notes below but the ATM cloud behaved the same
way.
Anthony Pace CCIE #10349
ATM PVCs BOUND TO VLANS
This is the config on the LS1010 where the ls1010 is the cloud and both
LANE modules are in this LS1010 (DC and LA). The only thing needed on
the LS1010 (or any switches in the cloud) are ATM PVCs mapped in and out
of the switch (1 per VLAN)
I made the VLAN name PVCs using the same digits so this is pretty easy
to follow. You also need to configure the LEC on each VLAN as well. The
VLAN names on the Ethernet switch can be anything and the VTP domains can
be different or the same. VTP information does not seem to traverse the
LANE so each city will need to be configured individually on the Ethernet
side.
LS1010
atm address 47.0091.8100.0000.0003.3200.8401.0003.3200.8401.00
atm router pnni
no aesa embedded-number left-justified
node 1 level 56 lowest
redistribute atm-static
!
interface ATM12/0/0
no ip address
no ip directed-broadcast
logging event subif-link-status
no atm ilmi-keepalive
!
interface ATM12/0/1
no ip address
no ip directed-broadcast
logging event subif-link-status
no atm ilmi-keepalive
atm pvc 1 111 interface ATM12/0/0 1 111
atm pvc 2 222 interface ATM12/0/0 2 222
atm pvc 3 333 interface ATM12/0/0 3 333
LANE-DC
interface ATM0
logging event subif-link-status
atm preferred phy A
atm pvc 11 1 111 aal5snap
atm pvc 22 2 222 aal5snap
atm pvc 33 3 333 aal5snap
atm bind pvc vlan 11 1
atm bind pvc vlan 22 2
atm bind pvc vlan 33 3
atm ilmi-keepalive
LANE-LA
interface ATM0
logging event subif-link-status
atm preferred phy A
atm pvc 11 1 111 aal5snap
atm pvc 22 2 222 aal5snap
atm pvc 33 3 333 aal5snap
atm bind pvc vlan 11 1
atm bind pvc vlan 22 2
atm bind pvc vlan 33 3
atm ilmi-keepalive
On Tue, 11 May 2004 12:25:38 -0400, "Howard C. Berkowitz"
<hcb@gettcomm.com> said:
> At 5:25 PM +0300 5/11/04, Dan wrote:
> >This draft sound so much like atm LANE? I dont know why the don't
> >just use LANE and adapt it to ethernet ;)
>
> Well, in a manner of speaking, there is an equivalent. You may have
> heard of MPLS being called "ATM without cells", and that's not a bad
> term -- it removes some of the overhead of ATM, can use more flexible
> standard IP routing, and can carry Ethernet payloads.
>
> So Ethernet-over-MPLS is functionally equivalent to LANE. There are
> lots of variants that can apply, especially when bandwidth isn't a
> constraint, such as Ethernet in PPP over L2TP over almost anything,
> including ATM and MPLS.
>
> >
> >
> >On Tue, 11 May 2004 10:20:23 -0400, Howard C. Berkowitz
> ><hcb@gettcomm.com> wrote:
> >
> >>At 1:00 PM +0530 5/11/04, Sachin Shenoy wrote:
> >>>Hi,
> >>>
> >>>I was wondering if trunking over WAN is possible ...
> >>>What I mean by that is
> >>>
> >>>
> >>> Serial Link
> >>> SW1----R1<------------->R2--SW2
> >>>
> >>>Is it possible to trunk VLANs from SW1 to SW2 ???
> >>>(So LAN IP ranges for VLANs on SW1 and SW2 will be the same !)
> >>
> >>In certain, restricted, cases, usually requiring gigabit or faster
> >>transmision media, yes. See such things as Private VLAN Service
> >>(more the IETF term) and QinQ encapsulation (although the latter
> >>is not a WAN protocol, but the distinction between LAN and WAN is
> >>less and less useful). It's also possible using MPLS.
> >>
> >>Why do you consider this a good idea? It has potential scalability
> >>issues, for example, involving both absolute delay greater than
> >>expected by LAN devices. Another scalability issue is that
> >>uncontrolled growth at both locations may cause the safe number of
> >>devices in a broadcast domain to be exceeded.
> >>
> >>I've been asked to do this many times, on the basis that "layer 2
> >>is simpler." At a certain level of scaling, it is not. In
> >>general, in the circumstance you describe, I'd route between the
> >>sites without overwhelming evidence to the contrary. I can even
> >>keep VLAN numbers consistent at both sites.
> >>
> >>Unfortunately, studying for the CCIE lab overempasizes lots of
> >>things that may be possible, but not a good idea in the real world.
> >>
> >>_______________________________________________________________________
> >>Please help support GroupStudy by purchasing your study materials from:
> >>http://shop.groupstudy.com
> >>
> >>Subscription information may be found at:
> >>http://www.groupstudy.com/list/CCIELab.html
> >
> >
> >
> >--
> >Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
> >
> >_______________________________________________________________________
> >Please help support GroupStudy by purchasing your study materials from:
> >http://shop.groupstudy.com
> >
> >Subscription information may be found at:
> >http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> Please help support GroupStudy by purchasing your study materials from:
> http://shop.groupstudy.com
>
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
-- Anthony Pace anthonypace@fastmail.fm-- http://www.fastmail.fm - Consolidate POP email and Hotmail in one place
This archive was generated by hypermail 2.1.4 : Wed Jun 02 2004 - 11:12:16 GMT-3