From: Scott F. Robohn (sfr@xxxxxxxxxxxxxx)
Date: Sat Aug 05 2000 - 16:59:51 GMT-3
John,
Let's try it this way. The encapsulation on each end of the
PVC must match. To say that the ecnapsulation is aal5snap
is not specific enough because RFC1483 defines several
differnt modes of LLC/SNAP encapsulation.
The LANE module *only* supports RFC1483 bridged (plus LANE);
it doesn't support the RFC1483 routed format. It's really
just a big fast bridge, right? So it's using aal5snap
BRIDGED because it's sending out ethernet frames,
encapsulated in AAL5, using the LLC/SNAP format for bridged
PDUs.
The router has to accomdate the LANE module's limitations,
so it must be able to decapsulate those AAL5 frames
properly. If you route IP on the router interface, it will
use RFC1483 ROUTED encapsulation, even thought you're using
the same 'aal5snap' keyword for encap-type (Note that this
is the default on any router interface; IP is routed, and
any aal5snap PVCs will be using RFC1483 routed encap).
To match the router up with the LANE module, you put the
router subinterface in a bridge group, which causes it the
router to now decapsulate the AAL5 frames as RFC1483
BRIDGED, just as they were encapsulated on the sending end.
Link that subint up with a BVI, put an ip address on the
BVI, and now that BVI can serve as the default gateway for
any hosts sitting on ether ports in the corresponding cat5
vlan (the one with this PVC bound to it). The IP packet can
now be routed to any other routed interface, BVI or
otherwise.
What you have here is not a real common implementation. As
you noted, a PVC between two router interface is much more
common. Both router interfaces route IP by default, so an
aal5snap PVC will use RFC1483 ROUTED encap, and the encap
now matches on both ends. No kludgy bridging or anything
like that. Here's a pretty typical config:
----------
hostname rtrA
!
interface ATM1/0
ip address 192.1.1.1 255.255.255.0
pvc 0/100
protocol ip 192.1.1.2 broadcast
encapsulation aal5snap
----------
hostname rtrB
!
interface ATM1/0
ip address 192.1.1.2 255.255.255.0
pvc 0/100
protocol ip 192.1.1.1 broadcast
encapsulation aal5snap
----------
hostname ls1010
!
interface ATM0/0/1
atm pvc 0 100 interface ATM0/0/0 0 100
----------
Just like pt-pt serial, there are NO MAC ADDRESSES involved
here, so the RFC1483 routed format doesn't preserve MAC
addrs (see the routed encap). For bridging vlans across a
PVC, we *must* preserve the MAC addresses, so we need an
encap that will do that (see the bridged encap).
Does that make more sense?
Come take CATM from me and I promise to make it all crystal
clear :)
Gotta get back to IPSec...
sfr
RTP 8/14-15
John Conzone wrote:
>
> Scott, let me see if I follow.
> A ethernet user needs to go out to the net. His default gateway is the
> BVI on the MGX. Say he is on another routed vlan #2 on the CAT. His ethernet
> packet with IP inside gets "routed" from interface VLAN2 to interface
> VLAN100, which is the VLAN that is bound to the ATM pvc on the LANE card in
> the CAT. The lane card takes that ethernet packet, which has IP inside, and
> SARs it into 45 byte payloads, appends the header with the PVC info and
> ships it across the PVC (LS1010---BPX---MGX) to the MGX switch card (this is
> the RFC1483 encap). I'm okay with all of that. I lose it at the MGX side.
> So now the MGX receives the packet on his switch card, which has a PVC
> mapped to a subinterface on the MGX RSM. You're saying that without bridging
> on the RSM subinterface, the 1483 encapsulation from the Lane card won't be
> decapsulated? The pvc on the RSM is AAL5 snap, so doesn't that tell the
> interface to expect the proper encapsulation?
> I kinda of see how the VLAN interface on the CAT5 and the BVI on the RSM
> equate to doing the layer 3, as do the Lane interface and the RSM
> subinterface equate to do the layer 2.
>
> CAT5 Vlan int(layer 3)<-->LANE mod(1483)<-->RSM sub(l1483)<-->BVI(layer 3)
> Is this the general idea?
>
> How is this different than a pvc bewteen 2 ATM interfaces on a router
> with IP. If I ccan compare it to that it will make it easier to understand.
> Thanks!
>
> I guess I need to bone up on rfc1483, 1490 and associated rfc's.
>
> ----- Original Message -----
> From: "Scott F. Robohn" <sfr@mentortech.com>
> To: "John Conzone" <jkconzone@home.com>; "ccielab" <ccielab@groupstudy.com>
> Sent: Saturday, August 05, 2000 12:35 PM
> Subject: Re: Cat5000 Vlan int---Lane Mod-----Ls1010-----BPX-----MGX RSM
>
> > John,
> >
> > This comes down to the RFC1483 encapsulation type used on a
> > LANE module and an RSM subinterface.
> >
> > The LANE module only supports LANE and RFC1483 bridged
> > PVCs. For PVCs, the LANE mod takes an ether frame (versus
> > an IP packet), encapsulates it in AAL5, and then chops it up
> > into cells. The MGX RSM has to be configured to expect an
> > ether frame, NOT an IP datagram; being in a bridge group
> > tells it to expect ether frames. If it had an IP address on
> > that interface, it would be routing IP, and would therefore
> > expect an IP datagram to be in the AAL5 frame.
> >
> > It's very similar to an encapsulation mismatch; e.g., a T1
> > set to HDLC on one end and Frame Relay on the other end.
> > You have to have the same encapsulation types on each end
> > (RFC1483 routed or RFC1483 bridged).
> >
> > The RFC1483 bridged format is used to span a VLAN across an
> > ATM PVC, which is the application you see in your network.
> > Note that what you see here is *not* LANE. The RFC1483
> > routed format is used very much like point-to-point serial
> > connections; e.g., two routers, routing IP, sending over
> > ATM.
> >
> > Bottom Line: In general, the ends that terminate the PVC
> > have to be set to the same encapsulation type: routed PDU's
> > or bridged PDU's.
> >
> > There are some ways to tweak this using something called
> > 'half-bridging' on the 6400 platform, but let's not get into
> > that here.
> >
> > BTW, RFC1483 has been superceded by RFC2684, but most
> > implementations reference 1483.
> >
> > HTH,
> > sfr
> >
> > PS - Here are the encapsulation formats:
> >
> > (1) RFC 1483 routed (sec 4.1):
> >
> > In the particular case of an Internet IP PDU, the Ethertype
> > value is 0x08-00:
> >
> > Payload Format for Routed IP PDUs
> > +-------------------------------+
> > | LLC 0xAA-AA-03 |
> > +-------------------------------+
> > | OUI 0x00-00-00 |
> > +-------------------------------+
> > | EtherType 0x08-00 |
> > +-------------------------------+
> > | . |
> > | IP PDU |
> > | (up to 2^16 - 9 octets) |
> > | . |
> > +-------------------------------+
> > | PAD ( 0 - 47 octets) |
> > +-------------------------------+ -------
> > | CPCS-UU (1 octet ) |
> > +-------------------------------+
> > | CPI (1 octet ) |
> > +-------------------------------+CPCS-PDU
> > Trailer
> > | Length (2 octets) |
> > +-------------------------------|
> > | CRC (4 octets) |
> > +-------------------------------+ -------
> >
> >
> > (2) RFC 1483 bridged:
> >
> > Payload Format for Bridged Ethernet/802.3
> > PDUs
> > +-------------------------------+
> > | LLC 0xAA-AA-03 |
> > +-------------------------------+
> > | OUI 0x00-80-C2 |
> > +-------------------------------+
> > | PID 0x00-01 or 0x00-07 |
> > +-------------------------------+
> > | PAD 0x00-00 |
> > +-------------------------------+
> > | MAC destination address |
> > +-------------------------------+
> > | |
> > | (remainder of MAC frame) |
> > | |
> > +-------------------------------+
> > | LAN FCS (if PID is 0x00-01) |
> > +-------------------------------+
> > | PAD ( 0 - 47 octets) |
> > +-------------------------------+ -------
> > | CPCS-UU (1 octet ) |
> > +-------------------------------+
> > | CPI (1 octet ) |
> > +-------------------------------+CPCS-PDU
> > Trailer
> > | Length (2 octets) |
> > +-------------------------------|
> > | CRC (4 octets) |
> > +-------------------------------+ -------
> >
> > In either case (routed or bridged), these AAL5 frames
> > consist of some whole number of 48-byte chunks that can be
> > put into ATM cell payloads.
> >
> > > John Conzone wrote:
> > >
> > > I've started at a new job and am familiarizing myself
> > > with the network. We have a large BPX/MGX backbone which
> > > we use to provide ISP service, but our coporate LAN/WAN
> > > utilizes the backbone services as well.
> > > I was looking at the LAN in our local office and noted
> > > that there is a CAT 5000 with a rsp running VLAN
> > > interfaces for each local subnet. The Cat has a LANE mod
> > > and tS1010 in the same chassio. The default gateway for
> > > the local LAN is a virtual subinterface on a MGX RSM.
> > > Here's my question. VLAN 100 on the CAT 5 (int
> > > VLAN100, ip 192.168.201.2) is bound to a pvc (0/32) on the
> > > LANE mod (atm pvc bind command). The lane mod bridges
> > > through the backplane to the LS1010, where pvc 0/32
> > > is switched out another LS1010 port to the BPX as pvc
> > > 0/702, and then switched to the MGX as 0/702, which is
> > > then mapped to a virtual subinterface on the MGX router
> > > blade.
> > > What I noted is that on the MGX router blade, the
> > > virtual subinterface has no ip address. Instead it has a
> > > bridge group assigned, and then IRB is enabled. The ip
> > > address 192.168.201.1 is assigend to the BVI. No other
> > > interfaces on the MGX RSM are in this bride group. Bridge
> > > 1 is routing IP.
> > > I asked the guy who set this up why and he said that
> > > it wouldn't work if the ip was assigned on the MGX RSM
> > > subinterface directly. He doesn't remember why but says it
> > > wouldn't work any other way.
> > > Not having a lot of production hands on with ATM yet
> > > (thats why I took the job!) I can't figure out why the
> > > IRB. If we're not bridging with any other interfaces, why
> > > not route rght on the sub?
> > > Any ideas?
> >
> > --
> > >> Scott F. Robohn, CCSI #20826/CCNP/CCDP ........ 703-623-3752 <<
> > >> mentor technologies ..... Service Provider Engineering Group <<
> > >> mailto:sfr@mentortech.com ........ http://www.mentortech.com <<
> > >> ........... Formerly Chesapeake Network Solutions .......... <<
> >
-- >> Scott F. Robohn, CCSI #20826/CCNP/CCDP ........ 703-623-3752 << >> mentor technologies ..... Service Provider Engineering Group << >> mailto:sfr@mentortech.com ........ http://www.mentortech.com << >> ........... Formerly Chesapeake Network Solutions .......... <<
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 08:24:21 GMT-3