[c-nsp] Point to Point T1's and vlan nightmares

[Oliver Garraux]

Preventing duplicate VLAN numbers sounds like it could be better
solved through process changes rather than technical changes.  Maybe a
wiki or a spreadsheet, or a single person that's in charge of
assigning new VLAN's.

(Not trying to be argumentative, just thinking that VTP may not be the
best way to solve the issue you're concerned about).

-------------------------------------

Oliver Garraux
Check out my blog:  www.GetSimpliciti.com/blog
Follow me on Twitter:  twitter.com/olivergarraux


On Fri, Jul 27, 2012 at 5:27 PM, Blake Pfankuch <blake at pfankuch.me> wrote:
> We are utilizing eigrp internally.
>
> Using vtp v3 is for pruning primarily.  This will be a large multi site voice deployment as well, right now im sitting at 213 vlans across all sites, and trying to make it as easy as possible for their staff to manage and not accidentially create a new vlan in 2 different sites like vlan 450 and then start utilizing them then have to change it once everything is on the fiber mesh.  Once the fiber is in place, there will be a few extensions of single vlans from 1 site to another due to the way some very poorly designed network devices work but that's another rant.  So we will have trunks between sites.
>
> -----Original Message-----
> From: JP Senior [mailto:SeniorJ at bennettjones.com]
> Sent: Friday, July 27, 2012 3:21 PM
> To: Blake Pfankuch; cisco-nsp at puck.nether.net
> Subject: RE: Point to Point T1's and vlan nightmares
>
> It sounds like you should be focusing more on a layer 3 solution than a layer 2 solution - run an IGP between your 3560s or 3750s. Even if you did have proper fiber connectivity between locations, you should be isolating VTP (if _absolutely_ required) to single sites.  You should also reconsider running VTP in the first place, it's a terrible protocol which can destroy entire networks in a single packet.
>
> Do you have any specific reason to run layer 2 between sites in a private network?  It is extremely rare that this is ever a good idea and management of vlans using a single vtp source isn't one of them.
>
>
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Blake Pfankuch
> Sent: 27 July 2012 1:51 PM
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] Point to Point T1's and vlan nightmares
>
> OK, First off if this is a bad idea just say so and move on, I don't want to start a giant flame war :)  Also forgive me for this being a little long winded.
>
> Working with a customer of mine who is actually doing a very nice switching replacement.  All switches are Cisco 3750X or Cisco 3560X and will be supporting multiple vlans.  Currently they have about 8 locations which are point to point T1 connected, and about 6 more that are connected on a private fiber ring.  Eventually they will all be on a private fiber ring, and this will all be a moot point, but I'm looking for the "keep it pretty until its complete" solution right now.
>
> Because of the quantity of vlans being added, and the fact that it will be customer managed, I would like to force a single VTP domain across all locations, and have a single primary server running under vtp3.  This will prevent they user from adding conflicting vlans at different sites and having to pay me to come fix it for a week before they can turn up fiber.  My questions is as follows.
>
> Within Location A, I have a Cisco 3750X stack connected to a cisco 2921 router.  This router has 3 dual port T1 wic's.  Example Location B site has a Cisco 3750X stack connected to a Cisco 2901 router with a single T1 wic.
>
> On Location A switch I create the following
>
> Interface vlan 801
> Ip address 172.16.255.1 255.255.255.252
>
> Int gi 1/0/1
> Switchport trunk encapsulation dot1q
> Switchport mode trunk
> Switchport trunk allowed vlan 801
> Switchport trunk native vlan 801
>
> Then connect gi 1/0/1 to gi0/0 on the Location A2921 router and configure on the router as follows.
>
> Int gi 0/0
> No ip address
>
> Int gi 0/0.801
> No ip route cache
> Bridge-group 1
>
> Int ser 0/0/0
> No ip address
> Bridge-group 1
>
> Int bvi1
> No ip address
>
> Bridge 1 protocol ieee
>
> Then connect that Location A 2921 ser 0/0/0 to Location B 2901 ser 0/0/0 and apply this configuration to the 2901
>
> Int gi 0/0
> No ip address
>
> Int gi 0/0.801
> No ip route cache
> Bridge group 1
>
> Int ser 0/0/0
> No ip address
> Bridge-group 1
>
> Int bvi 1
> No ip address
>
> Bridge 1 protocol ieee
>
>
> From Gi 0/0 on this router connect to gi 1/0/1 on the cisco 3750X stack at location B with the following configuration.
>
> Interface vlan 801
> Ip address 172.16.255.2 255.255.255.252
>
> Int gi 1/0/1
> Switchport trunk encapsulation dot1q
> Switchport mode trunk
> Switchport trunk allowed vlan 801
> Switchport trunk native vlan 801
>
>
> This "should" in my mind leave the point to point t1 links working correctly for now, allow VTP to continue functioning and pass information across the bridged point to point t1 until these links are replaced with the final fiber links between sites (eta 6-10months), and prevent the user from mangling the nice pretty vlan configuration before it's a single mesh network.  Also allowing me to create multiple bridge to vlan subinterface networks to handle the multiple physical point to point circuits flowing on this single router.
>
> Thoughts?
>
> Thanks in advance!
>
> Blake
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> The contents of this message may contain confidential and/or privileged subject matter. If this message has been received in error, please contact the sender and delete all copies. Like other forms of communication, e-mail communications may be vulnerable to interception by unauthorized parties. If you do not wish us to communicate with you by e-mail, please notify us at your earliest convenience. In the absence of such notification, your consent is assumed. Should you choose to allow us to communicate by e-mail, we will not take any additional security measures (such as encryption) unless specifically requested.
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/