From: John Conzone (jkconzone@xxxxxxxx)
Date: Sat Aug 05 2000 - 15:19:43 GMT-3
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 .......... <<
>
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 08:24:21 GMT-3