Recommendation on tunneling protocol

[richberry]

I need a recomendation on the simplest tunneling protocol to set-up to extend a L2 VLAN to a remote site.

Basically, I need to extend a VLAN across several layer3 hops and through a MPLS WAN connection. I been reviewing GRE, VRF, EoMPLS, L2TP, and any others that have come across my path.

We are trying to overcome an issue where our VoIP phones (at the remote location) drop thier connection while roaming.  The wireless network has been converted to run LDAP.  The vendor of our DAS*, and wireless network have recommended installing a new wireless controller at the remote site.  However, the SSID/VLAN that carries the public Internet traffic is located at the main facility.  At this stage the traffic exits the controller into the VLAN that is trunked to the Internet (separated from production traffic).   I need to trunk this VLAN from the Services core out to the remote site.

As it's a L2 VLAN I dont believe it needs any unique routing tables.... but most of the  VRF explanations cover dealing with opverlapping IPs (and hence the need for VRF).  I dont have confirmation from AT&T on their recomendations, or supported protocols, and/or if they support jumbo frames (so I dont have fragmentation problems with MTU incompatibility).

Attached is a simplified diag (couldn't post to body).   Happy to answer any questions, or provide additional details. Thanks in advance for your consideration and recommendations.

[richberry]

* DAS = Distributed Antenna System.  (Antenna Vendor manages levels and QOS for our wireless VoIP).

[paolo bevilacqua]

If you want solid, reliable and performant results achieved using best practices, do  not insist on bridging or "extending VLANS". Use routing instead.

Then the tranport method becomes largely irrelevant.

[richberry]

This is a really weak answer.  Better yet. dont pass any data.  that makes it really secure too!

[burleyman]

Wow...Way to slam someone who is trying to help and you do it to one of the most repected people on this forum....Not really a good way to get people to help.

Mike

[richberry]

Yeah. You're right.

However, I dont think answering a question with a unfeasble solution tailored to your preference was worth the reply. I put a lot of effort into researching tunnel solutions (GRE, VRF, EoMPLS, L2TP3, OTV, AToM, etc), describing the need and, providing documentation prior to posting. After 11 minutes of thought "Route it" was the answer?

Perhaps better thoughout answers on both are parts is in order.

[burleyman]

Ok...still slamming...very good. If you read the reply it is a very good reply. It states that trying to do what you are asking is NOT a best practice and it is much more stable and reliable to route not to extend vlan's. So if you do not want to follow best practices and are not that concerned with having a stable and reliable network then I guess thinking that answer is not a good one is up to you.

Mike

[burleyman]

Oh and almost forgot..... 5+ for you Paolo for a post that helps and points out some best practices to follow. I know this will help some others.

Mike

[Peter Paluch]

Gentlemen,

I guess tempers are slightly hightened in this thread - please, cool off everybody. The matter is by far not that serious.

As I see it, Rich has a network already in place and he needs to meet a specific requirement within constraints of this network. We may argue if the way of accomplishing that requirement using particular means is sound, or a best practice, and it is our full right to question Rich's choice of tools to accomplish it. At the same time, Rich should understand that there are various people here answering his request, with their own mindset, their own approach to solving problems, even their own issues in speaking a non-native language. So instead of scoffing at short and seemingly off-hand answers, a better way to go is to reiterate his own views and explain why a particular suggestion, even a briefly given one, is not appropriate for him. This forum is based on discussion, remember?

Paolo's way of answering threads is commonly succint and brief even to the point that people who don't know him may perceive Paolo as making unhelpful remarks although in reality, Paolo is merely saying the truth in a very direct, almost blunt way, but with no bad intent. From my personal viewpoint, it would be helpful especially for newcomers if Paolo was more verbose - a few more words would suffice for the original poster to understand that Paolo simply gives his best suggestion even if the answer is not lengthy and eloquent. This is all meant in the best possible meaning, no offense intended whatsoever.

Mike, I find it very nice of you to have stood up for Paolo. At the same time, if you look over Rich's disenchantment with Paolo's answer, don't you think that Rich has an interesting problem to solve and that perhaps VLAN extension may be a workable solution?

Rich, is the routed solution excluded for you? If you need to go with VLAN extension, what services is AT&T capable of providing you?

Once again, all my remarks are well-meant; please do not understand them as any criticisms or badmouthing.

Best regards,

Peter

[burleyman]

Peter, thanks for the grounding. The post caught me at the wrong time and I may have been a little harsh defending Paolo.

Rich, I do appolgize for comming off as harsh. It just sometimes angers me, probally too much, when some of the most helpful people get slammed for offering help.

I do find this interesting and was hoping to learn off this post. I do not know the correct answer but look forward to more input so I can see what the outcome is.

Rich, again sorry. You have come to the right place for answers.

Mike

[richberry]

Mike, Peter, and Palo,

Thanks for your comments and criticisms.

The second reply was not meant to be a slam.  I was acknowledging my poor etiquette (trying to justify it was just aqnother mistake).

Thanks again.

[Florin Barhala]

Hello,

I believe L2TP v3 will come in hand for you. It is a simple&robust solution.

Also EoMPLS could help you, but you have to ask you MPLS_provider for this.

[richberry]

Thanks.  L2TP is the method I'm focused on implementing. 

I'm not sure if this is a software technology, or there are harware limitations (far end is c3750G).  Any "gotchas" or special requirements ( I've read about MTU size fragmentation etc)?

We are already routing several services across this link and need to keep the "guest" traffic isolated from the production traffic. My understanding is that this needs to be tunneled/trunked to the services core w/o any L3 hops (from user perspective).

[Giuseppe Larosa]

Hello Rich,

to avoid too slow roaming between different APs on the remote site, you have been told to install a WCS on the remote site ( and an LDAP server we might guess).

At this point if all APs in the remote site are managed by the new WLC, wireless user traffic to the internet cannot emerge at HQ WiSM as it happens now.

So you could fix the roaming issue at the price of wireless internet access at the remote site.

You are thinking of a p2p L2 transport service to allow remote site wireless users that access the internet to be bridged to Vlan 700 in  HQ central site.

As noted by Florin L2TPv3 could be a good solution but from your network diagram I see that you have only C3750 multilayer switches at remote site and they do not support L2TPv3.

So you would need to deploy an ISR router on remote site with appropriate feature set and to terminate the L2TPv3 tunnel on the C6500 with the WiSM on in another device may be a second ISR deployed at HQ to avoid too much complexity on the C6500..

There is however an alternative: if wireless VoIP phones don't need to access the internet (this is likely)  they could be served by a subset of APs managed by locally installed WCS+LDAP. Other APs managed by HQ WiSM can be used for the wireless internet access service at the remote site.

In this way all the tunneling is performed by the APs to the WiSM as it is currently set.

This may be feasible if you need to provide wireless internet access from a guest room (a limited space) so that you need only a few APs still managed by HQ WiSM.

Hope to help

Giuseppe