Re: Transparent Bridging across Frame-relay

From: ccie (ccie@netchild.pub.sa)
Date: Thu Aug 21 2003 - 17:41:55 GMT-3


Another solution that cross my mind is layer 2 tunneling protocol version 3
,l2tpv3. it allows you to tunnel frame relay, ethernet, VLANs, VPN. It is a
layer 2 solution and as cisco said in its web site it work well with sprint.

With l2tpv3, you will build l2tpv3 tunnel called "psudo wire" on a top of
your IP core netowrk. With this you can run any kind of IP routing technique
to utilize your bandwidth equally. However, it is not supported for all
cisco routers. I think GSR, ESR, 7500, 7400, 7200 will do the job.

http://www.cisco.com/en/US/netsol/ns110/ns170/ns172/ns155/networking_solutio
ns_white_paper09186a00800a8443.shtml

and you can check this seminar on-demand
http://www.cisco.com/pcgi-bin/sreg2/register/regdetail.pl?SEMINAR_ID=4418&SE
MINAR_TYPE=O&LANGUAGE_ID=E&SESSION_ID=&PAGE_NO=SEMINARLIST&USER_TYPE=&CITY_I
D=&STATE_ID=&SOLUTION_ID=ALL&FROM_DATE=&TO_DATE=&KEYWORD=&

NetChild,
----- Original Message -----
From: "asadovnikov" <asadovnikov@comcast.net>
To: "'Danny Lane'" <techtips@wi.rr.com>; <ccielab@groupstudy.com>
Sent: Friday, August 22, 2003 7:56 AM
Subject: RE: Transparent Bridging across Frame-relay

