[c-nsp] ISP LAN Design
Mark Tohill
Mark at u.tv
Wed May 25 07:20:22 EDT 2005
Hi,
New to the list.
Has anyone good references/sites/docs regarding ISP LAN Design?
I have "Cisco ISP Essentials" - Greene,Smith but am looking for
something in particular with:
1. Organisation of VLAN and what services to put in what VLANs'. What
are the considertations, aprt from the normal broadcast domain
segregation etc...
We're planning on upgrading core with 6509 with Sup720 etc.
Any info. appreciated!
Thanks
Mark
-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of
cisco-nsp-request at puck.nether.net
Sent: 25 May 2005 11:45
To: cisco-nsp at puck.nether.net
Subject: cisco-nsp Digest, Vol 30, Issue 105
Send cisco-nsp mailing list submissions to
cisco-nsp at puck.nether.net
To subscribe or unsubscribe via the World Wide Web, visit
https://puck.nether.net/mailman/listinfo/cisco-nsp
or, via email, send a message with subject or body 'help' to
cisco-nsp-request at puck.nether.net
You can reach the person managing the list at
cisco-nsp-owner at puck.nether.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of cisco-nsp digest..."
Today's Topics:
1. RE: Basic DHCP config assistance (Voll, Scott)
2. Fining the host who is spoofing (Dan Lockwood)
3. OOPS: Fining the host who is spoofing (Dan Lockwood)
4. Re: OOPS: Fining the host who is spoofing (Jared Mauch)
5. RE: 3750 Metro (Cisco List)
6. Re: OOPS: Fining the host who is spoofing (Gert Doering)
7. bgp in the "core" (matthew zeier)
8. Re: bgp in the "core" (Matt Buford)
9. Re: 6500 SUP720 High Latency and Jitter issues (Simon Leinen)
----------------------------------------------------------------------
Message: 1
Date: Tue, 24 May 2005 10:31:33 -0700
From: "Voll, Scott" <Scott.Voll at wesd.org>
Subject: RE: [c-nsp] Basic DHCP config assistance
To: "Marcello Pedersen" <mpedersen at touchbase.us>,
<cisco-nsp at puck.nether.net>
Message-ID: <D713462ED535184D830F6F6301753E7E01511E59 at VISHNU.wesd.org>
Content-Type: text/plain; charset="us-ascii"
What is routing Vlan 3?
Where is the DHCP scope for Vlan 3?
How does the router now about the vlan's?
Are you using CM and cisco IP Phones for your voice? If so, why aren't
you using switchport access vlan 1 and switchport voice vlan 3?
What is your trunk port back to the router?
Scott
-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Marcello
Pedersen
Sent: Tuesday, May 24, 2005 10:16 AM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] Basic DHCP config assistance
Hi,
I am trying to get DHCP to work on multiple VLANs. My lab is pretty
simple:
Lucent Firewall --> 2651XM router and DHCP --> 3560 PoE Switch
I am trying to have phones on VLAN 3 get IP from 265x1XM as well as PCs
on VLAN 1.
PCs get an IP address however the phones don't. I think it is because my
VLAN 3 has no IP address but does it need to have an IP?
Thanks!
Marcello
My running config on the router:
version 12.3
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname ussf2521RT1
!
boot-start-marker
boot-end-marker
!
logging buffered 51200 warnings
enable secret
!
username cisco privilege 15 secre
ip subnet-zero
!
!
ip cef
!
ip dhcp pool ITS
network 172.25.2.128 255.255.255.128
option 150 ip 172.25.1.15
default-router 172.25.2.130
dns-server 172.25.1.10
!
!
ip domain list 172.25.1.10
ip domain name xyz
ip name-server 172.25.1.10
no ftp-server write-enable
!
interface GigabitEthernet0/0
description $ETH-LAN$$ETH-SW-LAUNCH$$INTF-INFO-GE 0/0$
ip address 172.25.2.2 255.255.255.128
ip nbar protocol-discovery
duplex auto
speed auto
!
interface GigabitEthernet0/1
ip address 172.25.2.129 255.255.255.128
duplex auto
speed auto
!
interface Serial0/2/1:23
no ip address
isdn switch-type primary-qsig
isdn incoming-voice voice
no cdp enable
!
ip classless
ip route 0.0.0.0 0.0.0.0 172.25.2.1
!
ip http server
ip http authentication local
ip http secure-server
ip http server
ip http authentication local
ip http secure-server
!
ip access-list extended DHCP
permit ip host 0.0.0.0 host 255.255.255.255
!
!
end
version 12.1
no service pad
service timestamps debug uptime
service timestamps log datetime
no service password-encryption
service sequence-numbers
!
hostname ussf3560sw1
ip subnet-zero
ip routing
ip dhcp smart-relay
!
ip name-server 172.25.1.10
ip dhcp-server 172.25.2.129
cluster enable ussfinternalnet 0
!
spanning-tree mode pvst
interface FastEthernet0/1
no ip address
srr-queue bandwidth share 10 20 40 80
srr-queue bandwidth shape 0 0 0 0
no mdix auto
!
interface FastEthernet0/2
switchport trunk encapsulation dot1q
switchport mode trunk
switchport voice vlan 3
no ip address
srr-queue bandwidth share 10 20 40 80
srr-queue bandwidth shape 0 0 0 0
no mdix auto
spanning-tree portfast
ALL PORTS CONFIGURED THE SAME
!
interface FastEthernet0/24
switchport trunk encapsulation dot1q
switchport mode trunk
switchport voice vlan 3
no ip address
srr-queue bandwidth share 10 20 40 80
spanning-tree portfast
!
interface GigabitEthernet0/1
no ip address
srr-queue bandwidth share 10 20 40 80
srr-queue bandwidth shape 0 0 0 0
!
interface GigabitEthernet0/2
no ip address
srr-queue bandwidth share 10 20 40 80
srr-queue bandwidth shape 0 0 0 0
!
interface Vlan1
ip address 172.25.2.130 255.255.255.128
ip helper-address 172.25.2.129
!
interface Vlan3
no ip address
ip helper-address 172.25.2.129
!
ip default-gateway 172.25.2.130
ip classless
ip route 0.0.0.0 0.0.0.0 172.25.2.129
ip http server
!
!
line con 0
line vty 0 4
password 5upport2021
login
line vty 5 15
password 5upport2021
login
!
end
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
_______________________________________________
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/
------------------------------
Message: 2
Date: Tue, 24 May 2005 11:26:19 -0700
From: "Dan Lockwood" <dlockwood at shastacoe.org>
Subject: [c-nsp] Fining the host who is spoofing
To: <cisco-nsp at puck.nether.net>
Message-ID:
<D87C1436D1DECB4A8FEB646F4FFDCE8602AA4118 at EXCHANGE08.shastalink.k12.ca.u
s>
Content-Type: text/plain; charset="US-ASCII"
Hi all,
We have a few hosts on our network that are spoofing addresses. Our
uRPF configs stop the traffic from spreading off the local subnet but I
would like to track down the offending PC and fix the problem. The
issue that I'm having is that when I log the uRPF violations all I see
is something like:
------------------------------
Message: 3
Date: Tue, 24 May 2005 11:26:19 -0700
From: "Dan Lockwood" <dlockwood at shastacoe.org>
Subject: [c-nsp] OOPS: Fining the host who is spoofing
To: <cisco-nsp at puck.nether.net>
Message-ID:
<D87C1436D1DECB4A8FEB646F4FFDCE8602AA411A at EXCHANGE08.shastalink.k12.ca.u
s>
Content-Type: text/plain; charset="US-ASCII"
Hi all,
We have a few hosts on our network that are spoofing addresses. Our
uRPF configs stop the traffic from spreading off the local subnet but I
would like to track down the offending PC and fix the problem. The
issue that I'm having is that when I log the uRPF violations all I see
is something like:
.May 24 08:56:08.712 PDT: %SEC-6-IPACCESSLOGP: list 133 denied udp
172.16.76.192(0) -> 207.46.130.100(0), 1 packet
Is there some way to cross reference the uRPF violation to something
like a MAC address that can be associated with a device?
Thanks,
Dan
------------------------------
Message: 4
Date: Tue, 24 May 2005 14:29:52 -0400
From: Jared Mauch <jared at puck.nether.net>
Subject: Re: [c-nsp] OOPS: Fining the host who is spoofing
To: Dan Lockwood <dlockwood at shastacoe.org>
Cc: cisco-nsp at puck.nether.net
Message-ID: <20050524182952.GA95877 at puck.nether.net>
Content-Type: text/plain; charset=us-ascii
On Tue, May 24, 2005 at 11:26:19AM -0700, Dan Lockwood wrote:
> Hi all,
>
> We have a few hosts on our network that are spoofing addresses. Our
> uRPF configs stop the traffic from spreading off the local subnet but
I
> would like to track down the offending PC and fix the problem. The
> issue that I'm having is that when I log the uRPF violations all I see
> is something like:
>
> .May 24 08:56:08.712 PDT: %SEC-6-IPACCESSLOGP: list 133 denied udp
> 172.16.76.192(0) -> 207.46.130.100(0), 1 packet
>
> Is there some way to cross reference the uRPF violation to something
> like a MAC address that can be associated with a device?
add 'log-input' to the end of that al 133
- jared
--
Jared Mauch | pgp key available via finger from jared at puck.nether.net
clue++; | http://puck.nether.net/~jared/ My statements are only
mine.
------------------------------
Message: 5
Date: Tue, 24 May 2005 12:29:57 -0700
From: "Cisco List" <CiscoList at go180.net>
Subject: RE: [c-nsp] 3750 Metro
To: <cisco-nsp at puck.nether.net>
Message-ID:
<7A2C7588564516488CD950202373E682014B6B1E at imail.inet.go180.net>
Content-Type: text/plain; charset="us-ascii"
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
We've now got one deployed in production after some testing and will
likely deploy more. We were off to a rocky start at first due to
some odd IOS issues. Our main problem was MTU related, which
shouldn't be much of a surprise for anyone doing MPLS over ethernet
links on Cisco gear. The box has a system MTU and a system jumbo
MTU. With the current 12.2.x code the system MTU controls all MTU
settings for the entire box except for the MTU on the ES GigE ports.
In theory that sounds ok but it isn't. We found that the system MTU
command limits the mpls mtu command and there is no ip mtu command.
So, what we ended up with was an MTU of 1546 on the ES GigE port's IP
interface (physical port was 9000) so OSPF was failing the MTU check.
We were able to get around that but when we tried to map an EoMPLS
circuit it failed the MTU checks because it felt that port on the
3750 was 1546 and the remote side was 1500. There is no ip mtu
command in 12.2 currently. From what the TAC said it was pulled from
12.2 because it didn't actually do anything.
We argued with the TAC some regarding how retarded this
implementation was. In our opinion it made the box useless for one
of its primary functions (MPLS services) if you expect to run full
1500 byte frames. We're used to setting 'ip mtu 1500' on interfaces
that have a higher MTU set for MPLS labels etc. and the boxes end up
happy.
We ended up getting the thing to work by reverting to some older code
12.1.X where the ip mtu command exists and the system and system
jumbo commands work as expected. We now have the ES ports running at
9000 bytes, all IP interfaces at 1500 bytes, and MPLS interfaces at
1546.
In this configuration we were able to load up 12 ports of 10/100 and
two GigE ports and run them all at line rate using a SmartBits. In
terms of performance we're happy with the box. There is a new 12.2
release due out in the next week or so that apparently fixes the
crazy MTU commands.
All in all it seems to be a good box, just needs to mature some more.
Good luck,
Chad
- ----------------------------
Chad E Skidmore
One Eighty Networks, Inc.
http://www.go180.net
509-688-8180
> -----Original Message-----
> From: Michel Renfer [mailto:michel.renfer at lan.ch]
> Posted At: Tuesday, May 24, 2005 8:15 AM
> Posted To: Cisco List
> Conversation: 3750 Metro
> Subject: [c-nsp] 3750 Metro
>
>
> Hi All!
>
> Anyone has informations regarding the (routing and mpls)
> performance of the Catalyst 3750 Metro? Anyone using this
> device in the field and is able to share his experiences?
>
> cheers,
> michel
>
> _______________________________________________
> 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/
>
-----BEGIN PGP SIGNATURE-----
Version: PGP 8.1
iQA/AwUBQpOAs02RUJ5udBnvEQIjQwCdH96tLhs4iqTg75mi2TwtXDnCky4AnR50
a8QQ1Ed0IfGZ9PtZ6VtDJnxj
=E0X4
-----END PGP SIGNATURE-----
------------------------------
Message: 6
Date: Tue, 24 May 2005 23:33:12 +0200
From: Gert Doering <gert at greenie.muc.de>
Subject: Re: [c-nsp] OOPS: Fining the host who is spoofing
To: Dan Lockwood <dlockwood at shastacoe.org>
Cc: cisco-nsp at puck.nether.net
Message-ID: <20050524213312.GJ7864 at greenie.muc.de>
Content-Type: text/plain; charset=us-ascii
Hi,
On Tue, May 24, 2005 at 11:26:19AM -0700, Dan Lockwood wrote:
> .May 24 08:56:08.712 PDT: %SEC-6-IPACCESSLOGP: list 133 denied udp
> 172.16.76.192(0) -> 207.46.130.100(0), 1 packet
Using "log-input" instead of "log" on the ACL 133 should show you the
MAC.
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany
gert at greenie.muc.de
fax: +49-89-35655025
gert at net.informatik.tu-muenchen.de
------------------------------
Message: 7
Date: Tue, 24 May 2005 15:51:00 -0700
From: matthew zeier <mrz at intelenet.net>
Subject: [c-nsp] bgp in the "core"
To: "cisco-nsp at puck.nether.net" <cisco-nsp at puck.nether.net>
Message-ID: <4293AFD4.9060906 at intelenet.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
I'm looking for examples of data center-like networks and whether or not
they
run ibgp in the "core" or just on their transit routers.
My network, roughly, is like this:
transit ---- transit --- transit
core -- core
access switches, L2
The "core" provides L3 connectivity for customer networks and each
transit
router is connected to each "core" router/switch. The access switches
are
plain L2 switches. Core and transit run OSPF.
The problem I have is that the transit routers are the boxes initiating
my BGP
routes and I contend that if they become disconnected from the "core",
having
them continue to announce routes is a Bad Thing.
I believe that the core should do the route origination.
Am I off my rocker?
------------------------------
Message: 8
Date: Tue, 24 May 2005 19:40:35 -0400
From: "Matt Buford" <matt at overloaded.net>
Subject: Re: [c-nsp] bgp in the "core"
To: "matthew zeier" <mrz at intelenet.net>, <cisco-nsp at puck.nether.net>
Message-ID: <011201c560b9$fc933810$0161a8c0 at speedy>
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
reply-type=original
matthew zeier" <mrz at intelenet.net> wrote:
> I'm looking for examples of data center-like networks and whether or
not
> they
> run ibgp in the "core" or just on their transit routers.
[...]
> The "core" provides L3 connectivity for customer networks and each
transit
> router is connected to each "core" router/switch. The access switches
are
> plain L2 switches. Core and transit run OSPF.
>
> The problem I have is that the transit routers are the boxes
initiating my
> BGP
> routes and I contend that if they become disconnected from the "core",
> having
> them continue to announce routes is a Bad Thing.
>
> I believe that the core should do the route origination.
>
> Am I off my rocker?
Nope, you are right on. The datacenters I manage are built out in a
similar
design.
The core should run iBGP and originate the routes. Also, I put a full
BGP
table in the core so that it can make the proper decision and forward
the
packet directly to the right border router. I don't want to see core1
->
border1 -> border2 -> transit, or something like that. I want to see
only 2
hops in my datacenter (such as coreX -> borderX -> transit) for all
paths.
6500s with at least sup2/msfc2 (sup720 recommended) work great for the
"core" role here, able to handle the full BGP table and everything else
necessary.
------------------------------
Message: 9
Date: Wed, 25 May 2005 12:42:04 +0200
From: Simon Leinen <simon at limmat.switch.ch>
Subject: Re: [c-nsp] 6500 SUP720 High Latency and Jitter issues
To: Tim Stevenson <tstevens at cisco.com>
Cc: Dan Benson <dbenson at swingpad.com>, "Lupi, Guy"
<Guy.Lupi at eurekanetworks.net>, cisco-nsp at puck.nether.net
Message-ID: <aaacmjk2o3.fsf at limmat.switch.ch>
Content-Type: text/plain; charset=us-ascii
Tim Stevenson writes:
> If you are measuring latency by pinging the RP itself, then that is
> not a good indicator of network performance at all. Are you saying
> that pings *through* the 6500 see the latency as well? or just pings
> to the RP? Your original mail suggests customers are being impacted,
> so either their traffic is getting s/w switched, or the CPU has
> little/nothing to do w/it.
The number behind the slash suggests that indeed much (possibly all)
traffic through the router is MSFC- (software-) switched. Slightly
edited extract from Dan's message <429347B8.90201 at swingpad.com>:
DB> DCA-BV-RTR#sho processes cpu | exclude 0.00
DB> CPU utilization for five seconds: 70%/28%; 1': 40%; 5': 39%
DB> DCA-BV-RTR#sho processes cpu | exclude 0.001' 5'
DB> CPU utilization for five seconds: 35%/24%; 1': 39%; 5': 39%
DB> DCA-BV-RTR#sho processes cpu | exclude 0.001' 5'
DB> CPU utilization for five seconds: 30%/26%; 1': 37%; 5': 38%
DB> DCA-BV-RTR#sho processes cpu | exclude 0.001' 5'
DB> CPU utilization for five seconds: 32%/28%; 1': 36%; 5': 38%
DB> DCA-BV-RTR#sho processes cpu | exclude 0.001' 5'
DB> CPU utilization for five seconds: 32%/28%; 1': 36%; 5': 38%
DB> DCA-BV-RTR#sho processes cpu | exclude 0.001' 5'
DB> CPU utilization for five seconds: 35%/31%; 1': 36%; 5': 38%
Since traffic is switched by the MSFC, it competes for resources with
other things such as BGP processing. BGP processing is probably what
is hurting in this case, because I think it does have these
table-walking jobs that run every minute.
> As long as the h/w is programmed correctly, the CPU can be at 100%
> and not effect latency through the system.
Yes, but the problem seems to be that traffic IS being sw-switched, so
it would be good to find out why. You are hinting at that in
> Are the customers that are seeing the problem the same ones that are
> being NATted?
- although NAT/PAT is supposed to be hardware-accelerated on the
PFC-3BXL that is used here - and Chuck Church suggested in
<B6621ED4D0AD394BBA73CA657DFD897642F427 at MSPEXBE01.wamnet.inc> to look
for "Any weird QOS configured on it" - although many forms of QoS are
also implemented in hardware on the PFC-2/3. There are many other
features that lead to software switching when enabled. My personal
favorites are complex ACLs such as Reflexive ACLs or CBAC.
As Ian Cox said on this list, turning a 7600 into a 7200 (by forcing
it do to software forwarding) is never a good idea. But it's easy to
do so by accident, and hard to find out after the fact why it
happened.
So I'd be interested in how you would look at a router to find out
*why* hardware-based forwarding is not being used.
Is there any finer-grained accounting on what MSFC-based forwarding is
actually doing, e.g. executing complex ACLs, doing NAT, performing
encapsulation and decapsulating for tunnel protocols that aren't
hardware-supported?
Another useful tool would be a config checker that would take a config
file and the description of the platform (e.g. Catalyst6500/7600 OSR
with Sup720-3BXL), and IOS version, and that would highlight which
parts of the configuration will cause packets to be software-switched,
and to which extent (e.g. will only those packets that enjoy the
feature be software-switched, or all packets on the interface/router
where the feature is activated).
--
Simon.
------------------------------
_______________________________________________
cisco-nsp mailing list
cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
End of cisco-nsp Digest, Vol 30, Issue 105
******************************************
More information about the cisco-nsp
mailing list