Dell PowerConnect 5324

Talk about setting up your home network.

Re: Dell PowerConnect 5324

Post#101 » Thu Mar 26, 2015 3:35 pm

Fun with console cables and DB9 'gender benders'.

*Digs out rusty Cisco CCNA memories*
User avatar
STC
 
Posts: 6805
Joined: 6 June 2011
HTPC Specs: Show details
5+ YrsTGB VeteranStaff
By the Community, for the Community. 100% Commercial Free.

Want decent guide data back? Check out EPG123

Post#102 » Sat Mar 28, 2015 2:06 am

First things first.....Live TV for the truck.

Decided to have a little fun tonight. Port forwarding in Vyatta is a piece of cake.
Attachments
LiveTVforTheTruck.jpg
User avatar
Crash2009
 
Posts: 4344
Joined: 17 May 2012
Location: Ann Arbor, Michigan
HTPC Specs: Show details
5+ YrsTGB Veteran

Post#103 » Sun Mar 29, 2015 4:23 pm

Venom51 wrote:It is a waste of a port but if it's working for you then so be it.

Do you have a second instance of DHCP running on the router in VLAN2. Once you segment the networks then broadcast messages are not passed between the 2 VLANS. There should be an option in the Edge router to have set a DHCP pool in each VLAN. I'd have to see the inner workings of the ERL to explain how to do it on that device.

It's referred to as Option 82 in some equipment. DHCP Relay in others and DHCP helper address in other.

Looks like the ERL refers to it as a Relay. https://community.ubnt.com/t5/EdgeMAX-CLI-Basics-Knowledge/EdgeMAX-Set-up-DHCP-relay-on-interfaces/ta-p/473935


It took a little time for your suggestion to motivate me to look into DHCP in the router. Did some reading over at Ubiquity and found some CLI tools.

dhcp-server

show dhcp leases
show dhcp client leases
show dhcp statistics
clear dhcp lease (one IP at a time)
clear dhcp leases (clear all)
renew dhcp interface eth1, eth2, eth1.1, eth1.2 (one interface at a time)

Cleaned up a few DHCP errors that I found in the log.
-authoritative was set to disable
-different IP's with duplicate MAC's

There is a sniffer built into the router, so now I will be able to see what the problem is. I don't quite have a grip on it yet but I've read there is a little more configuration in the router that needs to be done. Has something to do with tagged packets from the switch being returned as untagged. Still trying to wrap my head around it. May be the DHCP Relay you pointed me to. Gotta do more reading.

LINUX SNIFFER

sudo tcpdump -n -v -e -i eth1.1 port 67

You were sure right about the learning curve. 6 hours to find clear dhcp leases
User avatar
Crash2009
 
Posts: 4344
Joined: 17 May 2012
Location: Ann Arbor, Michigan
HTPC Specs: Show details
5+ YrsTGB Veteran

Post#104 » Mon Mar 30, 2015 4:11 am

I'll see if I can help you understand 802.1q tagging. When you are sending packets around in a single flat layer 2 network, all the traffic is handled with MAC addresses. When you send a packet from your machine to another machine in the network, the IP address isn't really involved beyond your machine sending an ARP request to find out which mac address is assigned the IP. Arp request is a broadcast so every machine in the layer 2 segment see it and only the machine that has the IP for which you are looking to send traffic responds. When it does both your machine and the switch update their MAC tables with that information and cache it for a period of time. The switch will also know on which port that MAC responded.

In Layer 3 we get in to routing and most of that you already understand. Once you start to break the layer 2 networks in to VLANs than you have to wrap your head around a couple more things. In a VLAN capable switch you have made 2 VLANs in the above case VLAN 1 and VLAN 2. At layer 2 any devices in VLAN 1 can talk to each other and any devices in VLAN2 can talk to each other. However devices in VLAN 1 can't talk to devices in VLAN 2 and vice versa. In order to allow those two Layer 2 VLANs to talk we now need a Layer 3 device, unique IP subnets for each and routing interfaces for each. That's what you have when you plug VLAN1 into port 23 and VLAN 2 into port 24 and build out the routing interfaces on the ERL. As you know this works and there is nothing wrong with leaving it that way. As long as you have the extra ports available on the devices there is no specific need to go any further. But let's take the following scenario. You have become port poor and you want to make better use of the ones available to free up some ports for other things. We can free up one on each device utilizing Trunking and VLAN tagging.

