Re: Regarding bridge group and Bridge domain

Hi Paul,

Thanks for ur information. I got the point. How the IP data will be
extracted on the other end of the Layer2 VPN?

I mean what will be the thought process of router when it sees a Psuedowire
Frame ?

Just can u tell me the process of it?

On Sat, Jan 14, 2012 at 12:12 AM, Aaron <aaron1_at_gvtc.com> wrote:

> Paul, thanks so much for the nice explanation. It wasn't me that
> originally
> asked the question....i think it was "CCIE KID" but I learned from your
> response too, so thanks again.
>
> Aaron
>
> -----Original Message-----
> From: Paul Negron [mailto:negron.paul_at_gmail.com]
> Sent: Friday, January 13, 2012 10:16 AM
> To: Aaron; 'CCIE KID'
> Cc: ccielab_at_groupstudy.com
> Subject: Re: Regarding bridge group and Bridge domain
>
> Aaron,
>
> I used the Internetworking Concept when I worked with an ATM backbone years
> ago. If you had an ATM backbone with Frame Relay on the edges, you would
> need to take the data that was using Frame-Relay for Transport and have it
> ride the backbone in ATM. Eventually it would have to be dropped off as
> Frame-Relay again. This was Network Interworking (FRF8). When a client had
> a
> Frame Relay Access Device on the edge (FRAD) and an ATM edge point. I would
> not need to convert back to Frame-Relay but would need to leave it within
> ATM. This was called Service Interworking.(FRF5)
>
> This concept is also supported with MPLS. If we have Frame on one side and
> Ethernet on the other, as an example, the thing they have in common is they
> both carry IP traffic. All we do is terminate the framing on one end .
> Remove the IP packet from the frame (Frame Relay) and have it ride over an
> IP backbone. Reinsert the IP info into a different encapsulation (Ethernet)
> and send it to the end device. We use NLPID to accomplish this, which is
> why
> we need IETF Frame Relay on one side.
>
> I have over simplified this example to help you understand the concept
> since
> that's what you were asking....right?
>
> Paul
> --
> Paul Negron
> CCIE# 14856 CCSI# 22752
> Senior Technical Instructor
>
>
>
> > From: Aaron <aaron1_at_gvtc.com>
> > Reply-To: Aaron <aaron1_at_gvtc.com>
> > Date: Fri, 13 Jan 2012 10:00:14 -0600
> > To: 'CCIE KID' <eliteccie_at_gmail.com>
> > Cc: <ccielab_at_groupstudy.com>
> > Subject: RE: Regarding bridge group and Bridge domain
> >
> > I don't understand the idea of interworking and what it means
> yet..however,
> > look what I found. This guy has a small lab showing frame relay to vlan
> > (eth) AToM and I see the command "interworking ip" in there too.under the
> pw
> > class.
> >
> > http://enotepad.wordpress.com/2010/04/14/framepvctovlan/
> >
> > Aaron
> >
> >
> >
> > From: CCIE KID [mailto:eliteccie_at_gmail.com]
> > Sent: Friday, January 13, 2012 1:16 AM
> > To: Aaron
> > Cc: Cisco certification
> > Subject: Re: Regarding bridge group and Bridge domain
> >
> >
> >
> > hi aaron, thanks for the reply
> >
> > Can u just give some brief about Atom Interworking. I m not very sure how
> it
> > works. can u give ur thoughts
> > one side of Ce to PE is ethernet and the other side is Frame Relay
> >
> > On Wed, Jan 11, 2012 at 9:20 PM, Aaron <aaron1_at_gvtc.com> wrote:
> >
> > I was told by someone a few months ago when I was config'ing my ASR9K's
> that
> > BG is a way of simply organizing the underlying BD's. I believe you
> can't
> > configure a BD without first config'ing an owning BG. So you can have
> > several BD's in one overarching BG. Again, the BD's are organized into a
> > BG. I guess you could create one to one....one bg for one bd....but I
> > didn't do my network that way....
> >
> > I took common bd's and put them into one bg
> >
> > The bd is what gets you the segregated broadcast domain/vlan entity that
> we
> > all understand. Not the bg. So the bd = broadcast domain. (funny that
> bd
> > doesn't stand for broadcast domain but instead stands for bridge domain,
> but
> > as I understand, the bd is in fact the broadcast domain....so the bg is a
> > way of organizing a bunch of bd's into one overarching bg.)
> >
> > Yeah, so I don't think the owning BG allows any technical forwarding of
> > traffic or anything like that amongst underlying bd's.
> >
> > As I understand it, you MUST enter the "l2vpn" config mode BEFORE you can
> > configure any bg/bd at all.
> >
> > Also, as I understand it, AToM I think is cisco-speak for EoMPLS.....
> >
> > And as I understand AToM/EoMPLS, this is known as MPLS L2VPN.... ethernet
> > frames over mpls frames over ethernet frames...don't you love it!
> >
> > So stack looks like ... ip/eth/mpls/eth
> >
> > Also, as I understand it, there are a variety of ways to accomplish MPLS
> > L2VPN/AToM.....i think EoMPLS is one of them....i think there is port
> mode
> > and vlan mode....i think there is VPLS (I believe for multipoint
> scenarios)
> > and I think EoMPLS might be more suited for p-to-p...not sure though, but
> > that's what I used in my network for something I'm doing....also, more
> > terminology...
> >
> > I think in EoMPLS...
> >
> > - the connection from edge/customer gear to the mpls
> imposition/disposition
> > device (label cloud edge device) is known as AC (attachment circuit)
> > --- so you should probably have (2) AC's, one on each edge of mpls cloud
> > that you are emulating layer 2 for...
> > - the mpls connection through the mpls cloud I believe is known as PW
> > (pseudowire)
> > - I think in some gear (ME3600) you provision the pw with command called
> > "xconnect" under perhaps the vlan svi or eth port (maybe that's where the
> > difference in port mode and vlan mode is for config'ing it)
> > - in IOS XR gear I see that it's not xconnect for the pw but is "neighbor
> > x.x.x.x" under the owning bd which is of course under the owning bg....
> > --- I think in both cases you specify encap mpls for xconnect/neighbor or
> a
> > pw class in which you specifiy in the pw class the encap mpls
> >
> > Also in your link to ciscosupport I see that there is another type of
> maybe
> > it's mpls l2vpn, e-line (vpws).
> >
> > From your other email, I don't know the difference from local connect and
> > local bridging...that link you sent shows local bridging using some dot1q
> > stuff on it and even qnq...maybe that's the difference. Not sure
> >
> > This mpls l2vpn stuff btw is *very* different than MPLS L3VPN's....wayyyy
> > different. L3vpn is based on routing tricks with vrf instances and using
> > mp-ibgp as the signaling protocol in the mpls cloud to carry the
> uppermost
> > label for l3vpn segregation....(I think I heard someone say recently that
> > you don't really have to have an mpls core to do mpls l3vpn's, I was
> amazed)
> >
> > Aaron
> >
> >
> >
> > -----Original Message-----
> > From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of
> CCIE
> > KID
> > Sent: Tuesday, January 10, 2012 12:49 AM
> > To: Cisco certification; CCIE OSL
> > Subject: Regarding bridge group and Bridge domain
> >
> > Hi fellas,
> >
> > What is the exact difference between the bridge group and bridge domain
> in
> > L2VPN configs.
> >
> > What is the exact purpose of bridge group and bridge domain in Atom
> configs
> >
> > --
> > With Warmest Regards,
> >
> > CCIE KID
> > CCIE#29992 (Security)
> >
> >
> >
> > Blogs and organic groups at http://www.ccie.net
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > --
> > With Warmest Regards,
> >
> > CCIE KID
> > CCIE#29992 (Security)
> >
> >
> > Blogs and organic groups at http://www.ccie.net
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> >
> >
> >
> >
> >
> >
> >
>
>
>

-- 
With Warmest Regards,
CCIE KID
CCIE#29992 (Security)
Blogs and organic groups at http://www.ccie.net