[c-nsp] Problem interface

[Skeeve Stevens]

Nick,

Excellent suggestions... Thanx mate. 



_______________________________________________________
Skeeve Stevens, RHCE     Email: skeeve at skeeve.org
Si vis pacem, para bellum


-----Original Message-----
From: Nick Payton [mailto:npayton at microsoft.com] 
Sent: Monday, 29 August 2005 12:22 PM
To: skeeve at skeeve.org; cisco-nsp at puck.nether.net
Subject: RE: [c-nsp] Problem interface

Here are a few from the way I see it:

ACL aggregation - all policy for these network ranges are shoved into one
ACL making it operationally harder to support. Furthermore, one ACE
oversight potentially exposes multiple segments so the vulnerability surface
is increased with each secondary network added. 

Outage impact - If that interface experiences a problem or the cabling
connecting to that interface, then multiple network segments are impacted by
this. Again, they have implemented a single point of failure for all your
servers here - that is just bad design if network resiliency was ever a
concern for them. Also, what happens when this interface bounces for any
given reason or the downstream switch? You could potentially drop the router
with nothing more than what would appear to be an arp storm since there are
so many hosts connected to this single interface or at the very least start
dropping inbound packets on this interface. There are a bunch of scenarios
that could cause problems here.

Throughput - You could potentially saturate that interface just with
secondary network intercommunications and that wouldn't even account for
traffic that is destined for external networks. I will assume this is a real
possibility unless they have all their services striped appropriately across
all these segments - so remove this if a server on segment X doesn't need to
ever talk to another server on a different segment assigned to this same
interface. 

Routing - I doubt they are running RIP or IGRP as an IGP, but if they were
there are some split-horizon issues that you would need to take into
account. Even with OSPF you lose some functionality in that all those
secondaries have to be in the same area by default. 


Some of these may or may not be a concern given your topology. At the very
least I would break these out onto their own sub-interfaces just for
operational simplicity if nothing else. I would also ask them what the
tipping point is for splitting these networks off? Is it when they start
having a problem or....? Just sounds like lack of foresight has put them in
this situation and you are doing the right thing by trying to get them out
of it. Or you could just propose assigning a /21 to this interface too =0
May the network god's be with you!

Regards,
Nick 


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Skeeve Stevens
Sent: Sunday, August 28, 2005 4:07 PM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] Problem interface


Hey guys,

	I have a new client for whom I manage their border and BGP.  The
router is a 7206vxr.  The router was badly setup before.. And I have
re-written 90% of the router already.  But their network is badly setup, but
I need some more reasons why I can pressure them to change.

	The key issue is that they run all their server - a couple of
hundred - in layer 2 with all the servers landing on a dot1q trunk on the
7206vxr.

interface FastEthernet1/0.200
 encapsulation dot1Q 200
 ip address x.x.103.1 255.255.255.0 secondary  ip address x.x.104.1
255.255.255.0 secondary  ip address x.x.96.1 255.255.255.0 secondary  ip
address x.x.100.1 255.255.255.0 secondary  ip address x.x.101.1
255.255.255.0 secondary  ip address x.x.102.1 255.255.255.0 secondary  ip
address x.x.105.1 255.255.255.0 secondary  ip address x.x.97.1 255.255.255.0
no ip proxy-arp  no ip mroute-cache  no snmp trap link-status  no cdp enable

So essentially every server, a couple of hundred land on the router here
with one of the above addresses being the servers default gateway.

I would like some advice from you guys in how many ways this is bad so I can
hit them with it all and convince them to a layer 2/3 switched environment.


_______________________________________________________
Skeeve Stevens, RHCE     Email: skeeve at skeeve.org
Website: www.skeeve.org  - Telephone: (0414) 753 383
Address: P.O Box 1035, Epping, NSW, 1710, Australia

eIntellego - skeeve at eintellego.net - www.eintellego.net
_______________________________________________________
I'm a groove licked love child king of the verse Si vis pacem, para bellum



_______________________________________________
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/

========================================================================
 iBurst Wireless Broadband from $34.95/month   www.platformnetworks.net
 Forward undetected SPAM to:                   spam at mailsecurity.net.au
========================================================================