> I have to start with saying that what you do is sort of considered this
days
> to be a bad design practice. My answer most likely would be "we need to
> purchase 2 T3, and I know it is a lot of money, but it is only reliable
way
> to get this bridging mess going, or applications need to be converted to
IP.
>
> But here are few suggestions which may make your life a little easier...
>
> First I would rather do it old-fashion way, not by utilizing latest 12.3
> features, but if you really like to go there here is a starting point
>
http://www.cisco.com/en/US/products/sw/netmgtsw/ps5331/products_user_guide_c
> hapter09186a008019e08f.html#115377. My advice - stay away from it.
>
> I do not send configurations as I do not know details of your environment
> enough to . Obviously the suggestions are subject to testing.
>
> 01. Option - Statistical Spanning-tree load balancing
> -----------------------------------------------------
> The reason you have this utilization is that spanning tree blocks on the
> same port for all bridge-groups. By adjusting spanning priority you can
get
> 2 to block on first T1, and 2 on the second. What you need to do is find
> where it is blocking 'show spantree block' and on another (!!!) side put
the
> following commands on 2 out of 4 subinterfaces: 'bridge-group 104 priority
> 144' (adjust the bridge number as needed).
>
> This is your best option if majority of you traffic is bridged.
>
> 02. Option 2 - PPP multilink + GRE.
> ----------------------------------
>
> You can bind together 2 Serial with multilink PPP (may want to get rid of
> the Frame first) and enable IP but not bridge on the multilink interface.
> Then add 4 secondary IP addresses on each side. Then build 4 GRE tunnels
> and use a different IP addresses for each tunnel source/destination (that
is
> why you just created the secondary IPs), you can keep the tunnels
unnumbered
> and disable routing over the tunnels. Then assign a unique bridge group
to
> each tunnel.
>
> This is your best option if majority of you traffic is IP.
>
>
> Best regards,
> Alexei
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
> Danny Lane
> Sent: Wednesday, August 20, 2003 5:48 PM
> To: ccielab@groupstudy.com
> Subject: Transparent Bridging across Frame-relay
>
>
> This is a real world scenario that I am a bit unclear on. We are trying
> to implement a point to point solution utilizing two T1 (hoping to bond
> the circuits) to build four transparent bridges facilitating four
> different types of non-routable traffic. We are currently running the
> following configurations using Ethernet subinterfaces and serial
> subinterfaces, but I do not see that we are utilizing both circuits. I
> cannot use Multilink interfaces or Circuit-groups because of
> subinterfaces. My question is does
> Anyone have any experience with BCP with is now offer in IOS 12.3?
> Apparently this new protocol enables you to do multiple bridging across
> the two interfaces as I described.
>
> Thanks in advance you're your help..
>
> -danny
>
> Router 1
> interface FastEthernet0/0.1
> description VLAN (122.0.x.y) over Copper
> encapsulation dot1Q 1 native
> no ip mroute-cache
> bridge-group 101
> !
> interface FastEthernet0/0.2
> description VLAN (126.3.x.y) over Copper
> encapsulation dot1Q 2
> no ip mroute-cache
> bridge-group 102
> !
> interface FastEthernet0/0.3
> description IP Multicast VLAN (130.121.x.y) over Copper
> encapsulation dot1Q 3
> no ip mroute-cache
> bridge-group 103
> !
> interface FastEthernet0/0.4
> description VLAN (121.0.x.y) over Copper
> encapsulation dot1Q 4
> no ip mroute-cache
> bridge-group 104
> !
> interface Serial0/0
> description T1 number 1
> ip address 192.168.1.2 255.255.255.252
> encapsulation frame-relay
> no ip mroute-cache
> no keepalive
> dce-terminal-timing-enable
> frame-relay intf-type dce
> !
> interface Serial0/0.1 point-to-point
> no ip mroute-cache
> frame-relay interface-dlci 101 IETF
> bridge-group 101
> !
> interface Serial0/0.2 point-to-point
> no ip mroute-cache
> frame-relay interface-dlci 102 IETF
> bridge-group 102
> !
> interface Serial0/0.3 point-to-point
> no ip mroute-cache
> frame-relay interface-dlci 103 IETF
> bridge-group 103
> !
> interface Serial0/0.4 point-to-point
> no ip mroute-cache
> frame-relay interface-dlci 104 IETF
> bridge-group 104
> !
> interface Serial0/1
> description T1 number 2
> ip address 192.168.2.2 255.255.255.252
> encapsulation frame-relay
> no ip mroute-cache
> no keepalive
> dce-terminal-timing-enable
> frame-relay intf-type dce
> !
> interface Serial0/1.1 point-to-point
> no ip mroute-cache
> frame-relay interface-dlci 101 IETF
> bridge-group 101
> !
> interface Serial0/1.2 point-to-point
> no ip mroute-cache
> frame-relay interface-dlci 102 IETF
> bridge-group 102
> !
> interface Serial0/1.3 point-to-point
> no ip mroute-cache
> frame-relay interface-dlci 103 IETF
> bridge-group 103
> !
> interface Serial0/1.4 point-to-point
> no ip mroute-cache
> frame-relay interface-dlci 104
> bridge-group 104
> !
> interface BVI101
> ip address 122.0.0.50 255.255.255.0
> !
> interface BVI102
> ip address 126.0.1.2 255.0.0.0
> !
> interface BVI103
> ip address 130.0.1.2 192.0.0.0
> !
> interface BVI104
> ip address 121.0.1.2 255.0.0.0
> !
> ip http server
> ip classless
> !
> !
> !
> !
> bridge 101 protocol ieee
> bridge 101 route ip
> bridge 102 protocol ieee
> bridge 103 protocol ieee
> bridge 103 route ip
> bridge 104 protocol ieee
> bridge 104 route ip
> call rsvp-sync
>
> Router 2
>
> interface FastEthernet0/0
> no ip address
> no ip mroute-cache
> speed 100
> full-duplex
> !
> interface FastEthernet0/0.1
> description VLAN (122.0.x.y) over Copper
> encapsulation dot1Q 1 native
> no ip mroute-cache
> bridge-group 101
> !
> interface FastEthernet0/0.2
> description VLAN (126.3.x.y) over Copper
> encapsulation dot1Q 2
> no ip mroute-cache
> bridge-group 102
> !
> interface FastEthernet0/0.3
> description IP Multicast VLAN (130.121.x.y) over Copper
> encapsulation dot1Q 3
> no ip mroute-cache
> bridge-group 103
> !
> interface FastEthernet0/0.4
> description VLAN (121.0.x.y) over Copper
> encapsulation dot1Q 4
> no ip mroute-cache
> bridge-group 104
> !
> interface Serial0/0
> description T1 number 1
> ip address 192.168.1.1 255.255.255.252
> encapsulation frame-relay
> no ip mroute-cache
> no keepalive
> fair-queue
> !
> interface Serial0/0.1 point-to-point
> no ip mroute-cache
> frame-relay interface-dlci 101 CISCO
> bridge-group 101
> !
> interface Serial0/0.2 point-to-point
> frame-relay interface-dlci 102 IETF
> bridge-group 102
> !
> interface Serial0/0.3 point-to-point
> frame-relay interface-dlci 103 IETF
> bridge-group 103
> !
> interface Serial0/0.4 point-to-point
> frame-relay interface-dlci 104 IETF
> bridge-group 104
> !
> interface Serial0/1
> description T1 number 2
> ip address 192.168.2.1 255.255.255.252
> encapsulation frame-relay
> no ip mroute-cache
> no keepalive
> fair-queue
> !
> interface Serial0/1.1 point-to-point
> no ip mroute-cache
> frame-relay interface-dlci 101 CISCO
> bridge-group 101
> !
> interface Serial0/1.2 point-to-point
> frame-relay interface-dlci 102 IETF
> bridge-group 102
> !
> interface Serial0/1.3 point-to-point
> frame-relay interface-dlci 103 IETF
> bridge-group 103
> !
> interface Serial0/1.4 point-to-point
> frame-relay interface-dlci 104 IETF
> bridge-group 104
> !
> interface BVI101
> ip address 122.0.0.1 255.255.255.0
> !
> interface BVI102
> ip address 126.0.1.1 255.0.0.0
> !
> interface BVI103
> ip address 130.0.1.1 192.0.0.0
> !
> interface BVI104
> ip address 121.0.1.1 255.0.0.0
> !
> ip http server
> no ip http secure-server
> ip classless
> !
> !
> !
> !
> bridge 101 protocol ieee
> bridge 101 route ip
> bridge 102 protocol ieee
> bridge 103 protocol ieee
> bridge 103 route ip
> bridge 104 protocol ieee
> bridge 104 route ip
> call rsvp-sync
>
> !
>
>
> _______________________________________________________________________
> You are subscribed to the GroupStudy.com CCIE R&S Discussion Group.
>
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
> _______________________________________________________________________
> You are subscribed to the GroupStudy.com CCIE R&S Discussion Group.
>
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html



This archive was generated by hypermail 2.1.4 : Tue Sep 02 2003 - 18:54:04 GMT-3