P2P fibre trunk link over 1 km

[ashish.patwekar1]

We have bought a new floor in a new building which is approx 1 km from our current office where the core switch resides.I am planning to use a 100mbps Point to point fibre link to connect the L2 switch at new floor which has capacity of around 200 users to the core switch at old office.I will then pass all the vlans over the trunk link.Are there any issues in this setup?

[balaji.bandi]

We are not sure how you are extending the Fibre through provider or own Fibre link

Either canse, as long as you have right interfaces used and i do not see any issue here extending the link.

Make sure spanning tree configuration on the new switch.(it should not elect as root bright).

[ashish.patwekar1]

ISP is providing 100mb point to point...we will be connecting the cable to gig ports on both ends...the core switch at old building is the root bridge with prior lowest....can be there be any latency issues due to distance?

[balaji.bandi]

there will be small ignorable always add when the distance increases.

[Patrick.Williams]

Once you are not consuming the total throughput of your link latencies will remain fairly constant an average of 1ms or sub ms will be achievable.

And as usual there is always the word IF the link is being over utilized then latencies will become an issue and at that point your QOS will not have much of a control.

***Remember to rate all helpful posts***

[Joseph W. Doherty]

". . . IF the link is being over utilized then latencies will become an issue and at that point your QOS will not have much of a control."

BTW, actually it's when a link is congested that you often benefit most from a QoS implementation. It's certainly true, QoS will not eliminate all traffic's latency, but it often can eliminate much of the latency for some traffic. For the traffic which is not prioritized, i.e. to minimize its latency, QoS sometimes can make other traffic's latency less variable and/or keep if from increasing further.

[Patrick.Williams]

Once the ISP is delivering a true Ethernet based link you will be able to establish a trunk to trunk link on both ends.

Ensure that all  VLANs that are not used at your remote location are pruned so as to prevent  unnecessary broadcast form traversing across the L2 link hence saving bandwidth which is always a good thing.

You will also have a root bridge election going on between your main office SW and the remote SW and in no case your remote SW should end up being the root switch, as this may cause some serious headaches on your part, to prevent  this ensure that your root priority is set to the max by issuing    spanning-tree vlan X priority 61440 on your remote SW

****Remember To Rate Posts That Are Help full***

Cheers

[Joseph W. Doherty]

For 200 users, now a-days, 100 Mbps might be a bit on the light side, but impact of that depends on just how those users consume bandwidth.

As other posters have noted, if you're going to trunk across the link, you'll probably want to limit VLANs on the link to only those used. However, to extend making best use of your bandwidth, might be to consider having the link be L3.

Also depending on what your users are doing, you might consider a QoS configuration on both ends. Again, now a-days, if often doesn't take much to congest a 100 Mbps port, and if one user does it, the other 199 will suffer, which may be a real problem if your doing/planing for VoIP.

Regarding your question on latency, as also noted by other posters, yes distance adds latency; for 1 KM (two way) it should be less than 10 microseconds.

[ashish.patwekar1]

Hi Joseph,

Thanks for the reply...there is no voip traffic on the link...it will be a plain data link....the reason we didnt configure it as a L3 is bcos the setup is little complicated so we decided on just extending the lan...i agree 100mb might be little less and we plan to upgrade to 200 after monitoring the usage for around a week.

[balaji.bandi]

if you have valid reason L2 then you welcome to go and deploy ( consider security Point of view). if you able to run some security mechanish which you prefer is acceptable way. - again depends on the end to end device supported features.