Google Grupper støtter ikke lenger nye Usenet-innlegg eller -abonnementer. Historisk innhold er fortsatt synlig.

Q: about ISL trunks and SPAN on Cisco Catalyst switch

Sett 1 gang
Hopp til første uleste melding

Robert MacKinnon

ulest,
18. jan. 2001, 14:26:4818.01.2001
til
I've configured three of our Cisco catalyst 2900 series switches in the
following way:

SW1, port FA0/1 is an ISL trunk cabled to SW2, port FA0/1 using an
Ethernet cross cable. All ports on both switches are in the default
VLAN 1.

SW2, port FA0/2 is an ISL trunk cabled to SW3, port FA0/1 using an
Ethernet cross cable. All ports on SW3 are in the default VLAN 1.

The ISL trunks on SW1, port 1 and SW2, port 1 are network ports (to
control flooding). SW2, port 2 and SW3 have no network ports defined.

There is one port on SW3 defined as a SPAN port for monitoring SW3, port
1. We wish to place a network analyzer on that SPAN port to monitor all
traffic flowing between SW1, SW2 and into SW3 (but primarily SW1 and 2).

Is this setup going to work? Will I see all traffic on the two other
switches if I monitor the ISL trunk on SW3?
---
Rob.

bria...@yahoo.com

ulest,
19. jan. 2001, 23:57:1519.01.2001
til
In article <n2ge6to3qt7nhc2l8...@4ax.com>,

I'm puzzled. If you're using just one VLAN for the whole physical
network, why are you using ISL (or even trunking for that matter)?

My understanding re: network ports was that they are used as "last
resort" ports only, ie if the mac-address-table didn't contain the
destination mac address, it went out that port. I could be wrong,
however.

No, you will not see all the traffic on the other switches monitoring
from just one switch. If traffic on port sw1:fa0/4 is destined for
sw1:fa0/6 or even sw2:fa0/6, it isn't supposed to reach sw3. The only
exceptions are broadcasts, cdp, bpdu's, and vtp, if you're using it.
Oh, there are a few others, too, like multicasts, RIP/SAP for IPX, etc.,
but you get the idea. Basically, if it isn't going to (or leaving) SW3,
you won't see it.


Sent via Deja.com
http://www.deja.com/

Robert MacKinnon

ulest,
20. jan. 2001, 16:07:5220.01.2001
til
On Sat, 20 Jan 2001 04:57:15 GMT, bria...@yahoo.com wrote:

>I'm puzzled. If you're using just one VLAN for the whole physical
>network, why are you using ISL (or even trunking for that matter)?

I'm implmenting a highly available network using two switches and cross
coupling the various servers. If power disrupts one of the switches,
half the servers will die but higher level HA software like IBM HACMP
and eNetwork Dispatcher will cause recovery in the remaining machines,
failover in the firewalls and at least service will remain but it will
be crippled response.

I assumed from my reading the Cisco manuals that an ISL trunk was a
means to span VLANs over physical switches, which is my desire in this
network. SW3 is outside the HA network design but is used to connect
monitoring equipment.

---
Rob.

bria...@yahoo.com

ulest,
21. jan. 2001, 01:06:5621.01.2001
til
ISL's primary function (as well as 802.1q trunking, the IEEE standard)
is to carry multiple network information (or VLANs) through a single
connection. Traditionally, a switch port could only be assigned to one
particular network. Using ISL, a switch port carries multiple VLANs
between switches, where the switch distributes the encapsulated frames
(as opposed to tagged with dot1q) to their correct ports.

