explanation about bridge group

[Fernando_Meza]

Hi Netpros,

I have some problems understanding the use of the bridge-group command. I have seen it on access points to bridge the radio interfaces with the ethernet interfaces .. I have also seen this on VoIP configs such as the one attached .. but to be honest I am not exactly sure what does it do .. any comments are much appreciated

bridge irb

!

!

!

interface Loopback10

ip address 12.1.1.1 255.255.255.255

!

interface Loopback20

ip address 12.8.0.1 255.255.255.255

!

interface Loopback30

ip address 12.10.1.1 255.255.255.255

!

interface Loopback110

ip address 12.10.2.1 255.255.255.255

!

interface Loopback120

ip address 12.10.3.1 255.255.255.255

!

interface Loopback130

ip address 12.10.4.1 255.255.255.255

!

interface Loopback140

ip address 12.10.5.1 255.255.255.255

!

interface Tunnel10

no ip address

tunnel source 12.1.1.1

tunnel destination 12.1.10.1

bridge-group 10

bridge-group 10 spanning-disabled

!

interface Tunnel20

no ip address

tunnel source 12.8.0.1

tunnel destination 12.8.10.1

bridge-group 20

bridge-group 20 spanning-disabled

!

interface Tunnel30

no ip address

tunnel source 12.10.1.1

tunnel destination 12.10.11.1

bridge-group 30

bridge-group 30 spanning-disabled

!

interface Tunnel110

no ip address

tunnel source 12.10.2.1

tunnel destination 12.10.12.1

bridge-group 110

bridge-group 110 spanning-disabled

!

interface Tunnel120

no ip address

tunnel source 12.10.3.1

tunnel destination 12.10.13.1

bridge-group 120

bridge-group 120 spanning-disabled

!

interface Tunnel130

no ip address

tunnel source 12.10.4.1

tunnel destination 12.10.14.1

bridge-group 130

bridge-group 130 spanning-disabled

!

interface Tunnel140

no ip address

tunnel source 12.10.5.1

tunnel destination 12.10.15.1

bridge-group 140

bridge-group 140 spanning-disabled

!

interface Ethernet0/0

description *********** INTERNET CONNECTION ******************

ip address dhcp

half-duplex

no cdp enable

crypto ipsec client ezvpn ezvpnclient

!

interface Ethernet1/0

description ***********

no ip address

half-duplex

!

interface Ethernet1/0.1

description HOME-VLAN

encapsulation dot1Q 1 native

!

interface Ethernet1/0.10

description HQ-Data

encapsulation dot1Q 10

no cdp enable

bridge-group 10

bridge-group 10 spanning-disabled

!

interface Ethernet1/0.20

description BR1-Data

encapsulation dot1Q 20

no cdp enable

bridge-group 20

bridge-group 20 spanning-disabled

!

interface Ethernet1/0.30

description BR2-Data

encapsulation dot1Q 30

no cdp enable

bridge-group 30

bridge-group 30 spanning-disabled

!

interface Ethernet1/0.110

description HQ_Voice

encapsulation dot1Q 110

no cdp enable

bridge-group 110

bridge-group 110 spanning-disabled

!

interface Ethernet1/0.120

description BR1-Voice

encapsulation dot1Q 120

no cdp enable

bridge-group 120

bridge-group 120 spanning-disabled

!

interface Ethernet1/0.130

description BR2-Voice

encapsulation dot1Q 130

no cdp enable

bridge-group 130

bridge-group 130 spanning-disabled

!

interface Ethernet1/0.140

description PSTN

encapsulation dot1Q 140

no cdp enable

bridge-group 140

bridge-group 140 spanning-disabled

!

[Craig Balfour]

The bridge-group command is used to configure a Cisco device to bridge traffic between two interfaces. In your configuration above traffic is being bridged between physical ethernet interfaces and tunnel interfaces.

So if, for example, you wanted to join two LANs - connected via a routers and a serial link between them - together. you would configure the LAN and WAN interface on each router to be part of the same bridge-group.

This will create a bridge between the two LANs and ethernet packets from one LAN will be visible on the other.

LAN 1---->[Router 1]---->[Router 2]-->LAN 2

On Router1:

int fa0

bridge-group 1

int s0

bridge-group 1

bridge 1 protocol ieee

On Router 2:

int s0

bridge-group 1

int fa0

bridge-group 1

bridge 1 protocol ieee

For more information on transparent bridging see http://www.cisco.com/en/US/tech/tk331/tk660/technologies_tech_note09186a0080094471.shtml.

[Richard Burts]

Fernando

Craig has given a good explanation of bridge-group and its essential role in configuring transparent bridging. I would just add one comment which is that unless things have changed recently bridging over GRE tunnels (which is what the config you posted is doing) is not an officially supported implementation. It may work but Cisco does not guarantee it and if something about it does not work then they are under no obligation to fix it.

HTH

Rick

[Fernando_Meza]

Thank you .. Appreciate your explanation .. I will read the link and get back with any comments ..

cheers,

[Fernando_Meza]

Ok .. I have read the document .. so taking the same example that you mentioned. Does it mean that by making both interfaces on each router part of the bridge-group .. then both LANs become one broadcast domain ...? .. would you mind adding IP addresses to each interfaces on each router .. if applicable ... that will really help me to understand this issue

Cheers,

[Richard Burts]

Fernando

Yes if you put bridge-group on both interfaces then they become part of a single broadcast domain.

It might make sense to put an IP address on one of the interfaces. If you wanted to put an address on the other interface, you could do it but I do not believe that it would accomplish much - both addresses would be in the same subnet and either one would give you the same access to the box.

HTH

Rick

[mohammedmahmoud]

Hi Rick,