When you want to send traffic for multiple VLANs between multiple switches or to a router on a single port the devices need a way to figure out which packets belong to which VLANs to make decisions about where to send the traffic. That's the purpose of 802.1q tags. When a packet from any VLAN is placed on a trunk ports a 4 byte tag is added to the header to identify the VLAN from which it originated. Once the packet reaches the other end of the trunk the tag is read by the switch or router and the packet is stripped of it's tag and forwarded on to it's destination. So the packet path looks as follows.

Packet leaves the PC untagged. It enters the switch port untagged. The switch looks at the destination mac address and looks it up in it's table. If the mac address isn't in the local table the CPU then tags the packet and places it on the trunk to be sent to it's destination. At the other end of the trunk the packet arrives and the receiving device reads the tag and the destination mac address. It looks up the mac address it's local table and if that device exists in it's mac table it will strip the tag and send the packet to the port to which the mac address is associated. That's a simplistic break down of how it works.

Once you wrap your head around it from then on it will seem so simple. It becomes a little more complicated once you get into the blurred lines that are layer 3 switches or what I like to refer to them as "multi-port lightweight routers. They can do a lot of things a router can do but not everything.
User avatar
Venom51
 
Posts: 557
Joined: 12 June 2011
Location: Cumming,GA
1+ YrsTGB Veteran

Post#105 » Tue Mar 31, 2015 2:01 am

Great timing! I was just about to report that I got it all figured out. Actually no, but I am a bit closer to understanding how DHCP makes this all happen. When you were talking about layer 2 being combined with layer 3, I was thinking, what "Black Magic Spell" makes this happen. In the past, I didn't need to know "How DHCP works". All I needed to know was the IP of the DHCP server and how to tell the device where to find it. Even now I don't need to know how it works, I just need to know how to read what the DHCP server is telling me, so that I know if my stuff is working properly. Thanks for the explaination! It helped a lot.

And when you were explaining the Tagging Untagging, I was drawing a blank there too. Lets just assume for a minute that I go back to Port 24 being the one and only Trunk. I think I understand now that the packets from VLAN1 go to the router untagged, just like previously. The packets from VLAN2 will be tagged by the switch, so the router knows where to send the payload.

1-Prior to the Vlan's the ports didn't need any help finding their way out of the switch. I believe (but I never tried) that I could plug the old or new router into any open port, and all the devices on all the ports would get out to the router, on to the modem, and internet. No configurations were necessary.

2-I think you said leave VLAN 1 untagged, so if 1-^ is true, VLAN 1 should be able to get out of any port without a trunk being defined. As a matter of fact we defined Port 24 as a Trunk and all the devices from VLAN 1 got through just fine.

3-Where the problem came in was after creating VLAN 2. VLAN 2 was unable to get out of port 24. Maybe I should have booted the router at this point. I read this week that the ERL's DHCP server needs a kick in the butt to activate changes. I'll try that next time I'm up when the kids are sleeping. I should have got that extra cable modem like you suggested, but I got so close without it.

Did a little experiment last night, just to get a feel for what's happening. Ran that sudo-tcpdump-mumbo-jumbo from the CLI of the router, then ran ipconfig /release and /renew from 192.168.2.50 and 192.168.1.41. Looks like tagging is working.

It was helpful for me to highlight the MAC's, etc.
Attachments
DiscoverOffer002.JPG
DiscoverOffer001.JPG
DynamicAddressTableSwitch.JPG
Last edited by Crash2009 on Tue Mar 31, 2015 2:12 am, edited 1 time in total.
User avatar
Crash2009
 
Posts: 4344
Joined: 17 May 2012
Location: Ann Arbor, Michigan
HTPC Specs: Show details
5+ YrsTGB Veteran

Post#106 » Tue Mar 31, 2015 2:11 am

