IRB – Integrated Routing and Bridging.


My understanding of IRB:

I did another Volume 1 lab yesterday. Again i hit my head against the infamous IRB feature.

IRB stands for Integrated Routing and Bridging. Below is my understanding of the technology. I could be very wrong about this, so please correct me if i state something completely incorrect.

Bridging is switching. Our standard routers dont normally do any bridging, but they can.

Basically you can bridge between two interfaces, which on a router, is routed interfaces.

As on the switch, we can either bridge or we can route, or can we do both?

Well, as it turns out we can do both. By using IRB we can both switch as well as route.

But lets take it all apart and see whats going on.

Topology is simply:

R1 <-> R2 <-> R3

First of, lets try and create a bridge group, which is what we will put on our two interfaces (to keep it simple):

"bridge-group 1 protocol ieee"

What this command does, is telling IOS that for bridge-group 1, we want to use traditional ieee (STP) and hence “extend” the STP across

our two bridged interfaces.

Now apply that two our interfaces on R2:

int f0/0
 bridge-group 1
int f0/1
 bridge-group 1

Only R1 and R3 has IP addresses assigned, and through the router (R2) they now appear to be on the same ethernet segment.

If, on R2, you view the status of the bridging group, you’ll see that spanning-tree has converged:

R2(config-if)#do sh bridge group
Bridge Group 1 is running the IEEE compatible Spanning Tree protocol
 Port 4 (FastEthernet0/0) of bridge group 1 is forwarding
 Port 5 (FastEthernet0/1) of bridge group 1 is forwarding

Even though our Layer 2 now seems operational, a ping from R1 to R3 still does not work:

R1#ping 192.168.100.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.100.3, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

So whats going on here? Well, basically, on R2 we havent told the router it should be a bridge for forwarding frames. By default it still thinks its a normal router,

even though we have assigned a bridge group to the interfaces.

Now, two ways to overcome this. Lets try out number one first. Namely, disable all IP routing on R2:

R2(config)#no ip routing
and now on R1 to R3:
R1#ping 192.168.100.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.100.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/42/92 ms

Its VERY important that you clear your ARP cache when doing these tests, as alot of the results will only be valid with an empty ARP cache.

So lets shut/no shut the F0/0 interface of R1 before proceeding:

R1(config)#int f0/0
R1(config-if)#sh
*Mar  1 00:21:26.319: %LINK-5-CHANGED: Interface FastEthernet0/0, changed state to administratively down
*Mar  1 00:21:27.319: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to down
R1(config-if)#no sh
R1(config-if)#
*Mar  1 00:21:30.827: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state to up
*Mar  1 00:21:31.827: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to up

Verify:

R1(config-if)#do sh arp
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  192.168.100.1           -   c200.0518.0000  ARPA   FastEthernet0/0

Lets enable IP routing on R2 again:

R2(config)# ip routing

And test from R1 again:

R1#ping 192.168.100.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.100.3, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

No dice.

Second way. Lets tell our R2 router that its allowed to use IRB. The “bridge irb” command by itself, simply states that both routing and switching/bridging can occur on this router.

R2(config)#bridge irb
Now lets try again from R1:
R1#ping 192.168.100.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.100.3, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 8/86/228 ms

Great. It works. At this point shut/no shut the R1 F0/0 interface again.

To use both routing and switching/bridging on the bridge 1, we need to tell R2 to use IRB for our defined bridge group. When we finish configuring this

function, we are able to both switch/bridge IP packets as well as perform routing on the bridge, using our BVI interface.

This can be confusing, but lets break it down to enable the functionality without defining our BVI interface:

R2(config)#bridge 1 route ip

And test on R1:

R1#ping 192.168.100.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.100.3, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

Hmm. whats this? Well, in order to still switch/bridge, we need to have our BVI interface defined and in an up/up state, even though we dont use it for routing:

R2(config)#int bvi1
R2(config-if)#
*Mar  1 00:27:52.207: %LINK-3-UPDOWN: Interface BVI1, changed state to up
*Mar  1 00:27:53.207: %LINEPROTO-5-UPDOWN: Line protocol on Interface BVI1, changed state to up

And test:

R1#ping 192.168.100.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.100.3, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 16/46/104 ms

Awesome.

The last thing is to put an IP address on the BVI1 interface so we can use it for routing:

R2(config-if)#int bvi1
R2(config-if)#ip add 192.168.100.2 255.255.255.0

And test:

R1#ping 192.168.100.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.100.2, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 1/71/136 ms

Good stuff.

Now lets verify it all. First verify our spanning-tree:

R2(config-if)#do sh bridge 1 group
Bridge Group 1 is running the IEEE compatible Spanning Tree protocol
 Port 4 (FastEthernet0/0) of bridge group 1 is forwarding
 Port 5 (FastEthernet0/1) of bridge group 1 is forwarding

We have spanning-tree working alright.

Lets verify our configuration on R2:

R2(config-if)#do sh run | incl bridge
bridge irb
 bridge-group 1
 bridge-group 1
bridge 1 protocol ieee
bridge 1 route ip

We have told R2 to use both routing and switching/bridging. We have applied bridge group 1 to both F0/0 and F0/1 interfaces.

We use the standard spanning-tree protocol (ieee) and finally on bridge group 1, we want to both route and bridge IP packets.

So to recap.

IRB is just a functionality that allows your router to be both a router AND a bridge/switch at the same time. Without it, you could only tell your

router to be either a switch or a router – probably not what you want, or you could tell it, by just using “bridge irb” to do both. By using “bridge route ip” you

have the ability to use a BVI interface to route the information as well!

One important fact you need to keep in mind is this: when you have an interface that is bridging, you will NOT be able to access this interface by its IP address.

Remember, you are switching/bridging on this interface, not routing. This is the exact same behavior as you have on your switch. Its either or.

Use your BVI interface for this purpose!

I hope you can use this in your studies!