Hi,
I have three switches in this configuration using VTP and i have created a domain Network1. The two access switches are client within this domain.
Switch1 port fa0/23-24 connect to Fa0/21-22 on CSW1
Switch2 port fa0/23-24 connect to fa0/23-24 on CSW1
I have used PagP to aggregrate the links.
All lights are green Vlans are being passed though from server to client but for some reason. IPV4 does not seem to work. I have attached Packet tracer lab i created. :( :( :( :(
What am i doing wrong??
Cheers in advance.
IP does not need to work in a Layer2 domain,
by " IPV4 does not seem to work" what do you mean?
If you create an IP address on vlan 1, no shut, and connect a computer to port fa0/1 in vlan 1 and give it an IP on the same network, the PC cannot ping the SVI?
I installed Wireshark to test this because it wasn't entirely clear what you mean. Unfortunately you didn't post the password so I can't get into the switch sim. I can ping from one host to the other, by the way, so I'm not sure what's not working for you?
C:\>ipconfig
FastEthernet0 Connection:(default port)
Link-local IPv6 Address.........: FE80::20A:F3FF:FEAE:2BC2
IP Address......................: 10.1.100.1
Subnet Mask.....................: 255.255.255.0
Default Gateway.................: 0.0.0.0
C:\>ping 10.1.100.2
Pinging 10.1.100.2 with 32 bytes of data:
Reply from 10.1.100.2: bytes=32 time=1ms TTL=128
Reply from 10.1.100.2: bytes=32 time<1ms TTL=128
Reply from 10.1.100.2: bytes=32 time<1ms TTL=128
Reply from 10.1.100.2: bytes=32 time<1ms TTL=128
Ping statistics for 10.1.100.2:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 1ms, Average = 0ms
Hi smon,
the passwords are a throw back from a long time ago.
Console password Lambgirl1
Secret password Canada1
I am looking at ether channels as Nic teaming. (Maybe wrong in doing this)
MY LOGIC
CSW1
So logic create port channel 1, Create all the rules switcport trunk etc etc
On the Phisical ports Fa0/23-24 Put them into channel-group 1
Now all trunking rules should be coming from the config in port channel 1. But not sure.
Heres the config
interface Port-channel 1
switchport trunk allowed vlan 1,100,105,110
switchport mode trunk
switchport nonegotiate
!
interface Port-channel 2
switchport trunk allowed vlan 1,100,105,110
switchport mode trunk
switchport nonegotiate
interface FastEthernet0/20
duplex full
speed 100
!
interface FastEthernet0/21
switchport trunk allowed vlan 1,100,105,110
switchport mode trunk
switchport nonegotiate
duplex full
speed 100
channel-group 1 mode desirable
!
interface FastEthernet0/22
switchport trunk allowed vlan 1,100,105,110
switchport mode trunk
switchport nonegotiate
duplex full
speed 100
channel-group 1 mode desirable
!
In the lab i have configure all interfaces including the physical switch ports as trunk mode. But not sure if i should have done this.
The switchport Nonegotiate not sure if this should be used? but reading everyone seems to tuen of DTP traffic.
Thanks again for the quick response. The password show allow you to look at my config.
It seems to allow me to ping between PC0 and PC1 but still not sure about the config i used. Hi ristau5741 when i assigned IP addresses to the machines on seperate switches was not able to ping. restarted Packet Tracer but still the same. today it seems to work (i hate it when things do that). Cheers for the reply
More reading on this can you confirm if correct or not.
Configuration
CSW1
interface Port-channel 1
switchport mode trunk
Now we get to the interfaces
int range FA0/23-24
Switchport Mode trunk
Switchport nonegotiate (this turns of DTP (dynamic trunking protocol) not need at you are specifying the the negotiation)
Channel-group 1 mode desirable
Do wr
SW1
interface Port-channel 1
switchport mode trunk
Now we get to the interfaces
int range FA0/23-24
Switchport Mode trunk
Switchport nonegotiate (this turns of DTP (dynamic trunking protocol) not need at you are specifying the the negotiation)
Channel-group 1 mode auto
Do wr
I am guessing this correct config? Now my other question is......I want to allow the trunk to only pass the vlans specified.
Switch trunk allowed vlan 100,105,110 (where is this put in the config on the virtual Port-channel or the physical ports? or both?)
I know i am posting way to much but i dont like sitting back and people feeding me the answers without going away and trying to figure it out first. But i am learning so thank you.
Anyone? Just want to know were i would restrict the vlans using the the following command.
Switchport trunk allowed Vlan X
Is this placed in the port-channel 1 section or the physical interface Fa0/23
Should be an easy onw to answer
cheers
Quote from: weasleman on May 17, 2017, 08:52:53 AM
Anyone? Just want to know were i would restrict the vlans using the the following command.
Switchport trunk allowed Vlan X
Is this placed in the port-channel 1 section or the physical interface Fa0/23
Should be an easy onw to answer
cheers
Technically it goes on both but u can add it on the port-channel and the switch should automatically copy the config to the physical interfaces.
Cheers RoDDY.
On the physical interfaces, you should only configure physical properties and configure them as child interfaces
For example, to add port 1 and 2 to an LACP Etherchannel:
interface range GigabitEthernet 1/0/1 - 2
speed 1000
duplex full
channel-group 1 mode active
Then apply all of the switchport commands directly to the Portchannel interface
interface Po1
description Po1 - Uplink to xxxx
switchport mode trunk
switchport nonegotiate
switchport trunk native vlan 666
switchport trunk allowed vlan 1,2,3
load-interval 30
The child interfaces will automatically inherit this configuration.
If you add commands on the child interfaces directly, they could move into suspended state because of the config mismatch.
I thought as much i have a Udemy course that i am using in conjunction with a CCNA book.
The Udemy course the basically does this
Interface port-channel 1
Switchport mode trunk
Interface range fa0/23-24
Speed 100
Duplex full
switchport mode trunk (Which is why i queried this)
Switchport nonegotiable
channel-group mode active
Thanks again for clarifying my brain doesn't process things unless i understand why I am doing something and it didn't make sense putting the config in two separate places.
If you mod 1 member interface of the port-channel, the port-channel members interface configurations will no longer match and cause the port channel to go either inconsistent or go down. (I forget exactly which, but neither is passing traffic)
VTP traffic. I am guess that when i create a trunk and if the native vlan does not have access to the trunk VTP packets would not be pased as this is untagged traffic. Never mind think i just answered my own question.
Not sure if this was a homework question as I didn't read it thoroughly. All I have to say is - don't use VTP. Get used to not using it.
there's nothing wrong with VTPv3. It fixes everything wrong with v2 and is sane. But people are so burned by old school horror stories they often still refuse to deploy it.
Only the primary server can change the vlan database, and you need to manually use a force command to take over the primary role, so basically that's all the issues of v2 fixed.
So i am guessing that VTP v3 is enabled by default with the new IOS or do you have to enable it some how. Just curious.
The VTP makes sense thats why i use it i dont want to create vlan 100 with name on 5 different switches.
Is there a reason why you said VTP gives you problems ? curious what these are ?
Quote from: wintermute000 on May 27, 2017, 01:11:38 AM
there's nothing wrong with VTPv3. It fixes everything wrong with v2 and is sane. But people are so burned by old school horror stories they often still refuse to deploy it.
Only the primary server can change the vlan database, and you need to manually use a force command to take over the primary role, so basically that's all the issues of v2 fixed.
I know what VTPv3 is, and I still don't recommend it. In this day and age, if you're going to automate deployment of VLANs across your environment, take the extra steps and automate more (i.e. just use Ansible, etc.). The sooner you can get off the proprietary teet - the better. Why add any complexity (big or small) if it's only going to solve one small part of the provisioning problem when you can solve that and more with something else?
I find it rather delicious to have a vendor argue for a vendor-neutral environment, as it then makes it easier for that vendor to replace another. :smug:
Thing is, if VTPv3 makes things easy and works and we have all Cisco stuff anyway, just use it. But get a Linux scripting box to do the automation, not Prime. Prime can't even check IOS version, which is a pain for those of us that want to use SNMP to monitor access ports. 12.2(35) and earlier uses different code on the switchport that 12.2(55) and later changes. Prime does not help me *at all* there, and that's just one example why it's not the automation solution you're looking for.
And, if you've got that Linux box scripting things for you, then it makes it easier and more possible to cut over to other vendors and to use methods other than VTPv3 to provision VLANs.
Quote from: deanwebb on May 31, 2017, 06:53:04 AM
I find it rather delicious to have a vendor argue for a vendor-neutral environment, as it then makes it easier for that vendor to replace another. :smug:
Thing is, if VTPv3 makes things easy and works and we have all Cisco stuff anyway, just use it. But get a Linux scripting box to do the automation, not Prime. Prime can't even check IOS version, which is a pain for those of us that want to use SNMP to monitor access ports. 12.2(35) and earlier uses different code on the switchport that 12.2(55) and later changes. Prime does not help me *at all* there, and that's just one example why it's not the automation solution you're looking for.
And, if you've got that Linux box scripting things for you, then it makes it easier and more possible to cut over to other vendors and to use methods other than VTPv3 to provision VLANs.
Oh, sure, because the rest of the network world hasn't been saying this for years. It MUST be because I'm a *vendor* who has ulterior motives. In case you haven't looked outside of your shop, said vendor hasn't really needed to make that argument - it's already been out there and why certain legacy vendors who can't keep up are getting replaced. But I digress.
It has nothing to do with me being a vendor - it has everything to do with knowing the world outside of what a certain vendor says it should be - and working with customers who are solving these problems today. I don't care what vendor it is - why on earth would you settle for just provisioning VLANs when you can get off your arse and put forward some effort to automate way more than that, for free (Unless you want to take advantage of the spiffy Tower capabilities which most do), with a solution that can not only provision switches/routers but servers, firewalls, load balancers, etc., that can integrate with something like Jenkins to provide workflow automation and checkpoints. Don't take my word for it - talk to other people out there that do it today with or without a certain vendor's gear - it's a no-brainer. I mean, I'm lazy, but at the same time if I were in your shoes, the first thing I would be doing as a network/system/whatever admin outside of the daily firefight is figuring out how to automate things which will take some "capex" of time on my part, but I know in the end it will heavily reduce the "opex" of my time, so-to-speak, AND make me more valuable to the company I'm working for, and any future companies I work for after having gained the experience. I did this as a desktop support guy over ten years ago and figured out how to create an imaging solution using a combination of Acronis (Not even the expensive corporate version) and Windows Sysprep that allowed me to apply a corporate standard image to any desktop or laptop - regardless of hardware - back before you had the expensive solutions there are today to accomplish the same. This saved the company money and we got to a point where everyone kept all of their data on network storage so if there was a problem that took longer than 5 minutes to fix, we'd just wipe their box and start over - again saving time. It's glorious when you finally achieve it - it's worth the hours and hours you pour into it initially. We had an IT team of 3 support a corp office and 17 branch offices. I handled help desk, asset management (figured out how to improve this too by learning and creating an Access database instead of the Excel spreadsheet they were doing it on previously), administered the company's volume licensing, did 100% of the imaging, and even some Sharepoint. You can't do all of that by not finding ways to streamline/improve processes and sticking to the crap ways you've been doing things the previous years.
Like, here's an example, and yes I'm going to use who I work for. Let's say I go to a dev meeting, and I say, "Hey, let's implement a feature where a switch acts as a server, and provisions VLANs for other switches. No - that's it, that's all it does". Do you know how hard that would get laughed at? That feature was valuable back when we didn't have the automation tools we have today - now, it's not even worth a developer's time. I would be very surprised if you ever see it or something like it from another vendor down the road (unless they have no other way to automate) again. I would almost be willing to bet you that if Cisco didn't already have it, they wouldn't develop it today. That being said, I feel like you should prepare to work in any environment and avoid things like VTP, EIGRP, etc. if you can and there are other solutions widely-accepted by the community at-large. I didn't even use EIGRP when I was a Cisco fanboy and it's all I knew - we used OSPF and BGP - why? Because we knew we could possibly have other vendors in the mix and didn't want to have to deal with redistribution just to support running EIGRP in part of our environment - we saw it for what it was. I mean, EIGRP is so awesome that there are huge, dedicated sections to it in the CCIE R&S material, right? The answer is no if you don't know (Unless things have changed since I last looked).
And if you find my post a little abrasive, sorry not sorry. It's a vendor-neutral topic and I don't understand why you'd argue to just go the lazy route which gives you less in the big picture. Like, you literally just said to use VTP cause it's easy, but then automate using a "linux scripting box" - do you understand how conflicting that is?
There's my pompous, vendor-biased view. /rolleyes I know I'm probably wasting my breath, but it's off my chest.
Don't worry, mate, I was just winding you up with my first comment. I meant no wrong with it.
You really are quite right in your comments that going with vendor-neutral solutions really is the best way to do things precisely because of the interoperability and flexibility that they offer up.
There are times, though, when architects lose focus and begin to dictate tools and technologies instead of what they're supposed to do, which is to define services. Too often, architects say, "We'll use this to do that, now go implement it" instead of, "We want these three things: find the product that does them best and send the bill of materials to the project manager."
Then there are vendors that like to show how "It's a SNAP to set up!!!" :cough:cisco:cough:
:vendors:
It's only ever a snap to set up in the demo, unless you've done some heavy lifting up front to get everything to run smoothly. Like you said, put in the effort to get your scripting done right and then you'll have plenty of time for relaxation later. Relax now as you pump out those snappy setups, not only do you find stuff that makes the setup unsnappy, there's other scalability issues later on.
Quote from: deanwebb on June 01, 2017, 01:23:53 PM
Don't worry, mate, I was just winding you up with my first comment. I meant no wrong with it.
Mission accomplished.
#Triggered
:kramer:
:XD:
Quote from: deanwebb on June 01, 2017, 01:23:53 PM
Then there are vendors that like to show how "It's a SNAP to set up!!!" :cough:cisco:cough:
Yeah it seems all vendors do this to varying degrees... that's what I don't enjoy about the sales aspect and why I try to keep myself wrapped up in actual engineering work than doing a bunch of pre-sales type of work. Unfortunately though the writing is on the wall that a certain vendor is going to be getting too big to maintain the "One SE does it all" model and they're going to have to break out into pre- and post- sales at some point... honestly hopefully I can land in the latter.