<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: Verdana; font-size: 10pt; color: #000000'><br><div class="gmail_quote">On Mon, Jan 26, 2009 at 6:26 PM, Lelio Fulgenzi <span dir="ltr"><<a href="mailto:lelio@uoguelph.ca" target="_blank">lelio@uoguelph.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div style="font-family: Verdana; font-size: 10pt; color: rgb(0, 0, 0);">Trying to separate the two (voice and network) will probably give you more trouble than it's worth. I can understand wanting to separate the two groups, but you should be able to work together without much issue. Most of the time, it's really just working out a configuration and then letting it be. </div>
</div></blockquote><div><br>What are your best practices for routing protocol configuration. /30's for the interfaces? Different RP then the rest of the network. Use the existing RP with proper areas/stubs/etc? <br><br><span style="font-style: italic; color: rgb(51, 51, 255);">Yes. We've been using /30s for now. Not sure if we will continue this way or not. As I mentioned earlier, we might consider two big networks for our next deployment. I'm not sure what you mean by the same/different RP. They are in the existing EIGRP domain as the rest of the data network. You could probably use VRF (or VRF-lite) but we have decided against that for now.</span><br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div style="font-family: Verdana; font-size: 10pt; color: rgb(0, 0, 0);"><br>We have two seperate voice and network groups, but we work very closely (we're in the same building actually) on many of our projects. The VGW and VG224s is a perfect example. We're working together on another project on moving our voice servers behind a set of redundant server farm switches with FWSM and ACE modules and making sure we conform to all of Cisco's requirements. This would be impossible without a strong network team.</div>
</div></blockquote><div> </div><div>Well I am actuay come from the network team and span both teams currently. Our network team is quite strong in networking but doesn't know a lick of voice. Our voice team however is currently comprised of old Siemens and Avaya techs who can hardly spell gateway and are having a hard time being introduced into voice and IOS routing on top of that is just way to much.<br>
<br>Also given the IOS stability issues I have had across devices I was trying to limit a VG224 or a dedicated ingress gateway to just one task. Not IGW as well as routing.<br><br>I guess the question I should ask is how do i template the RP configuration as best as I can to allows both teams to work more independently while preventing any catastrophic issues. <br>
<br>This may be more complicated than i thought.<br><br><span style="font-style: italic;"><span style="color: rgb(51, 51, 255);">I hear where you're coming from. We seperate our VGWs for voice only for now. The 3845 is probably over provisioned, but it does simplify things. I know quite a bit about networking, but if I didn't, I'm sure with the network team, they would have been able to configure things for me to the point where I could take over. </span><br style="color: rgb(51, 51, 255);"><br style="color: rgb(51, 51, 255);"><span style="color: rgb(51, 51, 255);">As far as template'ing the config...not sure how you might be able to do that. Any new VGW deployment will need both teams for sure. I'm sure after the first one, you can work together to agree to which parts are networking and which parts are voice. I configure the router all the time but don't dare to enter the EIGRP config. ;)</span><br></span><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div style="font-family: Verdana; font-size: 10pt; color: rgb(0, 0, 0);">
<br>Consider the the gateways as just another network device with voice as a service. <br><div class="Ih2E3d"></div></div></div></blockquote><div><br>I was afraid of that being that case. I think I need to attack this from another angle. I have two very stubborn teams who either don't want to do anything with voice (which with as unstable as it is I don't blame them) or don't want to do anything with networking (which as complicated as it is to a new comer i don't blame them either)<br>
</div></div><br>So maybe I am trying to figure out a technical solution to a political issue when I should really just be addressing it.<br><br style="color: rgb(51, 51, 255);"><span style="font-style: italic; color: rgb(51, 51, 255);">I think the two teams have to step up to supporting their particular area. It's not always black and white but you can pretty much divide 95% of the config statements without much thinking. The other 5% can be a bit gray, but it just requires discussion.</span><br style="font-style: italic; color: rgb(51, 51, 255);"><br style="font-style: italic; color: rgb(51, 51, 255);"><span style="font-style: italic; color: rgb(51, 51, 255);">The voice team will have to recognize that this is the future of voice in your organization and step up to the challenge. </span><br><br><br>Thanks for your input. <br><br>-Brandon<br><br>
</div></body></html>