I hope that you are fine, i just have a couple of questions here, as a concept, how can 2 bridged interfaces each have IPs, should't they be bridging traffic rather than routing traffic, and a second question what are all the interfaces supporting the bridge feature.

Thanks for all your valuable input.

BR,

Mohammed Mahmoud.

[Richard Burts]

Mohammed

2 bridged interfaces can each have an IP address. It is still bridging not routing. Perhaps an example can help clarify:

bridge 5 protocol ieee

interface fastethernet0/0

ip address 10.1.1.5 255.255.255.0

bridge-group 5

interface fastethernet0/1

ip address 10.1.1.6 255.255.255.0

bridge-group 5

So in this situation both interfaces are bridging, there is one broadcast domain which includes both interfaces, and you could telnet (or ping or whatever) to 10.1.1.5 or to 10.1.1.6.

We most often associate bridging with the various Ethernet interfaces (Ethernet, FastEthernet, etc), but bridging is supported on other kinds of interfaces as well. When we were using Token Ring interfaces you could do transparent bridging or source route bridging (also on FDDI interfaces). I have done transparent bridging over point to point interfaces (HDLC and PPP, and Frame Relay). The main type of interface that I am aware of on which transparent bridging is not officially supported is the GRE tunnel (as I commented in an earlier post). You can get data to flow over GRE tunnels configured with bridging, but it is not officially supported.

HTH

Rick

[mohammedmahmoud]

Hi Rick,

Thanks for your awesome explaination, but i have problems understanding how can traffic be bridged between for example an Ethernet and a PPP interface, if you can please elaborate further.

BR,

Mohammed Mahmoud.

[Richard Burts]

Mohammed

Transparent bridging is generally a LAN technology but it can be transported over point to point links. This is done by encapsulating the bridged LAN frame in a header for PPP, HDLC, etc. Perhaps a small example may help.

bridge 6 protocol ieee

interface fastethernet0/0

ip address 10.1.1.5 255.255.255.0

bridge-group 6

interface fastethernet0/1

no ip address

bridge-group 6

interface serial1/0

encapsulation ppp

bridge-group 6

Lets start with the easy part. A frame arrives on fastethernet0/0, the bridging logic looks at the frame, determines that the destination MAC address is associated with interface fastethernet0/1, and forwards the frame out that interface. Now the more complicated part. A frame arrives on fastethernet0/0, the bridging logic looks at the frame, determines that the destination MAC address is associated with interface serial1/0, the router/bridge takes the LAN frame and encapsulates it in a PPP header and forwards it out the serial interface. On the other end of the serial connection the router/bridge receives the frame, strips the PPP header, and its bridging logic examines the LAN frame to make the correct forwarding decision.

HTH

Rick

[mohammedmahmoud]

Hi Rick,

Sorry for asking so much, i really do appreciate your valuable explaination, but i have trouble with this part "determines that the destination MAC address is associated with interface serial1/0" how is a MAC address associated with a serial interface.

BR,

Mohammed Mahmoud.

[Richard Burts]

Mohammed

It is a reasonable question and I am glad to help you understand how this works. Lets start with a couple of fundamental concepts of how the "router as a bridge" works and contrast the workings of routing and bridging. We are already familiar with several tables that the router maintains to do its work (the ARP table that it maintains to be able to communicate with LAN devices, and the routing table that it builds to be able to make layer 3 forwarding decisions). When we enable bridging on the router then the router builds another table which is the bridging table. It populates the table by observing traffic that is being bridged. Every frame that is received by the bridging logic is examined and its source MAC address is put into the bridging table along with the interface on which it was received. Then bridging forwarding decisions are made by looking into the bridging table, finding the destination MAC address, and forwarding out the indicated interface.

Having explained that lets look at how that works when bridging over serial interfaces is involved. Using the example in my previous post lets assume that bridging is configured on both fastethernets and on serial1/0. Then lets assume that a frame is received on the serial interface. The router/bridge strips the PPP header and looks into the LAN frame, it finds the source MAC and puts that source MAC into the bridging table and associated that MAC with interface serial1/0 (the interface on which it was received). That is how MAC addresses get associated with serial interfaces.

I agree that the concept of MAC address and serial interface seems a bit strange at first. And we are not saying that there is a MAC address ON the serial interface. We are saying that the MAC is associated with the serial interface. We have learned that we get to that MAC address by going through this interfface. It may help to think of the similarity between the routing logic which looks into a routing table to find the correct outbound interface and the bridging logic which looks into the bridging table to find the correct outbound interface.

HTH

Rick

[mohammedmahmoud]

Rick,

Thank you very very much for the wonderful explaination, i wouldn't have understood it throughly without your help, i really do appreciate interacting with a superior expert as your self.

To make sure that i've got it throughly, for you example to be completed, there must be a router on the other end of the serial interface that also have its serial bridged with its Ethernet to have a frame with a MAC address received on the local router serial interface and then the process goes as you've explained perfectly, have i got it right.

BR,

Mohammed Mahmoud.

[Richard Burts]

Mohammed

Yes indeed you have got it right. There must be a router on the other end of the PPP connection which is bridging its serial and its Ethernet(s). This is the only way that it can work.

And having made the point that it does work, I will also make the point that most of the time we think it is poor design to try to bridge Ethernet of serial interfaces. Forwarding LAN frames at serial link speeds frequently creates a bottleneck and performance of the Ethernet is impacted. Also forwarding the amount of broadcast traffic frequently found in Ethernet networks over the serial interface will frequently congest the serial link.

HTH

Rick

[mohammedmahmoud]

Hi Rick,

Thank you, no words to say :) superior expert indeed.

BR,

Mohammed Mahmoud.