Removed Bridged subnet and replace with routed

Unanswered Question
Apr 23rd, 2008

We have a critical server that originally could not be routed to the DR server in our DR site. It had to be on the same subnet, so it was bridged to the DR site.

The server is using the BVI interface as it's default gateway.

We now need to remove this bridged subnet and put it on a routed subnet.

I am trying to come up with a plan to do this, while also understand how the bridge worked, as we still have the need to keep the two other existing bridged subnets.

As it stands now, there are three bridged subnets to DR.

I am thinking I could:

1. Create a subnet in DR for the DR server and make sure it is routing to HQ.

2.Configure HSRP on VLAN5 on our 6509 switches. It is not configured on this VLAN for some reason, don't know why.

3. Point the server to the VIP of HSRP pair for VLAN5.

Is this feasable while leaving the bridge configured to fall back on if there are problems?

Is there anything with the subinterfaces I need to take into account while I am doing this?

This is a DS3 point-to-point, but the configs are showing as Frame-Relay, is this a mock up of Frame-Relay, by using the "Frame-Relay Switching" command?

Why would the server use the BVI interface as it's default gateway and not the VLAN interface for that subnet?

Thanks for any information anyone can provide.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (3 ratings)
Richard Burts Sat, 04/26/2008 - 12:38


This is a sophisticated and complex setup. I have gone through what you have posted and believe that I understand some but not all of what is going on here. Much of it makes good sense and a few things are puzzling. I will address several aspects of it here and suspect that there will need to be several iterations of follow up.

As I commented in another thread that you started, a point to point circuit is not mutually exclusive with Frame Relay. I believe that this is a clever way to take a single point to point circuit and logically subdivide it to carry several different types of traffic which need to be separated from each other (1 routed link, and 3 bridged links). This is effectively done by making it Frame Relay with 4 PVCs (and 4 DLCIs).

You ask if it is a mock up of Frame Relay using frame relay switching. I am not sure that it is. If it were I would expect DLCIs to match on both ends. While the DLCIs do match for the routed link and for bridge group 1 they do not match for bridge groups 2 and 3. Perhaps you could check with Verizon and they could provide some details and whether they provision this link with Frame Relay switching.

As far as the plan that you suggest:

1) you can create a new subnet on DR and make sure that it is routing to HQ. This would also involve reconfiguring the server at DR, giving it an address in the new subnet, and giving it a default gateway.

2) it is not clear to me whether the 6509 switches are at DR. I assume that they are but would like to know for sure. In fact your drawing is not clear about the topology at either DR or HQ. You show the server that seems to be connected to a switch and the switch connected to the router. But the link from the switch to the router appears in the config to be a routed link and not a trunk. You show a dotted link for VLAN 5 between server and router and the config shows the connection to the router to be interface FastEthernet2/0. I am not clear how that relates to your possibly configuring HSRP.

During the transition you could leave the BVI and the subinterface for bridge-group 1 in place to have a fall back. Once you are comfortable that the routed connection between servers is working there is no need for the BVI and for the subinterface on Frame Relay for bridge group 1.

The reason that the server uses the BVI as its default gateway instead of the VLAN interface is that the BVI is the way to get from the bridged environment to the routed environment.



wilson_1234_2 Sat, 04/26/2008 - 15:20

Thanks for the reply.

The 6509 switches are actually in HQ and I mentioned configuring HSRP on that VLAN only because it is not configured on it and it is on all other VLAN. Ididn't post the switch config, so you would not have known that.

The servers are configured the same on both ends (which is why I brought up the question about their default gateway) which is, they are on ports in VLAN 5 on each switch. Vlan 5 on the switch has an IP Address on the SVI, but the servers are not configured with that default gateway. They were given the DG of the BVI interface on the router, which also has it's interface in VLAN 5. Since the router BVI interface and the switch VLAN 5 SVI interface are on the same subnet, I guess the server were given the BVI interface as the DG to eliminate one step.

Maybe I should not have shown the ethernet interface (routed) connection to the switch because it is not relevant here.

I am trying to find out from Verizon about how the circuit is set up but have not heard anything yet.

Please tell me your thoughts on the below Rick:

If it is actually Frame Relay, then I would have to either

1. Add the new VLAN in DR, remove the Bridge Group interface and add IP Addresses to the subinterface to maske that particular PVC a routed connection.

2. Add the new VLAN in DR and let the existing routed connection route HQ VLAN 5 to the new DR VLAN (105?), but have to get with Verizon and have them increase the CIR for that particular PVC.