Continued....
Attachments
RequestInform.JPG
User avatar
Crash2009
 
Posts: 4344
Joined: 17 May 2012
Location: Ann Arbor, Michigan
HTPC Specs: Show details
5+ YrsTGB Veteran

Post#107 » Tue Mar 31, 2015 6:33 pm

Remember that the router port on the other end of the line from port 24 will need to understand that it is a trunk port as well so that it can handle looking at the tags and sending them where they need to go as well as adding the tag before it sends it back down the trunk to the switch. Both ends are involved for this to work.
User avatar
Venom51
 
Posts: 557
Joined: 12 June 2011
Location: Cumming,GA
1+ YrsTGB Veteran

Post#108 » Wed Apr 01, 2015 12:38 am

not to be too simplistic.... :-).... I always thought of a trunk port like a large pipe (the trunk) with multiple smaller pipes made out of different colors within it (vlans). For everything to flow (work right), both sides of the pipe have to be connected and the colors must match the "socket" on each end when connected.
PlainEric
 
Posts: 15
Joined: 7 May 2014
HTPC Specs: Show details
+++H0
"You don't become a failure until you're satisfied with being one. "

Post#109 » Wed Apr 01, 2015 12:39 am

That's actually a really good way to think about it. Other than there is only a single pipe. Maybe a better way to look at is compare the packets to skittles. Each VLAN is a specific color skittle and packets are painted a specific color on the way in and then sorted by color on the way out.
User avatar
Venom51
 
Posts: 557
Joined: 12 June 2011
Location: Cumming,GA
1+ YrsTGB Veteran

Post#110 » Wed Apr 01, 2015 12:44 am

You told me about Relay before. Do you think this is the missing piece to my puzzle?

I think the skittles from VLAN2 are being sent to the Black Hole.
Attachments
DHCP_Relaying003.JPG
DHCP_Relaying002.JPG
DHCP_Relaying001.JPG
User avatar
Crash2009
 
Posts: 4344
Joined: 17 May 2012
Location: Ann Arbor, Michigan
HTPC Specs: Show details
5+ YrsTGB Veteran

Post#111 » Wed Apr 01, 2015 1:48 am

You are headed in the right direction.
User avatar
Venom51
 
Posts: 557
Joined: 12 June 2011
Location: Cumming,GA
1+ YrsTGB Veteran

Post#112 » Wed Apr 01, 2015 10:01 am

Attachments
DHCP_Relaying004.JPG
User avatar
Crash2009
 
Posts: 4344
Joined: 17 May 2012
Location: Ann Arbor, Michigan
HTPC Specs: Show details
5+ YrsTGB Veteran

Post#113 » Thu Apr 02, 2015 11:07 pm

Success yet?
User avatar
Venom51
 
Posts: 557
Joined: 12 June 2011
Location: Cumming,GA
1+ YrsTGB Veteran

Post#114 » Fri Apr 03, 2015 2:37 am

No, not yet. Haven't even read those last 2 links yet.

I tried a couple things in the relay section of the router and blew it up. Did a reset, and got the subnets back. Simplified the switch a bit 1-22 is all VLAN 1, 23 is VLAN 2, 24 goes to eth1 on the router and is set to trunk.

I think the switch is good. All I have left to do is figure out how to convince the router to receive the packets with the mac's from vlan 2, and relay them to the dhcp server, so that the members of vlan 2 can get an IP.

In the first picture, I have tried server 192.168.1.1 and 192.168.2.1 with interface eth1

Next try will be 192.168.1.1 and 192.168.2.1 with interface eth2

I have no ideas yet for what to put in the Relay Options. If I mouse-over the ! mark:

hop-count = Policy to discard packets that have reached specified hop-count
max-size = Maximum packet size to send to a DHCPv4/BOOTP server
port = port number to listen on
relay-agents-packets = Policy to handle incoming DHCPv4 packets which already contain relay agent options
Attachments
DHCP-RelayAgentPartA.JPG
DHCP-RelayAgentPartB.JPG
User avatar
Crash2009
 
Posts: 4344
Joined: 17 May 2012
Location: Ann Arbor, Michigan
HTPC Specs: Show details
5+ YrsTGB Veteran

Post#115 » Fri Apr 03, 2015 3:12 am

I'll try the Cisco defaults from post 112 tomorrow.
User avatar
Crash2009
 
Posts: 4344
Joined: 17 May 2012
Location: Ann Arbor, Michigan
HTPC Specs: Show details
5+ YrsTGB Veteran

Post#116 » Fri Apr 03, 2015 1:31 pm

Crash2009 wrote:I'll try the Cisco defaults from post 112 tomorrow.


It appears that some progress has been made. Still not quite right though. The way I read this capture, Dell-Studio sends a Discover from vlan 2, and the reply is an Offer of IP 192.168.1.199 from 192.168.1.1 (the wrong side of the subnet)

My retaliation to that is to set 192.168.2.50 static on the Dell-Studio with default gateway 192.168.2.1

Dell-Studio now reports that I need to: "Investigate router or broadband modem issues" and gave me 3 suggestions which basically say "Cold Boot the Router and Modem"

I'm out of time for this morning, but I will soft boot the router when I return home from work. I don't have time to recover the router if it blows up again.
Attachments
DiscoverAndAnOffer.JPG
User avatar
Crash2009
 
Posts: 4344
Joined: 17 May 2012
Location: Ann Arbor, Michigan
HTPC Specs: Show details
5+ YrsTGB Veteran

Post#117 » Mon Apr 13, 2015 2:36 am

Still working on it.....Here's something that isn't in the manual.

To relay DHCP requests from interface eth0 to eth1, use the following commands:

configure
edit service dhcp-relay
set server 10.1.0.1
set interface eth0
set interface eth1
commit

MikroTik suggests 10.1.0.2, I read a post or 2 suggesting 10's also.

What's up with these 10.x.x.x numbers? If this is what I need to set the server to, I definitely missed that part. I was trying to jam 192.168 numbers in there. Ha Ha! No wonder it blew up.
This can be set in the GUI and confirmed in the CLI. Likely vice versa.
Attachments
Dhcp-relay.jpg
SetInterfaceServer.JPG
User avatar
Crash2009
 
Posts: 4344
Joined: 17 May 2012
Location: Ann Arbor, Michigan
HTPC Specs: Show details
5+ YrsTGB Veteran

Post#118 » Mon Apr 13, 2015 11:40 am

I just checked with my Soothsayer! I'm told that another week of reading is in my future, and that I should start with:

Multiprotocol Label Switching.

http://en.wikipedia.org/wiki/Multiprotocol_Label_Switching

This learning curve is getting a bit steep. Yeah, I could just put the numbers in, but I need to know "why".
Attachments
Soothsayer.jpg
User avatar
Crash2009
 
Posts: 4344
Joined: 17 May 2012
Location: Ann Arbor, Michigan
HTPC Specs: Show details
5+ YrsTGB Veteran

Post#119 » Thu Apr 16, 2015 12:56 am

You have no need for MPLS. If you were trying to do something clever like tie multiple data centers together and transport layer2 traffic between them and avoid the additional complexity of routing then MPLS would be a good choice. Consider MPLS to straddle Layers 2 and 3.

I bought a ERPro this afternoon so I'll be able to give you some hands on help in the near future. I can't say it will replace my 2811's but if I like it then I may extricate them from the network. I got it for $220 so if nothing else I can get my money back out of it fairly easily. I really like my Unifi AP Pro's so I'm optimistic.
User avatar
Venom51
 
Posts: 557
Joined: 12 June 2011
Location: Cumming,GA
1+ YrsTGB Veteran

Post#120 » Thu Apr 16, 2015 3:21 am

Thanks, I'll skip that chapter then.

This project reminds me of my first ISA modem in WFWG, only I haven't got to the part where I say....."How did I do that?"
User avatar
Crash2009
 
Posts: 4344
Joined: 17 May 2012
Location: Ann Arbor, Michigan
HTPC Specs: Show details
5+ YrsTGB Veteran

PreviousNext

Return to Networking / Windows Home Server



Who is online

Users browsing this forum: No registered users and 1 guest

cron