IRC Logs

Network: freenode Channel: #cisco

	Enter your search terms Submit search form
	Web www.irclog.org

[00:18]<[mzvzyw]>sup
[00:18]<[mzvzyw]>err, need to change my nick
[00:25]<-- svgvsdyzgjvr__ xr>/dev/null")
[00:34]<gndyvx>expense reports are fun
[00:34]<gndyvx>[Aileran]: why?
[00:34]<[ryfgzrg]>Don't work at Matrix anymore
[00:34]<[ryfgzrg]>so I'm whipping out the gaming handle
[00:36]<gndyvx>you named yourself after where you work?
[00:42]<[ryfgzrg]>Yeah, I did before. Lack of creative process, heh.
[01:16]<axuaxyvy>what would make an access point not forward traffic to a vlan? the port on the switch it set up to trunk and allow the vlan, the associated client is on the right vlan, there are no filters...
[01:20]<gndyvx>many things, maybe the bridge-group is improperly setup, trunking not right on the ap side
[01:20]<gndyvx>native vlans
[01:21]<vcul>sounds like a homework question :)
[01:22]<mjllyg>Well, if you are having problems with trunking / native vlans, take a look at the logging buffer "sho logg", it should be logged there by default.
[01:28]<axuaxyvy>tkup: it's not =p
[01:28]<axuaxyvy>nemith: what should the native vlan have to do with anything? it's trunked...
[01:28]<gndyvx>well if they don't match
[01:28]<gndyvx>ie i am sending untagged frames on vlan X and they are recieved and Vlan Y
[01:29]<gndyvx>on
[01:29]<axuaxyvy>ah, true. well they're both set to native vlan of 1.
[01:29]<axuaxyvy>there's nothing in the log
[01:30]<gndyvx>got a config?
[01:30]<gndyvx>also did you check the existance of the vlan in switch?
[01:30]<axuaxyvy>err, sure. want the whole thing or just relavent parts?
[01:30]<gndyvx>show vlan, see if it is listed
[01:31]<axuaxyvy>yeah, it's there. i'm not that stupid =x
[01:31]<gndyvx>i am not implying that
[01:31]<axuaxyvy>i know
[01:31]<axuaxyvy>well, the vlan is there. but it's not listed under Ports. which i assume is because it's trunked?
[01:32]<axuaxyvy>i mean - the port isn't listed there. the vlan is listed
[01:32]<gndyvx>just some people get hung up when they add a switchport access vlan and the vlan is created automatically for them
[01:32]<gndyvx>yeah thats find
[01:32]<gndyvx>er fine
[01:32]<axuaxyvy>configs are forthcoming.
[01:32]<gndyvx>those are just member ports, not trunks
[01:32]<gndyvx>aye
[01:37]<axuaxyvy>http://rafb.net/paste/results/1YInmM67.html
[01:37]<axuaxyvy>the machine i'm trying to talk to is actually on another switch, but i've confirmed that the vlan works between switches
[01:39]<dydyc_>hi everybody
[01:40]<gndyvx>http://rafb.net/paste/results/1YInmM67.html
[01:40]<gndyvx>er
[01:40]<gndyvx>ip address 10.0.2.30 255.255.255.224 <-- i don't think IRB works with an ip address on the interface
[01:41]<gndyvx>also I didn't think this was allowed :) i might have to play with some of the new code again
[01:41]<axuaxyvy>IRB?
[01:41]<gndyvx>Intergrated routing and bridiging
[01:41]<axuaxyvy>it works - i can ping it from that vlan
[01:41]<gndyvx>pretty much the bridge groups
[01:41]<gndyvx>yeah, the ip address works.. but the bridging between fa0.2 and dot110.2 isn't
[01:43]<gndyvx>thats why BVI's are required
[01:43]<axuaxyvy>okay - that's gone
[01:44]<axuaxyvy>i still don't get any forwarding
[01:44]<gndyvx>also with WEP and open authenication you will be able to associate, but the AP will drop any packets that it can't decrypt
[01:45]<axuaxyvy>...that's what i want, no?
[01:45]<gndyvx>yeah
[01:45]<gndyvx>i am just saying check your WEP code on the client
[01:45]<axuaxyvy>ah. well it works fine if i put that ssid in the native vlan.
[01:46]<gndyvx>well never mind then :P
[01:47]<axuaxyvy>heh. i mean i set the thing up through the web interface for the most part, so there could only be minimal breakage by me fooling with it =p
[01:50]<gndyvx>yeah
[01:54]<axuaxyvy>it... it doesn't have to be in workgroup bridge mode, does it?
[01:56]<kgzggf-kzys>longshot here but is it possible to have a switch set to have a monitor VLAN ie. instead of a monitor port have everything broadcased to a vlan
[01:57]<axuaxyvy>no.
[01:57]<axuaxyvy>heh, that *was* a long shot =p
[01:57]<kgzggf-kzys>lol ya i figured
[01:57]<cuzyjscrv>hey, nothing wrong with the concept
[01:58]<cuzyjscrv>it's possible, you just have to replace IOS/CatOS with your own firmware to support it :)
[01:58]<kgzggf-kzys>that would allow me to reloce my IDS/IPS ststem to another building :)
[01:58]<2drrrxrg_>actually it is possible
[01:58]<2drrrxrg_>what platform
[01:58]<axuaxyvy>haha. i was right? because i actually didn't notice he'd just joined and misread "to" as "you". i thought he was applying it to my problem.
[01:59]<kgzggf-kzys>2970 12.1(19)EA1d
[01:59]<2drrrxrg_>monitor session 1 source vlan
[02:00]<2drrrxrg_>see if it takes that command
[02:00]<2drrrxrg_>if you want to move the IDS to a different location you use RSPAN
[02:00]<kgzggf-kzys>ok would it be source or destination
[02:00]<2drrrxrg_>instead of the destination being a port you make it an rspan VLAN
[02:01]<2drrrxrg_>the disadvantage is it can be taxing on your layer 2 trunk links depending on how much traffic you're spanning
[02:02]<kgzggf-kzys>probably a bad idea then, its a 48port gigE with alot of traffic... i guess ill just have to settle with it in the same data closet
[02:03]<axuaxyvy>nemith: Possible encryption key mismatch between interface Dot11Radio0 and station 0016.cb04.d593 <- look what i found.
[02:04]<axuaxyvy>nemith: which is strange because the same SSID settings work in vlan 1...
[02:05]<2drrrxrg_>Kernel-Kris: say you have even 10% utilization it would mean that you would be redirecting 4.8Gbps out your trunk links
[02:05]<kgzggf-kzys>out all trunk links, even if they are pruned?
[02:06]<2drrrxrg_>in the transit path of the rspan vlan
[02:07]<2drrrxrg_>rspan is where the source is local and the destination is remote
[02:07]<2drrrxrg_>to move the traffic from the local device to the remote device it copies it onto a special vlan that you define
[02:07]<2drrrxrg_>the vlan can't be pruned in the transit path otherwise the traffic wont get through
[02:07]<kgzggf-kzys>bmcgahan: ok so there is not better way to do it.. the needed switch is directly connected to it
[02:08]<2drrrxrg_>probably better just to leave it as it is
[02:09]<2drrrxrg_>the reason you do rspan usually is you have a sniffer centrally located
[02:09]<2drrrxrg_>then if you need to sniff a specific segment you can just temporarily enable rspan
[02:09]<2drrrxrg_>so you don't have to move the sniffer physically
[02:09]<2drrrxrg_>but with something like IDS that's constant you're better off just having the IDS physically connected
[02:10]<2drrrxrg_>unless you know bandwidth isn't an issue
[02:11]<kgzggf-kzys>bmcgahan_: well were multi homed 7Mbps and all traffic from both carriers terminate into it....wouldnt be a smart choice
[02:12]<2drrrxrg_>well it depends on what your trunks are like
[02:12]<2drrrxrg_>14Mbps isn't that much if you have gig channels as your uplinks
[02:12]<dydyc_>i got my 2621 today
[02:12]<2drrrxrg_>but if you have single 100Mbps links then it's probably not a great idea
[02:14]<kgzggf-kzys>bmcgahan_: thats the problem, it has trunk links to 4other switchs over 100M and one fiber trunk......
[02:21]<kgzggf-kzys>bmcgahan_: Thanks for your help

Back to #cisco
Or go to some related logs:
#php
#gentoo
#suse
#debian
#gentoo