IRC Logs

Network: freenode Channel: #cisco

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

[00:00]<sycn>alt: that's what i thought, which is fine, but i don't want to waste time if the 7912s are a headache with asterisk
[00:00]<sycn>maybe i'll try one or two and see
[00:00]<fjsvnf>7912 have gone EOS, and no need to go for polycoms, cisco's speakerphones on the whole 79xx series is manufactured by polycom. Remember the early software trains that had the banner CLARITY BY POLYCOM on the cisco screens?
[00:00]<dzzc1livn>loather-work,
[00:01]<fjzvxnz-wjzc>twkm: what's cisco's ticker symbol?
[00:01]<vwcd>csco
[00:01]<fjzvxnz-wjzc>Dark3LIte,
[00:01]<vwcd>last: 18.07, +0.12
[00:01]<dzzc1livn>pm
[00:02]<gndyvx>nemith> twkm: you have cisco stock?
[00:02]<gndyvx>15:57 <@t
[00:02]<gndyvx>er
[00:02]<gndyvx>http://www.google.com/finance?q=TWTC&hl=en
[00:02]<gndyvx>woo
[00:02]<jygc>oh
[00:03]<jygc>he's not pasting a cisco.com link
[00:03]<jygc>hurray
[00:03]<jygc>;-)
[00:03]<vwcd>twtc is okay. it's had a nice range, if you are a day trader type.
[00:05]<gndyvx>yeah
[00:05]<gndyvx>i am just hoping it continues up
[00:06]<gndyvx>so at least my stock options are worth something
[00:06]<vwcd>options give me gas.
[00:06]<gndyvx>i am getting close to my employee stock purchase program too
[00:06]<gndyvx>and i'd like to make a little on it
[00:17]<vcul>i've been reading a few books on stock tech analysis and opened an account online. short term stock trading looks very interesting
[00:31]<sazdn>eh
[00:31]<sazdn>did i hear someone say finance
[00:32]<jygc>Hm
[00:33]<jygc>I'm learning prefixes from a peering exchange point and a transit provider, I'm sharing them over iBGP to another router on another site. Is it possible on the other site to differenciate peering and transit ?
[00:33]<jygc>Should I use communities ?
[00:36]<jygc>I'm sure you have the answer
[00:36]<jygc>;-)
[00:38]<sycn>does anyone know this one...
[00:38]<sycn>if i enable rtp header-compression on an interface that is currently handling VoIP traffic, will the calls get dropped?
[00:39]<gndyvx>oink: hmm
[00:39]<gndyvx>sike: calls won't be dropped
[00:39]<sycn>excellent. thanks
[00:40]<gndyvx>sike: but good change that if you don't have rtp header-compression on the other side that calls will no longer have any data
[00:40]<gndyvx>so there is no audio
[00:40]<gndyvx>or one way audio
[00:40]<sycn>nemith thanks
[00:41]<sycn>so the *right* way would be to enable it passive on one end, then enable it on the other, and then enable it non-passive back on the first side, right?
[00:41]<sycn>(if that makes any sense?)
[00:41]<gndyvx>or just leave it passive
[00:41]<gndyvx>yeah it did
[00:41]<gndyvx>and i think that will work
[00:41]<sycn>ok cool
[00:41]<sycn>is there any reason not to leave it passive?
[00:42]<gndyvx>not that i can think of
[00:42]<gndyvx>you can verify that is is compressing
[00:42]<gndyvx>and if it is, who cares
[00:42]<jygc>nemith: I dont want to setup two iBGP sessions, there's no need. Do you know what infos is included in a prefix ?
[00:42]<jygc>s/is/are/
[00:43]<gndyvx>between ibgp peers?
[00:43]<sycn>thanks nemith
[00:43]<jygc>Yeah
[00:44]<gndyvx>well for sure, as_path, next_hop and orgin are transitive mandatory
[00:44]<gndyvx>right?
[00:44]<gndyvx>so they will always be there
[00:44]<gndyvx>er well-known mandatory
[00:45]<gndyvx>not sure what exactly you are looking for
[00:45]<gndyvx>i mean all bgp attributes can be transfered
[00:46]<gndyvx>so you have two routers peering in the same as
[00:46]<gndyvx>and you don't want to do ibgp?
[00:46]<gndyvx>any reason?
[00:47]<jygc>re
[00:47]<jygc>Well
[00:47]<jygc>I'm already doing iBGP, I want to keep my iBGP session
[00:48]<gndyvx>k
[00:48]<`kgvyg>nemith: I have seen some 'so-called' high end consultants reccomend disabling it, (its not needed and doesn't help), and suggest that a 2651 is worthy of being in the core with bgp rotuing
[00:48]<jygc>I have two routers, [ a ] ----- [ b ], a learns a full table from a transit provider, and prefixes from multiple peering exchange points
[00:48]<gndyvx>`Kevin: disabling what?
[00:48]<`kgvyg>iBGP neighborship
[00:49]<jygc>b learns a full table from a transit provider, and a full table from a
[00:49]<gndyvx>2651 is fine, but i am confused on the rest
[00:49]<jygc>but I want b to prefer peering prefixes to transit, even if the as path has the same length in both sides
[00:50]<gndyvx>med?
[00:50]<jygc>So I was thinking of doing local preference based on communities sent by a to b
[00:50]<gndyvx>sure
[00:50]<jygc>Does it make sense ?
[00:50]<jygc>Yeah
[00:51]<gndyvx>`Kevin: for a dual home, maybe
[00:51]<`kgvyg>nemith: I had suggestion from a consultant to remove neighborship between them to improve load balancing from the switch.. between a 7206 and a 2651, he felt their was no need to have bgp calculate better routes etc in an enviornment that has voip and other laitency/jitter sensitive data
[00:52]<gndyvx>well thats a different story, you are no longer using bgp for shortest path
[00:52]<gndyvx>i guess you are doing per-session load balancing
[00:52]<`kgvyg>yea now..
[00:52]<gndyvx>sure
[00:52]<gndyvx>but those are specific requirements
[00:53]<gndyvx>all depends on what you want
[00:53]<`kgvyg>boss likes his suggestion, but i didnt see it as right being that we have a lot of local clients as well with one provider
[00:53]<`kgvyg>being that bgp should be fully meshed for that itself
[00:53]<gndyvx>no one fully meshes more than 3 routers anyway
[00:54]<`kgvyg>nemith: issue was that, 2651 had memory problems, so we do partial/summary routes
[00:54]<`kgvyg>do the same with the 7206, which had no issues, but ok. and then we took of the iBGP
[00:54]<gndyvx>so you have to completly seperate routers just sending traffic out, this has little advatage to static routes, the only thing is being able to annouce a prefix on both
[00:55]<gndyvx>well ibgp between the 2651 and the 7206?
[00:55]<`kgvyg>yea, we have a few /24's

Back to #cisco
Or go to some related logs:
#gentoo
#php
#iptables
#gentoo
#ubuntu