If I go with #1, I will have to figure out a way to have HQ route VLAN 5 over the newly IP Addresseses subinterface and maintain dynamic routing.

This also brings up the question about the frame-relay switching, is it possible to use that and segment the traffic with frame relay PVCs without a provisioned frame-relay circuit?

Does any of the above make sense?

Richard Burts Sun, 04/27/2008 - 16:56


Yes it does make some sense. It is complex and there are parts of it that we do not yet understand. But some of it is making sense.

I do not have much enthusiasm for suggestion 1). I do not see any benefit from trying to create 2 routed PVCs and as you comment there would be some issues to resolve about how to get VLAN 5 to route over that PVC. I think suggestion 2) is much better. Let the existing routed PVC carry the routed traffic and perhaps you need to adjust the CIR.

The issue of the default gateway for the servers is somewhat complex. We tend to think of the IP address of the SVI/VLAN interface as the default gateway because usually the SVI does function as the gateway between the VLAN and layer 3. But configuring IRB changes that somewhat. With IRB configured the BVI really becomes the gateway between the layer 2 domain and the layer 3 domain. Therefore the BVI is the logical choice for the default gateway of the server.

I would prefer to get a response from Verizon before we have much discussion about the aspect of frame relay switching.



wilson_1234_2 Mon, 04/28/2008 - 05:20

Thanks Rick,

I see what you are saying about the BVI interface.

Thanks for the great replys.

wilson_1234_2 Mon, 05/05/2008 - 16:04


I have an answer from Verizon that this is a point-to-point circuit with no Frame Relay provisioned.

Which means that the "frame-relay switching" command in the router is allowing the configuration of PVCs on the circuit from end to end.

I did not know you could do that.

Also, If there is no bandwidth or CIR configured, does this mean that the traffic is isolated per PVC, but any one of the PVCs could utilize the entire 45 Mbps if need?

And, if I were to remove the one bridged connection and add IP Addressing to the PVC, what about PBR to route traffic destined for a certain subnet in DR?

Richard Burts Mon, 05/05/2008 - 18:48


That is a very interesting response from Verizon. And it does confirm that the configuration of frame-relay switching is essential in making several PVCs work which allows separation of traffic over the link. As I commented before: "this is a clever way to take a single point to point circuit and logically subdivide it to carry several different types of traffic which need to be separated from each other". It is a very creative solution.

Without the ability to enforce CIR I believe that it does enable isolation of traffic per PVC and that any one of the PVCs could utilize the entire bandwidth.

I believe that it is feasible to remove the bridging from one of the PVCs and to replace it with IP addressing to make that PVC a routed link. And I believe that it would be feasible to configure PBR to send traffic for a certain subnet over that link. But I wonder if you really want to do it. Usually the reason for configuring PBR is that you want the traffic to take a physically different path or you want the traffic to take a path where it has certain access to bandwidth. But neither of these seem to apply to this situation. PBR would not seem to give any better access to bandwidth than putting all traffic on the same routed link. Is there some aspect of routing for a certain subnet in DR that I am not thinking about?



wilson_1234_2 Tue, 05/06/2008 - 08:23

I was thinking along the lines of keeping the traffic seperate as it is now, and not being concerned about the bandwidth utilization of the differnet PVCs.

Just as they are not concerned now.

The traffic was seperated because one bridged connection is for DR voice servers and another was for traffic that must be isolated from all other for security reasons, the other was just for a few workstations (not sure what that one was kept seperate).

The routed connection was for all other DR replication traffic.

The bridged connection that I will be removing is the traffic that must be kept secure and isolated, so I was thinking of using the existing PVC, give it IP Addresses end to end.

Then I could use the PBR to ensure that all traffic destined for the new VLAN in DR (that I will create), will go via the new IP Address link I will create on the PVC.

I could also create the new PVC and test it before adding the policy to route the traffic.

Richard Burts Tue, 05/06/2008 - 08:55


If there is a requirement to keep that traffic separated, then using the PVC, assigning an IP address, and using PBR to route the traffic over it makes a lot of sense.

It certainly is a good idea to test things before doing them in production. But converting the PVC from bridged to routed and implementing PBR should be relatively straight forward.



wilson_1234_2 Tue, 05/06/2008 - 09:12

I was going to lab it this weekend to test.

I appreciate your input on this.

It never ceases to amaze me the creativity some people have.

I could have never have dreamed anything like this up.


This Discussion