I need some advice regarding some basic routing and switching. Attached is a basic logical diagram that depicts my core network.
I have a public /21 assigned from my ISP that I need to subnet into /24's at my core. For the example's sake, we will say this public /21 is 220.127.116.11/21. Here is how I envision this working.. please step in and correct me with suggestions or if anything is wrong:
* Gi0/1 on the router will have an IP address of 18.104.22.168/30. This will be a small transit network to connect the core.
* The other end will be connected to a SVI on my core, VLAN 2, 22.214.171.124/30.
* Configure a static route on the 3865: ip route 126.96.36.199 255.255.248.0 188.8.131.52
* At this point, I need to be able to break down the /21 into smaller /24's. As an example, we will use VLAN3 (184.108.40.206/24). On the core: interface Vlan3 ip address 220.127.116.11 255.255.255.0
Does this seem like a valid configuration? I am unsure as to the static route that was configured on the 3865 above. Ideally, I do not want to have to add a new static route for every /24 that I subnet on the 3865. Can someone help me understand if this is the correct way to configure this? Please let me know if you need more information.
The design is valid...although I'm a little surprised that a provider is giving you a pub /21. What is wrong is the static...it not correct. The smartest thing for you to do is to enable a routing protocol like EIGRP and run it between the 3845 and the 3560. If not, then you will need to do the static route thing, but I would do it on a per /24 basis for now. It seems like you are only going to have a couple subnets, so I wouldn't worry too much about admin overhead of adding a static route.
The more complicated part of this is how you are going to configure the 3845 and how you're going to interact with the carrier considering you are using public space. Also, have you decided on a method of implementing security?
Good point. I am not -sure- that I will be getting a /21. Still waiting to hear back from my ISP. I just used a /21 as an example. All in all, I will need to have several /24's and several /25's. The reason that I do not want to touch the 3845 very often is that I do not actually manage it.. it is managed by our ISP (ATT). I have total control over the 3560.
So, if I do not implement EIGRP, you saying that I would need to create a static route for each /24, /25, etc on the 3845? For example:
ip route 18.104.22.168 255.255.255.0 22.214.171.124
.. where 126.96.36.199 = the uplink from the router. Or, would the static route need to be to the corresponding SVI on my 3560 for that /24?
What will EIGRP buy me in terms of management? It will keep me from having to use static routing for each of my /24's on the 3845?
What kind of service are they offering you? Are they just giving you Internet access, or is the 3845 acting as a firewall as well? I am thinking it's only giving you Internet access and you provide your own firewall...at least that is what I've commonly seen from AT&T managed Internet solutions.
If that is the case, then you really need to back to the drawing board and reengineer your network as there are several missing pieces. Bottom line, you don't want to have open access to your network from the Internet and will absolutely need some protection (firewall).
If you want to talk more about it send me an email or private message.
Ok, I don't see a link to send you a private message.
The 3845 will be providing internet access to our core. The main purpose of this network is to provide transit and customer based services, so there is no firewall in line with the core switch.
I'm wondering why my core can't just have a default route to the serial side of the 3845? If the 3845 has a default route for the entire /21, shouldn't I be able to carve out smaller /24's as I need to on my core without any additional configuration on the router?
I realize I need to figure out exactly how ATT is going to configure the 3845 before I can make any real decisions..
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...