From: Scott F. Robohn (sfr@xxxxxxxxxxxxxx)
Date: Sat Aug 05 2000 - 23:02:10 GMT-3
John,
My pleasure.
BTW, I'm pretty sure the BPX class focuses on WAN ATM topics
and won't touch routers much, so you won't get too deep into
topic like RFC1483, bridging, encap types, etc. CATM
focuses more on campus ATM issues like these, and focuses on
the LS1010 and ATM interfaces on routers.
At the risk of 'advertising', you can see our scheduled CATM
dates at http://www.mentortech.com/learn/sched_CATM.shtml
AFAIK, I'm teaching the 11/13 class in Falls Church, VA.
My apologies to the list for such blatant class recruiting -
but John *did* ask :) (Thanks, John).
sfr
John Conzone wrote:
>
> Scott, I got it! Thanks for taking the time!
> My new company will be happy to send me to your class, I'm sure. They
> are packing me off to BPX class. When and where is the class? If I get this
> much for free, I can only imagine what I'll get if I pay for a class! Please
> let me know.
>
> From: "Scott F. Robohn" <sfr@mentortech.com>
> To: "John Conzone" <jkconzone@home.com>; "ccielab" <ccielab@groupstudy.com>
> Sent: Saturday, August 05, 2000 3:59 PM
> Subject: Re: Cat5000 Vlan int---Lane Mod-----Ls1010-----BPX-----MGX RSM
>
> > 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 .......... <<
-- >> 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