cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
853
Views
0
Helpful
6
Replies

Fiber loop routing question

william.culver
Level 1
Level 1

I have a dark fiber loop. I have a 6506 at the core and 3750 layer 3 switches at remote sites. I would like to close the loop so that if I have a fiber break, traffic can route back around to the core. If I have two GBICs - one going in each direction, what considerations do I need to take into account. Essentially it would be a widely dispersed stack. How can I force the traffic to default to the shortest path if available. I am currently using RIP.

Any assistance is greatly appreciated.

6 Replies 6

Collin Clark
VIP Alumni
VIP Alumni

Just so I understand your topology better, are the 3750's stacks the default gateways of your VLAN's? Is it a layer 2 or layer 3 connection between your core and the stacks?

Yes. VLANs gateways are on the 3750s. Layer 3 to core. Clarify - default route from 3750 takes you back to the 6506.

Thanks.

Giuseppe is right on. I too would look at moving away from RIP. If you use EIGRP/OSPF you can load-balance across the links to the core effectively using both links. If one fails, the IGP will pull it from the routing table and all traffic will go over the working link.

Giuseppe Larosa
Hall of Fame
Hall of Fame

Hello William,

>> If I have two GBICs - one going in each direction, what considerations do I need to take into account.

GBICs are bi-directional they have a TX and RX circuitry and host two fibers.

What you can do by inserting two GBICs at each device:

have pathA : C6500 - C3750_A bidirectional using one IP subnet /30

have pathB : C6500 - C3750_B bidirectional using a second IP subnet /30

have pathC: C3750_A to C3750_B bidirectional using a third IP subnet /30.

I hope you use at least RIPv2 but I would suggest you to move to OSPF or EIGRP for faster convergence.

In normal conditions traffic from each remote site to the central site should use the direct link, traffic between the two remote sites would use the pathC if no other measures are used.

To have traffic between sites to go via central site (this can be required for security / accounting reasons) some changes have to be done:

with OSPF:

ip ospf cost 500 out pathC on both C3750 interfaces

with RIP:

use of an offset-list of 4 (this rises the RIP hop count metric in a controlled manner inbound pathC) so that going via the hub site is preferred even for remote to remote traffic.

In case of fault pathC should be used for all traffic.

Hope to help

Giuseppe

Thanks all for your great input. I will actually have 5 3750's in a ring back to the 6506. Gig connections around the ring. Also am beginning to run VOIP (not Cisco)and could split that off on its own fiber pair if it makes sense. Total fiber ring is maybe 15 miles. I plan to have redundant 45Mb internet connectivity at separate sites. Any other thoughts would be appreciated.

Hello William,

with a correct implementation of QoS you shouldn't need a dedicated fiber link for VoIP traffic.

The devices are 5 in the ring in addition to the C6500: you can follow the schema proposed in the previous post and skip only the features for having traffic through central site that doesn't apply anymore.

In this case, there are more reasons to move to a different routing protocol like OSPF or EIGRP or your convergence time can be in the order of 30seconds * 4 = 120 seconds in addition the the RIP holdtime.

The change is also needed to support VoIP traffic: you can try to use EIGRP it should be enough to rewrite the RIP configuration using

eigrp 100

you need to use the same AS number 100 in all of your routers.

>> Total fiber ring is maybe 15 miles

single mode fiber necessary

the redundant internet access can be configured to inject a less preferred default route to be used only if the primary fails

Hope to help

Giuseppe

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco