I don't have the chance to work on the production network at work so I kind of want to do it at home in my lab. I wanted to take the typical switching lab with 4 3550s but add a pair of routers to act as the core. Then I would have pair of 3550s as the distro/aggregation layer and the other 2 3550s as the access, maybe even throw in a couple 2950s too. I just want to make it like the production type network and practice. Maybe after that is setup I can create an OSPF lab with some other routers connecting those with serial cables. Is this the right approach of laying out a lab like this?
I was thinking something like this in Visio below. I just did a quick network topology layout.
(http://s12.postimg.org/lehe17q3d/network.jpg) (http://postimg.org/image/lehe17q3d/)
you're on the right track.
- add a cross connect between the two core switches.
- servers are usually dual homed.
- experiment with different topologies routing from core to WAN devices. Try different protocols, try redistribution, try layer 2 (i.e. VRRP or HSPR on LAN side of the WAN routers), note the different behaviour, plusses and minuses of each.
- make the spoke sites dual homed (one link into the OSPF WAN, the other into the EIGRP WAN). Make it failover properly, then do it the other way (i.e. prefer the 'other' WAN) :)
- create ISP router(s) as a termination point for the two BGP internet links. Pretend you are advertising a /24. Make BGP prefer one link, but be able to failover the /24 to the other.
I would strongly suggest trying GNS3 or VIRL, you can pretty much run up the whole damned thing in either. There is a good thread in this forum (started by setit) on building a GNS3 IOU server, that's free. If you want the official Cisco badge of quality (tm) then buy a VIRL license for same same but different. This is a golden age for labbing R&S, do take advantage.
What's the goal? To study general R&S?
Quote from: wintermute000 on June 10, 2015, 06:25:46 AM
you're on the right track.
- add a cross connect between the two core switches.
- servers are usually dual homed.
- experiment with different topologies routing from core to WAN devices. Try different protocols, try redistribution, try layer 2 (i.e. VRRP or HSPR on LAN side of the WAN routers), note the different behaviour, plusses and minuses of each.
- make the spoke sites dual homed (one link into the OSPF WAN, the other into the EIGRP WAN). Make it failover properly, then do it the other way (i.e. prefer the 'other' WAN) :)
- create ISP router(s) as a termination point for the two BGP internet links. Pretend you are advertising a /24. Make BGP prefer one link, but be able to failover the /24 to the other.
I would strongly suggest trying GNS3 or VIRL, you can pretty much run up the whole damned thing in either. There is a good thread in this forum (started by setit) on building a GNS3 IOU server, that's free. If you want the official Cisco badge of quality (tm) then buy a VIRL license for same same but different. This is a golden age for labbing R&S, do take advantage.
Thank you for the great feedback wintermute000. I'm going to try each and everyone of those lab scenarios. I know this is the best way to learn. To answer your question aspiringnetworker, yes this is to learn from my studies. I find myself reading a lot in books and online but I don't feel like I have grasp the concepts and want to take it farther and lab it.
- I should of known about the cross connects between the core switches a mistake on my part.
- The idea to make the spoke sites dual homed is a good one. I read about this alot so that will be good to put in practice.
- To create an ISP router in the lab what makes it an ISP router? I guess I'm asking will it be setup any differently than the other routers? I really like this one because I can finally practice BGP.
I have all this gear at work that's just laying around. I did want to build it up for fun. But I also have VIRL at home that I think I will build it up too for even more practice. I just want to learn it all and not just say i learned it from a book. I can explain what STP or BGP is and does but I want to make sure I can build it and fix it.
to create an ISP router basically make it BGP peer to your router and advertise dummy loopbacks to advertise the internet.
You can then test internet connectivity by seeing if the 'internet' IPs can ping your /24 or whatever you are advertising to the internet.
Lots of detail I can get into here, but I'll let you discover for yourself :)
Actually wintermute000 you got me very curious and would love it if you could share more. I'm learning a lot more than expected here. I really like that. I am excited to try the BGP stuff.
I will update the Visio diagram tonight and upload it.
what are you looking for me to 'share '? Happy to answer any specific questions you have, but I'm not in a position to give you a lab on a plate so to speak
I can understand because that's just a massive thing, I mean that network can have all kinds of lab pieces. You just mentioned that you could get into lots of detail so I thought you were holding back. I think the best thing is for me to get my hands dirty in this lab and set it up. I will ask this though when you have a setup like the diagram shows, how do you go about starting the setup. My first thought would be to work from the inside out starting with the core and build out. Do you take special considerations on design and configuration, maybe you have a set way you work it out. I think that every network will be different of course I'm just wonder how to start this out as I'm cabling up everything now. I keep thinking to start at the core.
I made some of the changes to the Visio diagram. The only part I'm a little unsure about is the one link into the OSPF WAN, the other into the EIGRP WAN part. Do I have the right idea in terms of connectivity?
(http://s11.postimg.org/qzaqa4rwv/topology_UPDATED.jpg) (http://postimg.org/image/qzaqa4rwv/)
looks fine, but you'll never do redistribution like that. I'd also recommend to include your core devices in the routing instances.
+1.
Have separate internet and WAN routers at first.
Run the same WAN routing protocol, then switch it, then start playing around with redistribution.
And yes, route from core to WAN segments. Again, at first, Keep It Simple Stupid and use the same protocol, then try to make them different. Also you'd typically not run primary/secondary links via different protocols if you can help it, as ristau says. If you want to model EIGRP vs OSPF WAN, have a spoke site pure EIGRP or OSPF. Then move onto having different protocols everywhere.
OFF-TOPIC: Mad props to fsck for the Moss avatar.
:itcrowd:
"are you from the paaaaast?" -Roy
"yes we never want to find ourselves in invalid memory" -Moss
Quote from: ristau5741 on June 15, 2015, 07:27:01 AM
looks fine, but you'll never do redistribution like that. I'd also recommend to include your core devices in the routing instances.
I'm not quite sure what you mean by including my core devices in the routing instance. Can you please explain?
Quote from: fsck on June 15, 2015, 05:36:30 PM
Quote from: ristau5741 on June 15, 2015, 07:27:01 AM
looks fine, but you'll never do redistribution like that. I'd also recommend to include your core devices in the routing instances.
I'm not quite sure what you mean by including my core devices in the routing instance. Can you please explain?
So the big square boxy things in the middle needs to help the little rectangular things at the bottom, get their packets to the roundy things at the top.
You would want to populate the routing tables in the network core, hosts at the access layer need to know how to get places. if you just populate the routing tables in the WAN distro block, routes will never get to the core, and hosts in the access layer will not know how to get places. you could use static routes, but with 2 connections going to 2 different providers, this will be confusing and a better plan is needed. sending the wan block IGP routes into the core will help.
Quote from: ristau5741 on June 16, 2015, 07:25:19 AM
Quote from: fsck on June 15, 2015, 05:36:30 PM
Quote from: ristau5741 on June 15, 2015, 07:27:01 AM
looks fine, but you'll never do redistribution like that. I'd also recommend to include your core devices in the routing instances.
I'm not quite sure what you mean by including my core devices in the routing instance. Can you please explain?
So the big square boxy things in the middle needs to help the little rectangular things at the bottom, get their packets to the roundy things at the top.
You would want to populate the routing tables in the network core, hosts at the access layer need to know how to get places. if you just populate the routing tables in the WAN distro block, routes will never get to the core, and hosts in the access layer will not know how to get places. you could use static routes, but with 2 connections going to 2 different providers, this will be confusing and a better plan is needed. sending the wan block IGP routes into the core will help.
I got it thank you for explaining.
For creating production type lab you have to follow some simple steps:
1. Have separate internet and WAN routers at first.
2. Same WAN routing protocol is to be run and then it is to be switched, after that start playing around redistribution.
3. Route from the core to WAN segments. At first, keep the connections simple using same protocol and then try to make them different.
(Note) : Spoke suite pure EIGRP or OSPF is required if you want EIGRP vs. OSPF WAN. Then move on to different protocols.
I'm trying to connect the access layer to my distribution switches, but I must be missing something.
Here's what I did so far, on both switches. I'm still just working on the left side of the topology.
I created both interfaces as a trunk
switchport trunk encapsulation dot1q
switchport mode trunk
I haven't created any VLANs, otherwise I would of added switchport trunk allowed vlan x so I thought maybe that's why I can't router traffic. I'm still not telling the traffic how to move. I'm a little confused on what to do next. Is this where I would need something like ip-route to direct the traffic, but not use ip-default gateway? If I connect a host to the core switch I can ping the ISP router, so I got that working but I want to bring that host down to the access layer and have it ping up to the ISP.
a trunk config without defining vlans = allow all vlans
what vlan is your router connected to.
just make sure on the access switch, its the same vlan.
also make sure your trunk is not blocked in STP or otherwise disabled in any other way (errdisabled etc.)
Got it! thank you I will continue the setup and see how far I get.
I was reading a bit about common Access-Distribution block designs. I'm currently working on building up the core switches in this lab network. How do you determine which of the 3 configurations. Layer 2 loop free, Layer 2 looped, Layer 3 routed. I know each will have its good and bad but when you guys design your networks what are you keeping in mind?
Quote from: fsck on December 28, 2015, 05:15:45 PM
I was reading a bit about common Access-Distribution block designs. I'm currently working on building up the core switches in this lab network. How do you determine which of the 3 configurations. Layer 2 loop free, Layer 2 looped, Layer 3 routed. I know each will have its good and bad but when you guys design your networks what are you keeping in mind?
I think we consider services that the customers need, then that defines the network architecture for deployment.
Got it. That makes sense. I will just try all the scenarios and see how they work and recover from failure tests and such.