From: Scott F. Robohn (sfr@xxxxxxxxxxxxxx)
Date: Sat Aug 05 2000 - 13:35:51 GMT-3
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