Yes, in the simplest terms, ISL is used to span VLANs across physical
switches. However, it is designed to span MULTIPLE VLANs where needed,
not just one. A simple crossconnect in your situation will work fine,
as long as all of the ports remain in the same VLAN (1 in this case).
It will also remove overhead from your switching fabric (although it
probably isn't significant with only three switches).

What type of monitoring are you trying to acheive off of SW3? Using
your scenario, there are a couple of different monitoring techniques
that could be used, from active pinging of the switch's management
interface to SNMP off of the switches or server. It sounded like you
were getting ready to set up a sniffer to the monitor port (just about
its only use, really). Was this going to be a full time sniffer,
scanning traffic for certain patterns?

Hope this helps or at least clarifies some things.

In article <s7vj6t4n7p4pabelu...@4ax.com>,

Rainer Nagel

ulest,
21. jan. 2001, 05:44:2221.01.2001
til
On Sun, 21 Jan 2001 06:06:56 GMT,
bria...@yahoo.com <bria...@yahoo.com> wrote:

>Using ISL, a switch port carries multiple VLANs
>between switches, where the switch distributes the encapsulated frames
>(as opposed to tagged with dot1q) to their correct ports.

Could you please explain this a bit more?
IMHO the only difference is the frame format.

Thanks
--
Rainer Nagel
Rainer...@tashrah.com
Duesseldorfer Linux User Group - http://www.dlug.de

bria...@yahoo.com

ulest,
21. jan. 2001, 12:31:5321.01.2001
til
In article <slrn96lfc9.4o...@dragon.angor.de>,

I'm not sure what you're asking. Explain ISL, explain 802.1q or why
it's unnecessary in this scenario?

Basically (and it may not answer your question):

ISL = encapsulated layer 2 frame using Cisco proprietary technology
(http://www.cisco.com/warp/public/741/4.html). The switch removes the
encapsulation from the frame before sending the new frame to the access
port.

802.1q = typical layer 2 frame with a section of the header specifying
the VLAN ID. If I remember correctly it's 2 or 4 bytes. The layer 2
frame is the same frame, however, that will go to the access port minus
the VLAN ID section in the header, which the switch removes.

Cisco calls 802.1q an "internal, or one level, packet tagging scheme"
while ISL is a "external, or two level, packet tagging scheme"
(http://www.cisco.com/univercd/cc/td/doc/product/l3sw/8540/rel_12_0/w5_1
5/config/8500over.htm#xtocid204810).

Not sure if this answers the question.

Rainer Nagel

ulest,
21. jan. 2001, 15:39:4921.01.2001
til
On Sun, 21 Jan 2001 17:31:53 GMT,
bria...@yahoo.com <bria...@yahoo.com> wrote:

>ISL = encapsulated layer 2 frame using Cisco proprietary technology
>(http://www.cisco.com/warp/public/741/4.html). The switch removes the
>encapsulation from the frame before sending the new frame to the access
>port.
>
>802.1q = typical layer 2 frame with a section of the header specifying
>the VLAN ID. If I remember correctly it's 2 or 4 bytes. The layer 2
>frame is the same frame, however, that will go to the access port minus
>the VLAN ID section in the header, which the switch removes.

So both are stripping the overhead (ISL-framing, VLAN-Tag).
The difference is not when it is stripped, but what is stripped.
My question was, if the switch would strip the 802.1Q Tag at another
time/piece of hardware than the ISL-Frame.

>Cisco calls 802.1q an "internal, or one level, packet tagging scheme"
>while ISL is a "external, or two level, packet tagging scheme"
>(http://www.cisco.com/univercd/cc/td/doc/product/l3sw/8540/rel_12_0/w5_1
>5/config/8500over.htm#xtocid204810).

OK. I didn't know cisco defines it in this manner.

>Not sure if this answers the question.

Yes, thanks.

Robert MacKinnon

ulest,
21. jan. 2001, 17:42:2121.01.2001
til
On Sun, 21 Jan 2001 06:06:56 GMT, bria...@yahoo.com wrote:

>It sounded like you
>were getting ready to set up a sniffer to the monitor port (just about
>its only use, really). Was this going to be a full time sniffer,
>scanning traffic for certain patterns?

Yes, we are going to set up a full time sniffer on the monitor port and
examine all IP traffic (ICMP,TCP and UDP) over primarily SW1 and SW2,
VLAN1. NOt necessarily specific patterns since we have other host based
IDS software to do that. This is more for network load analysis and low
level IP debug purposes.

>
>Hope this helps or at least clarifies some things.

It does, thank you.
---
Rob.

Brian Austin

ulest,
21. jan. 2001, 21:20:2921.01.2001
til
In article <r7pm6tcrork5oi5ao...@4ax.com>,

If you're trying to analyze ALL the traffic flowing in VLAN1, this won't
work, I'm afraid. The monitor port will only monitor one specific port,
whatever type of port that might be. It can't give you all of the
traffic on a VLAN, since the only traffic that would flow to the port
would either be broadcast or unicast destined for a port not on the
switch (referring to the crossconnect).

Best bet to watch all of the traffic leaving your data center is to use
SW3 as your egress switch. You could do this a couple of different
ways:

SW1 connection to SW3 = sw3:fa0/1
Monitor port on SW3 for SW1 = sw3:fa0/2
SW2 connection to SW3 = sw3:fa0/3
Monitor port on SW3 for SW2 = sw3:fa0/4
Another port on SW3 for outside world.

Two monitors would be required, though.

The other way would be like this:

SW1 connection to SW3 = sw3:fa0/1
SW2 connection to SW3 = sw3:fa0/2
SW3's connection to the "outside" world = sw3:fa0/3
Monitor port for outside world = sw3:fa0/4

This is assuming you're only monitoring ingress/egress traffic from your
data center. You still have a single point of failure, however (SW3).

If you're still not sure how to continue or looking for other ideas, it
might help if I knew where the switches were going from SW1 and SW2.
Are they connected to a router, a core switch that feeds a LAN/WAN, or a
distribution switch for a local network?

--
Brian Austin, CCNA
mailto: baust...@my-deja.com

"I make no claims to perfection or expert knowledge.
I simply relate my personal education and experience."
-- Me

0 nye meldinger