One thing I learned today on this last topic that I wanted to make sure I stated correctly. On my last post ( http://checkpointfun.blogspot.com/2012/01/packet-debugging-through-firewall.html ), I had a packet pinging through the firewall out into the Internet. However, what I want to make sure Im clear on is the meaning of the letters I mentioned before in the packet capture (i,I,O,o). I think this will be very important in troubleshooting, as it has been to me so far. So, here is an example:
i = "incoming" to the interface mentioned in the capture
I= "incoming" into the OS kernal
O= "outgoing" from the OS kernal
o= "outgoing" from the interface mentioned in the capture
So, lets look at this packet capture below, from the start (including the command):
fw monitor -e "accept src=29.27.7.2 or dst=29.27.7.2;"
monitor: getting filter (from command line)
monitor: compiling
monitorfilter:
Compiled OK.
monitor: loading
monitor: monitoring (control-C to stop)
External:o[154]: 17.27.14.13 -> 29.27.7.2 (UDP) len=154 id=0 <--------- "o" outgoing from the OS kernal
UDP: 48900 -> 1812
External:O[154]: 17.27.14.13 -> 29.27.7.2 (UDP) len=154 id=0 <--------- "O" outgoing from the outside interface from the IP of 17.27.14.13 to 29.27.7.2
UDP: 48900 -> 1812
External:i[207]: 29.27.7.2 -> 17.27.14.13 (UDP) len=207 id=10621 <--------- "i" incoming into the outside interface from the IP of 29.27.7.2 to 17.27.14.13
UDP: 1812 -> 48900
External:I[207]: 29.27.7.2 -> 17.27.14.13 (UDP) len=207 id=10621 <--------- "I" incoming into the OS kernal
UDP: 1812 -> 48900
I just wanted to make sure I made clear the meanings of the letters i, I, O, and o. Thanks.
Tuesday, January 31, 2012
Sunday, January 22, 2012
How To Configure A Static NAT Translation On A Cisco IOS Router
Have you ever needed to get to a web server or email server from the outside of your network, and you didn't have a firewall in place, but you had IOS router instead? I have seen where there have been IOS routers in place for access to the public network instead of an ASA. Nothing wrong with that if the proper security is in place, but I wanted to cover how you would access a server from the outside if you needed to. You would do this with a static NAT translation and the proper security ACL. Lets work with an www server.
First, make sure a couple of things are in place:
interface GigabitEthernet0/0
description -------- To Internet ----------------
ip address 70.70.70.82 255.255.255.240
ip nat outside <----------- Make sure you have your
ip access-group 110 in <---------- Make sure you have proper security
Lets look at the ACL:
access-list 110 permit tcp any 70.70.70.83 eq www
Lets put our static nat translation in. Ltes say our www server is 10.10.10.4 on the inside. Our public is 70.70.70.83. Here is the command:
ip nat inside source static 10.10.10.4 70.70.70.83
First, make sure a couple of things are in place:
interface GigabitEthernet0/0
description -------- To Internet ----------------
ip address 70.70.70.82 255.255.255.240
ip nat outside <----------- Make sure you have your
ip access-group 110 in <---------- Make sure you have proper security
Lets look at the ACL:
access-list 110 permit tcp any 70.70.70.83 eq www
Lets put our static nat translation in. Ltes say our www server is 10.10.10.4 on the inside. Our public is 70.70.70.83. Here is the command:
ip nat inside source static 10.10.10.4 70.70.70.83
Saturday, January 21, 2012
ShoreTel and the Algo 8180 SIP ringer.
Anyone heard of the Algo 8180 SIP ringer? Well, its kind of a neat device if you have a hard time hearing a phone ringing. In my example, I have a manufacturing facility where there is one phone in particular that has a lot of noise around it. So, when a call comes, its very difficult for them to hear the phone. With the Algo 8180 SIP device, it will ring an electronic tone out pretty loudly so that they can hear when the phone rings. Its pretty nifty. By the way, Im integrating this with the ShoreTel phone system, version 12.1.
So, here is what I did to set this up. I put the Algo 8180 on the voice network and it got a DHCP address. I found that address and then I put a static IP address on it through the web interface. Its pretty easy. You find the network area and set it to be DHCP off. Then you are allowed to put in the static IP, subnet mask and gateway. Save that and it will want to reboot. You can go ahead and put the SIP settings in also. See a screenshot of the web interface of the Algo 8180. Im somewhat of a fan of this device in this environment.
So, on the ShoreTel side, here is what I did. Keep in mind that there are several ways to do this.
First, I went to IP phones and registered the SIP device. Once you enter that info and save it, you can go to the bottom of the page and see if it registered. If it did, great. Go to the users page and add a user. Put in the extension you want it to be. Make it an extension only, no mailbox. Go to the IP phones and select the SIP phone you just got registered. Then go the bottom and put in the SIP authentication. Oh, make sure the username matches the same as what you put as the name of the Algo 8180. I used "sipalerter". Next, go and create a hunt group. Put in the extension of the Algo 8180 and the phone you want it to ring with. If the user extension was originally 6000, then I made the hunt group 6000 and gave the phone a different extension. So, the Algo and the phone on the manufacturing floor are in the hunt group. Make sure you make it ring "simultaneous", so that bot ring at the same time.
That is all you have to do. Pretty simple.
So, here is what I did to set this up. I put the Algo 8180 on the voice network and it got a DHCP address. I found that address and then I put a static IP address on it through the web interface. Its pretty easy. You find the network area and set it to be DHCP off. Then you are allowed to put in the static IP, subnet mask and gateway. Save that and it will want to reboot. You can go ahead and put the SIP settings in also. See a screenshot of the web interface of the Algo 8180. Im somewhat of a fan of this device in this environment.
First, I went to IP phones and registered the SIP device. Once you enter that info and save it, you can go to the bottom of the page and see if it registered. If it did, great. Go to the users page and add a user. Put in the extension you want it to be. Make it an extension only, no mailbox. Go to the IP phones and select the SIP phone you just got registered. Then go the bottom and put in the SIP authentication. Oh, make sure the username matches the same as what you put as the name of the Algo 8180. I used "sipalerter". Next, go and create a hunt group. Put in the extension of the Algo 8180 and the phone you want it to ring with. If the user extension was originally 6000, then I made the hunt group 6000 and gave the phone a different extension. So, the Algo and the phone on the manufacturing floor are in the hunt group. Make sure you make it ring "simultaneous", so that bot ring at the same time.
That is all you have to do. Pretty simple.
Thursday, January 19, 2012
Check Point: fw monitor - How To Debug Packets Through The Firewall In CLI
I was on a TAC call today with Check Point, and "I" was troubleshooting a RADIUS issue while "TAC" was troubleshooting a firewall rule issue. Check Point TAC's first line of support is terrible, but I digress. I did, however, learn something interesting today about debugs. The TAC guy was trying to see, in CLI, if packets were actually getting through the firewall. So, he ran this command in expert mode:
[Expert@VPN1]# fw monitor -e "accept src=209.217.70.2 or dst=209.217.70.2;"
Now, here is what was interesting. We ran a ping from my switch in the inside of the network, behind the firewall, and got these results in the CLI (shortened, but you get the idea):
monitor: getting filter (from command line)
monitor: compiling
monitorfilter:
Compiled OK.
monitor: loading
monitor: monitoring (control-C to stop)
[fw_0] Lan1:i[100]: 10.50.1.254 -> 209.217.70.2 (ICMP) len=100 id=363
ICMP: type=8 code=0 echo request id=1189 seq=8192
[fw_0] Lan1:I[100]: 10.50.1.254 -> 209.217.70.2 (ICMP) len=100 id=363
ICMP: type=8 code=0 echo request id=1189 seq=8192
[fw_0] Lan5:o[100]: 10.50.1.254 -> 209.217.70.2 (ICMP) len=100 id=363
ICMP: type=8 code=0 echo request id=1189 seq=8192
[fw_0] Lan5:O[100]: 10.50.1.254 -> 209.217.70.2 (ICMP) len=100 id=363
ICMP: type=8 code=0 echo request id=1189 seq=8192
[fw_0] Lan1:i[100]: 10.50.1.254 -> 209.217.70.2 (ICMP) len=100 id=364
ICMP: type=8 code=0 echo request id=1190 seq=8192
[fw_0] Lan1:I[100]: 10.50.1.254 -> 209.217.70.2 (ICMP) len=100 id=364
So, I asked what some of this means, and I found that there is some really good troubleshooting techniques in this. Here is what was explained to me:
Pretty cool stuff.
[Expert@VPN1]# fw monitor -e "accept src=209.217.70.2 or dst=209.217.70.2;"
Now, here is what was interesting. We ran a ping from my switch in the inside of the network, behind the firewall, and got these results in the CLI (shortened, but you get the idea):
monitor: getting filter (from command line)
monitor: compiling
monitorfilter:
Compiled OK.
monitor: loading
monitor: monitoring (control-C to stop)
[fw_0] Lan1:i[100]: 10.50.1.254 -> 209.217.70.2 (ICMP) len=100 id=363
ICMP: type=8 code=0 echo request id=1189 seq=8192
[fw_0] Lan1:I[100]: 10.50.1.254 -> 209.217.70.2 (ICMP) len=100 id=363
ICMP: type=8 code=0 echo request id=1189 seq=8192
[fw_0] Lan5:o[100]: 10.50.1.254 -> 209.217.70.2 (ICMP) len=100 id=363
ICMP: type=8 code=0 echo request id=1189 seq=8192
[fw_0] Lan5:O[100]: 10.50.1.254 -> 209.217.70.2 (ICMP) len=100 id=363
ICMP: type=8 code=0 echo request id=1189 seq=8192
[fw_0] Lan1:i[100]: 10.50.1.254 -> 209.217.70.2 (ICMP) len=100 id=364
ICMP: type=8 code=0 echo request id=1190 seq=8192
[fw_0] Lan1:I[100]: 10.50.1.254 -> 209.217.70.2 (ICMP) len=100 id=364
So, I asked what some of this means, and I found that there is some really good troubleshooting techniques in this. Here is what was explained to me:
Check Point: Load on Module failed - failed to load Security Policy
I have been working on this issue for some time now, and today, after escalating this to someone higher in Check Point TAC, we finally got some resolution to this. We have a pair of clustered Check Point 5075 appliances, with a distributed management station. We started out running R75.20. Everything was fine, until we added URL filtering. So, when we would push policy to the cluster, we would get the following error:
"Installation failed: Reason: Load on Module failed - failed to load Security Policy."
Now, what changed? Well, we added URL filtering. So, when we unchecked URL filtering, we can push policy. See below where I mean when we "unchecked" URL Filtering. This is added on the Properties of our clustered Check Points:
So, after some trials and pain, we finally upgraded to R75.30, to try to fix this issue. We were told by Check Point that R75.30 fixed a ton of issues. So, we were pro-active and we did the upgrade. Well, it didn't fix the issue, although according to Check Point, we did get a little further into the policy push. Im glad we did the upgrade, even though it didn't fix completely the issue. What we found was that on the "Application and URL Filtering" page, we had "URLs are defined as Regular Expression" checked. We also had in our URL List *.myspace.com that we put in. Well, it turns out that the "*" was keeping us from pushing policy. CP cant determine that the * is not a regular expression, and because of this, it wont allow you to push policy. * is a wildcard, and not an expression. When we unchecked this, we can push policy, and we still have URL Filtering capability. See below the screenshot of where Im talking about in this:
"Installation failed: Reason: Load on Module failed - failed to load Security Policy."
Now, what changed? Well, we added URL filtering. So, when we unchecked URL filtering, we can push policy. See below where I mean when we "unchecked" URL Filtering. This is added on the Properties of our clustered Check Points:
So, after some trials and pain, we finally upgraded to R75.30, to try to fix this issue. We were told by Check Point that R75.30 fixed a ton of issues. So, we were pro-active and we did the upgrade. Well, it didn't fix the issue, although according to Check Point, we did get a little further into the policy push. Im glad we did the upgrade, even though it didn't fix completely the issue. What we found was that on the "Application and URL Filtering" page, we had "URLs are defined as Regular Expression" checked. We also had in our URL List *.myspace.com that we put in. Well, it turns out that the "*" was keeping us from pushing policy. CP cant determine that the * is not a regular expression, and because of this, it wont allow you to push policy. * is a wildcard, and not an expression. When we unchecked this, we can push policy, and we still have URL Filtering capability. See below the screenshot of where Im talking about in this:
ShoreTel: What services are unavailable if you reboot the Director server?
I have often wondered what exactly is unavailable when you reboot the ShoreTel Director server during production hours. Well, here is what I have come to find is unavailable if you reboot the Director server.
1. Personal call manager will not be available.
2. New voicemail cant be left when someone calls in.
3. Workgroup users will be kicked out of the workgroup and will have to log back in when the server comes up.
4. No auto attendant will be available.
1. Personal call manager will not be available.
2. New voicemail cant be left when someone calls in.
3. Workgroup users will be kicked out of the workgroup and will have to log back in when the server comes up.
4. No auto attendant will be available.
Friday, January 13, 2012
Integration of the Valcom VIP-204 with the ShoreTel Phone System
A cheatsheet for me to have on the next integration...
Ok, this was not as easy as it seemed like it would be, but I finally got this going. Forget calling ShoreTel about this. I had two TAC guys who told me (basically) that they couldn't help me, and that integrating with the Valcom system was "UNSUPPORTED". I really cant believe that Valcom is an "unsupported" company in ShoreTel land. After all, Valcom is in almost every company Ive been to where I live. I did, however, talk with one pre-sales guy that offered some help (Thanks Tom). He didn't know how to do this exactly, but he did at least make some suggestions about the SIP part. So, with that said, here are my notes on this on how to integrate ShoreTel with the Valcom VIP-204.
CONFIGURATION OF THE VALCOM VIP-204:
On the VIP-204 PagePro Paging System:
Install the VIP-102B Solutions Setup Tool.
Device must be scanned and found first. Scan for "all devices".
Give device an static IP address. click "assign".
Device reboots.
You must now verify the device. Right click on pagepro device and click "verify device".
Window comes up, click "verify".
Move device to the vlan you want it to be in, that matches the ip address range you configured the ip address for.
Rescan "all devices" again.
I had to "update changed devices" at this point.
When the device reboots, go to System ---> Audio Groups.
Create as many Audio Groups as you need. Click OK.
Go to System ---> Audio Group Membership.
On this page, select the Audio Group in the drop down box you want, and select what ports it should be available to. Click "close".
Go to "Channels" tab. Select 1 through 4 and put in the dial code you want it to be. Leave the rest as default.
Go to "SIP" tab. Select your paging zones (1 - 8) and fill out the info. Here is what I found:
Phone Number: After you dial the ShoreTel SIP extension to access the Valcom box, you will hear a "tone" in the earpiece. You will then dial this "phone number" to select the paging zone you want to access (1 - 8). In my case here, I used 12 for tab 2.
Description:
Authentication Name: Used for authentication with the ShoreTel SIP extension.
Secret: Match this with the ShoreTel SIP extension password.
SIP Server: Match this with the ShoreGear Switch that hosts the SIP Proxy Ports. In this case, I used 172.17.10.4 (the switch ip address, NOT that of the ShoreTel Director Server.
The rest leave as is.
Pre-Announce Tone: I checked this so that I would know when to hit the code for the paging zone.
Audio Groups: Select the Audio Groups you want this dial code (phone number, 12 in this case) to access for paging.
Now, configure each SIP tab as you need to. Authentication will be the same for each one.
To save this config, go to File ---> Save. This will save to your pc.
Below is a screenshot of the VIP-102B Solutions Setup Tool interface. Its easy to use and the tool is the only way to configure the paging system.
CONFIGURATION FOR THE SHORETEL PHONE SYSTEM PIECE:
Go to the ShoreGear switch you want to be the Proxy SIP Server.
Select one "port type" as "100 SIP Proxy" in the drop down box. Make sure that in the "Built-in Capacity" on the same page, you have at lease "100 SIP Proxy Ports" in RED.
Go to Sites, and in the site with the ShoreGear switch you selected above, go to the SIP Proxy settings. Forget the "Virtual IP Address blank. Select your ShoreGear switch in Proxy Switch 1. Save it.
In Call Control ---> Options. Make sure "Realm" is set to the same thing you have in the PagePro setup.
For SIP Profiles, I used "_System", which is a system default. I didn't know what else to use, and IF you need to create one for some reason, I wouldn't know what specs to configure for it.
Go to Users and create a user. I called mine Paging. Type in the extension you want to use to access the Valcom and the sip authentication password to match that of the PagePro SIP authentication. Save this.
Go to IP Phones ---> Individual IP Phones. Select the "SIP Registration" button, and put in the info. I used:
Contact: company name
AOR: company name
Host: IP address of the pagepro sip appliance (the sip device)
User: The SIP extension you created just before this.
SIP Profile: _system
Site: Site you want this for.
Save this info. You should see the SIP phone register now down toward the bottom. See below screenshot. Make sure it registers to the ShoreGear switch you intended it to. This can cause you problems if it registers to a different ShoreGear switch.
Go back to the SIP extension user (under Users), and for the IP phone, select the SIP phone you saw down at the bottom of the page you just saw register. Actually, it should already be assigned, but make sure. For some reason, it did assign mine automatically.
Done.
You can also use the buttset to test with as a speaker IF you can not use the production test speakers to test with. This can interrupt the people in the company, which may be unwanted, so I used the buttset to test with until I knew my setup/config was right. Then I moved on to connect the speakers. It looked like this:
TROUBLESHOOTING THE SETUP:
Now, for troubleshooting. ShoreTel will not help you with this, so I have very little to offer. But, I do have SOME good info. For troubleshooting this, the main thing I did was to telnet to the PagePro SIP device and make sure it registered. Its a Linux box, but here is exactly what I did below. Notice that I have NOTES in this troubleshooting below for some help.
ON THE PAGEPRO IP SIP APPLIANCE:
telnet to the ip address of the SIP PagePro device.
THIS LOGIN BELOW IS THE DEFAULT LOGIN, GIVEN TO ME BY VALCOM:
PagePro login: root
Password: moonbase
#
#
# ps <------------- Show what processes are running
PID PORT STAT SIZE SHARED %CPU COMMAND
1 S 25K 0K 0.1 init
2 S 0K 0K 0.0 keventd
3 R 0K 0K 3.3 ksoftirqd_CPU0
4 S 0K 0K 0.0 kswapd
5 S 0K 0K 0.0 bdflush
6 S 0K 0K 0.0 kupdated
7 S 0K 0K 0.0 mtdblockd
16 S 0K 0K 0.0 jffs2_gcd_mtd2
25 S0 S 85K 0K 0.0 /bin/sh
26 S 50K 0K 0.0 /mnt/bin/inetd
44 S 178K 0K 0.0 /mnt/bin/boa
46 S 586K 0K 0.1 /mnt/bin/vipRunStp
54 S 1326K 0K 94.6 /mnt/bin/vip804 <------------ Find this process
57 S 85K 0K 0.3 /mnt/bin/telnetd
58 p0 S 85K 0K 1.2 -sh
59 p0 R 50K 0K 0.0 ps
# kill -15 54 <--------------------- Stop this process from running
# vip804 & <----------- To start the vip804 process
64
# Initializing System
initializing DHCP handling
ws1: dhcp, ws2: 0
v1Socket: 7
v2Socket: 8
v2McastControlSocket: 9
v2McastAudioSocket: 10
v2McastSetupSocket: 11, 4097
v2McaseSetupAddr: 239.1.1.2
tos: 00
tos: 00
tos: 00
initNetwork fdmax: 11
sizeof dspQueueEntry_t: 412
sizeof testentry.next: 4
calling vpResetDSP()
Entering vpResetDSP
Leaving vpResetDSP
calling vpInit()
vpInit: setting chip selects 1
cs1base address set
cs1base: 0x90000d01
cs1option address set
cs1option: 0xf0000e08
calling vpInitGlobals
vpInitGlobals: setting dspPtr
vpInitPortA()
paddr: 0014
padat: E00C
ICR1: 88000005
ISR: 9FFFFFF0
Leaving vpInterruptInit
Entering vpResetDSP
Leaving vpResetDSP
First DSP Word: AA55
Writing Patch
***** writePatch
result of writing patch: 0
tcounter: 32771
Done writing Patch
After write of 0x6060: 6060
how long did it take for the dsp to come back? : 59909
number of statusQueue entries: 0
number of statusQueue entries: 1
system ready message:
00E0
0A00
0000
0000
0001
00FA
0341
0026
1400
0401
before capabilityMsg number of statusQueue entries: 0
writeCapabilityMessage
initializing for 4 channels
after capabilityMsg number of statusQueue entries: 1
lin0gc: 2
lout0gc: 1
lin1gc: 2
lout1gc: 1
mingc: 2
spoutgc: 0
hsingc: 2
hsoutgc: 1
ConfigureGPIO()
starting monitor gpio
start monitor gpioProcess
start monitor gpioProcess
start monitor gpioProcess
start monitor gpioProcess
start monitor gpioProcess
start monitor gpioProcess
start monitor gpioProcess
start monitor gpioProcess
configure channel
configure channel
configure channel
configure channel
init channels, systemVars.numChannels == 4
opening /mnt/chan1.ini
starting to get file contents
vox: 0
unicast page not defined, assuming 0
opening /mnt/chan2.ini
starting to get file contents
vox: 0
unicast page not defined, assuming 0
opening /mnt/chan3.ini
starting to get file contents
vox: 0
unicast page not defined, assuming 0
opening /mnt/chan4.ini
starting to get file contents
vox: 0
unicast page not defined, assuming 0
sipInitNetwork: ERROR bind SIP(UDP) Channel: 1, Port: 5060 - Address already in
use
sipInitNetwork: errno: 98 (0x62), socket = 15
sipInitNetwork: ERROR bind SIP(UDP) Channel: 2, Port: 5060 - Address already in
use
sipInitNetwork: errno: 98 (0x62), socket = 16
sipInitNetwork: ERROR bind SIP(UDP) Channel: 3, Port: 5060 - Address already in
use
sipInitNetwork: errno: 98 (0x62), socket = 17
sipInitNetwork: ERROR bind SIP(UDP) Channel: 4, Port: 5060 - Address already in
use
sipInitNetwork: errno: 98 (0x62), socket = 18
sipInitNetwork: ERROR bind SIP(UDP) Channel: 5, Port: 5060 - Address already in
use
sipInitNetwork: errno: 98 (0x62), socket = 19
sipInitNetwork: ERROR bind SIP(UDP) Channel: 6, Port: 5060 - Address already in
use
sipInitNetwork: errno: 98 (0x62), socket = 20
sipInitNetwork: ERROR bind SIP(UDP) Channel: 7, Port: 5060 - Address already in
use
sipInitNetwork: errno: 98 (0x62), socket = 21
initProtocolstun: Routine entered
read 5588 bytes from /tmp/SingleChimeHigh.raw
read 10950 bytes from /tmp/DualChime.raw
how long did it take for the dsp to come back? : 0
number of statusQueue entries: 1
starting main loop number of statusQueue entries: 0
running cleanupToIdle before main
cleanupToIdle chan: 0
musicoff channel: 0
musicoff channel: 0
cleanupToIdle chan: 1
musicoff channel: 1
musicoff channel: 1
cleanupToIdle chan: 2
musicoff channel: 2
musicoff channel: 2
cleanupToIdle chan: 3
musicoff channel: 3
musicoff channel: 3
generic FD_MAX value: 0
setting 10ms timer for 48 Mhz clock
safInitQueue()
unknown DSP data: 00E0, 0000, 0004, 00FA, 0341
Xmt0: REGISTER Seq:1000 To:804@172.17.10.4:5060
sipMatchChan: Routine entered
sipMatchChan: Response type = 200
sipMatchChan: Chan=0, ws1=804@
sipProcessResponse: entered, sipCalledChannel=0, sipCallExtptr->rspCode=200
Rcv0: 200-OK For:REGISTER Seq:1000 From:804@172.17.10.4:5060 <--------------- Seeing 200-OK means it registered. THIS IS WHAT YOU ARE LOOKING FOR!!!
Xmt1: REGISTER Seq:2000 To:805@172.17.10.10:5060
Xmt1: REGISTER Seq:2001 To:805@172.17.10.10:5060
Xmt1: REGISTER Seq:2002 To:805@172.17.10.10:5060
Xmt1: REGISTER Seq:2003 To:805@172.17.10.10:5060
And that is the process I went through on this. To me, it was a little painful, but now I know how to do this. I hope this is helpful.
Ok, this was not as easy as it seemed like it would be, but I finally got this going. Forget calling ShoreTel about this. I had two TAC guys who told me (basically) that they couldn't help me, and that integrating with the Valcom system was "UNSUPPORTED". I really cant believe that Valcom is an "unsupported" company in ShoreTel land. After all, Valcom is in almost every company Ive been to where I live. I did, however, talk with one pre-sales guy that offered some help (Thanks Tom). He didn't know how to do this exactly, but he did at least make some suggestions about the SIP part. So, with that said, here are my notes on this on how to integrate ShoreTel with the Valcom VIP-204.
CONFIGURATION OF THE VALCOM VIP-204:
On the VIP-204 PagePro Paging System:
Install the VIP-102B Solutions Setup Tool.
Device must be scanned and found first. Scan for "all devices".
Give device an static IP address. click "assign".
Device reboots.
You must now verify the device. Right click on pagepro device and click "verify device".
Window comes up, click "verify".
Move device to the vlan you want it to be in, that matches the ip address range you configured the ip address for.
Rescan "all devices" again.
I had to "update changed devices" at this point.
When the device reboots, go to System ---> Audio Groups.
Create as many Audio Groups as you need. Click OK.
Go to System ---> Audio Group Membership.
On this page, select the Audio Group in the drop down box you want, and select what ports it should be available to. Click "close".
Go to "Channels" tab. Select 1 through 4 and put in the dial code you want it to be. Leave the rest as default.
Go to "SIP" tab. Select your paging zones (1 - 8) and fill out the info. Here is what I found:
Phone Number: After you dial the ShoreTel SIP extension to access the Valcom box, you will hear a "tone" in the earpiece. You will then dial this "phone number" to select the paging zone you want to access (1 - 8). In my case here, I used 12 for tab 2.
Description:
Authentication Name: Used for authentication with the ShoreTel SIP extension.
Secret: Match this with the ShoreTel SIP extension password.
SIP Server: Match this with the ShoreGear Switch that hosts the SIP Proxy Ports. In this case, I used 172.17.10.4 (the switch ip address, NOT that of the ShoreTel Director Server.
The rest leave as is.
Pre-Announce Tone: I checked this so that I would know when to hit the code for the paging zone.
Audio Groups: Select the Audio Groups you want this dial code (phone number, 12 in this case) to access for paging.
Now, configure each SIP tab as you need to. Authentication will be the same for each one.
To save this config, go to File ---> Save. This will save to your pc.
Below is a screenshot of the VIP-102B Solutions Setup Tool interface. Its easy to use and the tool is the only way to configure the paging system.
Go to the ShoreGear switch you want to be the Proxy SIP Server.
Select one "port type" as "100 SIP Proxy" in the drop down box. Make sure that in the "Built-in Capacity" on the same page, you have at lease "100 SIP Proxy Ports" in RED.
Go to Sites, and in the site with the ShoreGear switch you selected above, go to the SIP Proxy settings. Forget the "Virtual IP Address blank. Select your ShoreGear switch in Proxy Switch 1. Save it.
In Call Control ---> Options. Make sure "Realm" is set to the same thing you have in the PagePro setup.
For SIP Profiles, I used "_System", which is a system default. I didn't know what else to use, and IF you need to create one for some reason, I wouldn't know what specs to configure for it.
Go to Users and create a user. I called mine Paging. Type in the extension you want to use to access the Valcom and the sip authentication password to match that of the PagePro SIP authentication. Save this.
Go to IP Phones ---> Individual IP Phones. Select the "SIP Registration" button, and put in the info. I used:
Contact: company name
AOR: company name
Host: IP address of the pagepro sip appliance (the sip device)
User: The SIP extension you created just before this.
SIP Profile: _system
Site: Site you want this for.
Save this info. You should see the SIP phone register now down toward the bottom. See below screenshot. Make sure it registers to the ShoreGear switch you intended it to. This can cause you problems if it registers to a different ShoreGear switch.
Go back to the SIP extension user (under Users), and for the IP phone, select the SIP phone you saw down at the bottom of the page you just saw register. Actually, it should already be assigned, but make sure. For some reason, it did assign mine automatically.
Done.
FOR THE PHYSICAL CONNECTIONS:
The PagePro VIP-204 isn't hard. Its a LAN interface on the front, and 4 analog ports on the back. They are Ethernet connected, which comes with a biscuit jack, that connects to the speakers. Make sure your speakers have an external power source. Other than that, see the picture below of what this biscuit jack looks like. Notice that its the BROWN pair that goes to the audio speakers.
My buttset setting was set like this below (apparently, my focus doesn't work on my phone) :
Now, for troubleshooting. ShoreTel will not help you with this, so I have very little to offer. But, I do have SOME good info. For troubleshooting this, the main thing I did was to telnet to the PagePro SIP device and make sure it registered. Its a Linux box, but here is exactly what I did below. Notice that I have NOTES in this troubleshooting below for some help.
ON THE PAGEPRO IP SIP APPLIANCE:
telnet to the ip address of the SIP PagePro device.
THIS LOGIN BELOW IS THE DEFAULT LOGIN, GIVEN TO ME BY VALCOM:
PagePro login: root
Password: moonbase
#
#
# ps <------------- Show what processes are running
PID PORT STAT SIZE SHARED %CPU COMMAND
1 S 25K 0K 0.1 init
2 S 0K 0K 0.0 keventd
3 R 0K 0K 3.3 ksoftirqd_CPU0
4 S 0K 0K 0.0 kswapd
5 S 0K 0K 0.0 bdflush
6 S 0K 0K 0.0 kupdated
7 S 0K 0K 0.0 mtdblockd
16 S 0K 0K 0.0 jffs2_gcd_mtd2
25 S0 S 85K 0K 0.0 /bin/sh
26 S 50K 0K 0.0 /mnt/bin/inetd
44 S 178K 0K 0.0 /mnt/bin/boa
46 S 586K 0K 0.1 /mnt/bin/vipRunStp
54 S 1326K 0K 94.6 /mnt/bin/vip804 <------------ Find this process
57 S 85K 0K 0.3 /mnt/bin/telnetd
58 p0 S 85K 0K 1.2 -sh
59 p0 R 50K 0K 0.0 ps
# kill -15 54 <--------------------- Stop this process from running
# vip804 & <----------- To start the vip804 process
64
# Initializing System
initializing DHCP handling
ws1: dhcp, ws2: 0
v1Socket: 7
v2Socket: 8
v2McastControlSocket: 9
v2McastAudioSocket: 10
v2McastSetupSocket: 11, 4097
v2McaseSetupAddr: 239.1.1.2
tos: 00
tos: 00
tos: 00
initNetwork fdmax: 11
sizeof dspQueueEntry_t: 412
sizeof testentry.next: 4
calling vpResetDSP()
Entering vpResetDSP
Leaving vpResetDSP
calling vpInit()
vpInit: setting chip selects 1
cs1base address set
cs1base: 0x90000d01
cs1option address set
cs1option: 0xf0000e08
calling vpInitGlobals
vpInitGlobals: setting dspPtr
vpInitPortA()
paddr: 0014
padat: E00C
ICR1: 88000005
ISR: 9FFFFFF0
Leaving vpInterruptInit
Entering vpResetDSP
Leaving vpResetDSP
First DSP Word: AA55
Writing Patch
***** writePatch
result of writing patch: 0
tcounter: 32771
Done writing Patch
After write of 0x6060: 6060
how long did it take for the dsp to come back? : 59909
number of statusQueue entries: 0
number of statusQueue entries: 1
system ready message:
00E0
0A00
0000
0000
0001
00FA
0341
0026
1400
0401
before capabilityMsg number of statusQueue entries: 0
writeCapabilityMessage
initializing for 4 channels
after capabilityMsg number of statusQueue entries: 1
lin0gc: 2
lout0gc: 1
lin1gc: 2
lout1gc: 1
mingc: 2
spoutgc: 0
hsingc: 2
hsoutgc: 1
ConfigureGPIO()
starting monitor gpio
start monitor gpioProcess
start monitor gpioProcess
start monitor gpioProcess
start monitor gpioProcess
start monitor gpioProcess
start monitor gpioProcess
start monitor gpioProcess
start monitor gpioProcess
configure channel
configure channel
configure channel
configure channel
init channels, systemVars.numChannels == 4
opening /mnt/chan1.ini
starting to get file contents
vox: 0
unicast page not defined, assuming 0
opening /mnt/chan2.ini
starting to get file contents
vox: 0
unicast page not defined, assuming 0
opening /mnt/chan3.ini
starting to get file contents
vox: 0
unicast page not defined, assuming 0
opening /mnt/chan4.ini
starting to get file contents
vox: 0
unicast page not defined, assuming 0
sipInitNetwork: ERROR bind SIP(UDP) Channel: 1, Port: 5060 - Address already in
use
sipInitNetwork: errno: 98 (0x62), socket = 15
sipInitNetwork: ERROR bind SIP(UDP) Channel: 2, Port: 5060 - Address already in
use
sipInitNetwork: errno: 98 (0x62), socket = 16
sipInitNetwork: ERROR bind SIP(UDP) Channel: 3, Port: 5060 - Address already in
use
sipInitNetwork: errno: 98 (0x62), socket = 17
sipInitNetwork: ERROR bind SIP(UDP) Channel: 4, Port: 5060 - Address already in
use
sipInitNetwork: errno: 98 (0x62), socket = 18
sipInitNetwork: ERROR bind SIP(UDP) Channel: 5, Port: 5060 - Address already in
use
sipInitNetwork: errno: 98 (0x62), socket = 19
sipInitNetwork: ERROR bind SIP(UDP) Channel: 6, Port: 5060 - Address already in
use
sipInitNetwork: errno: 98 (0x62), socket = 20
sipInitNetwork: ERROR bind SIP(UDP) Channel: 7, Port: 5060 - Address already in
use
sipInitNetwork: errno: 98 (0x62), socket = 21
initProtocolstun: Routine entered
read 5588 bytes from /tmp/SingleChimeHigh.raw
read 10950 bytes from /tmp/DualChime.raw
how long did it take for the dsp to come back? : 0
number of statusQueue entries: 1
starting main loop number of statusQueue entries: 0
running cleanupToIdle before main
cleanupToIdle chan: 0
musicoff channel: 0
musicoff channel: 0
cleanupToIdle chan: 1
musicoff channel: 1
musicoff channel: 1
cleanupToIdle chan: 2
musicoff channel: 2
musicoff channel: 2
cleanupToIdle chan: 3
musicoff channel: 3
musicoff channel: 3
generic FD_MAX value: 0
setting 10ms timer for 48 Mhz clock
safInitQueue()
unknown DSP data: 00E0, 0000, 0004, 00FA, 0341
Xmt0: REGISTER Seq:1000 To:804@172.17.10.4:5060
sipMatchChan: Routine entered
sipMatchChan: Response type = 200
sipMatchChan: Chan=0, ws1=804@
sipProcessResponse: entered, sipCalledChannel=0, sipCallExtptr->rspCode=200
Rcv0: 200-OK For:REGISTER Seq:1000 From:804@172.17.10.4:5060 <--------------- Seeing 200-OK means it registered. THIS IS WHAT YOU ARE LOOKING FOR!!!
Xmt1: REGISTER Seq:2000 To:805@172.17.10.10:5060
Xmt1: REGISTER Seq:2001 To:805@172.17.10.10:5060
Xmt1: REGISTER Seq:2002 To:805@172.17.10.10:5060
Xmt1: REGISTER Seq:2003 To:805@172.17.10.10:5060
And that is the process I went through on this. To me, it was a little painful, but now I know how to do this. I hope this is helpful.
Monday, January 9, 2012
Operator solutions for ShoreTel
I have a setup where I have two operators receiving calls for mid sized company. The upper management wants all calls to be answered by a person, instead of an AA. Doesn't make sense to me, but hey, not my company. So, I have them setup as a hunt group. Two operators, in a hunt group, and they have IP 230s. Not my call, but that's what they choose to get. So, they complain that each operator now can not get more than two calls. They want each operator to get 6 calls each. Wow, I still vote for the AA.
So, in trying to figure out what to do with this, I call up TAC. The TAC guy says to use a BCA. I tried that and still, a similar issue. I could only get one call to ring in on the individual operator in communicator. Not sure why that was. I had a call stack of 8 for each operator. However, when I made the second call into the operator, it wouldn't show up at the operator communicator, nor on her phone. So, I went back to the hunt group. Ugh.
So, what are my other options? I could get a phone with more line appearances. That might be the option. But, if the company wants the callers to talk to a live person, how about a workgroup? Well, I think that is a decent option, if they want to have someone answer the phone. But, its going to cost them more workgroup licenses.
I like how communicator works for operators, but I still feel like the options for the operator is weak. If I have a Cisco solution in place, I can get as many calls in as I want, not only for the operator, but for any user. Maybe this will change in ShoreTel in the future, but for now, Im a little disappointed.
So, in trying to figure out what to do with this, I call up TAC. The TAC guy says to use a BCA. I tried that and still, a similar issue. I could only get one call to ring in on the individual operator in communicator. Not sure why that was. I had a call stack of 8 for each operator. However, when I made the second call into the operator, it wouldn't show up at the operator communicator, nor on her phone. So, I went back to the hunt group. Ugh.
So, what are my other options? I could get a phone with more line appearances. That might be the option. But, if the company wants the callers to talk to a live person, how about a workgroup? Well, I think that is a decent option, if they want to have someone answer the phone. But, its going to cost them more workgroup licenses.
I like how communicator works for operators, but I still feel like the options for the operator is weak. If I have a Cisco solution in place, I can get as many calls in as I want, not only for the operator, but for any user. Maybe this will change in ShoreTel in the future, but for now, Im a little disappointed.
Saturday, January 7, 2012
Integrating A Viking RC-2A Into A ShoreTel System For Unlocking A Door/Gate
I am on a ShoreTel install and I have come across the need to be able to integrate two Viking RC-2A units into the phone system. They will open the front door (which is locked all the time) by dialing digits on the phone after a call is made from the Viking unit (by pressing the call button on the box). Also, they will use this to open a gate in the back of the facility for truck drivers and employees. Same principle as the front door.
To do this, we need an ShoreGear 30, so that we can make use of trunk lines. We will tie these lines directly to the Viking unit. See the topology below. Also note that Im using ShoreTel 12.1.
In ShoreTel Director, this is real easy to setup. For the Front Door, you configure ShoreGear 30 port 1 to be a trunk port. For the Back Gate, I used port 2. Two trunk ports for two separate Viking RC-2A units. The Viking units have nothing to do with each other. Two totally separate purposes. Below is the first step, to configure the ShoreGear 30 for the proper port settings.
Next, we configure a Trunk Group for the Front Door (and the Back Gate). Make sure you put in a destination for the Inbound destination. When they push the call button the on the call box, the call has to go somewhere.
Make sure you have destinations that are valid. You dont want it going to an extension that is a mailbox only, or something odd like that.
Thanks to a post in the ShoreTel forums (ShoreTel sponsored, not the one I got banned from), I learned something that may be important. I read a post from a guy named TonyZ that talked about callerID on a trunk group. What he said makes sense to me, so I followed his advise. By the way, thank you TonyZ for your help in the forum. He says the following: "the Shoretel wants to listen for caller ID on the trunk, so it wont let the doorbox ring through immediately. So you have to disable this in the Shoretel trunk group." Well, Im happy to follow his advice, and here is what he says about how to do this:
"At the DIRECTOR login screen, hold shift+ctrl+alt and click the text that says "user id" - it should now say **support entry** in red below the login. Now just log in as normal. "
" Go to the DOORBOX trunk group, and at the very bottom there's a new field that says "custom" - click the EDIT box. In that window, type in ;1L (semicolon, the number one, capital L) - it has to be EXACT. Then save. This will stop the analog trunk group from looking for caller ID and let it ring through right away."
***NOTE*** I did this and I ran into no issues at all that I had to battle, dealing with this in particular. Again, Thanks TonyZ for your post in the forums.
Make all you physical connections, as shown similarly in the topology above. This involved 66 blocks, etc, but you get the idea in the above topology.
Now for the Viking RC-2A unit settings. For my install, this was already integrated with an Avaya system. So, I figured the settings were correct just the way they were. Here is a picture of the settings. If you cant tell for sure, dip switches 1-5 are down, and 6 and 7 are up. The three potentiometer looking things are actually settings. All three of mine are on "D". Yes, that is sunshine in the picture below. That thing is in an underground box outside.
Now, here is what happens. Ill use the back gate as an example. When someone presses the button on the call box by the gate (before entering), it rings the analog phone. Once you are on the phone, you can dial in 16 to open the gate (or the front door). The gate opens and the front door unlocks (separately of course). Guests are welcome to come in at this point. You do not have to do anything else. NOTE THIS*** You will want to know, you can not dial the Viking unit directly, that I am aware of (at this point anyway, TAC is working on this capability in my case). So, how do you initiate a command to the Viking without someone calling from the call box? Read the next paragraph. Why would you want to do this? Because if an 18 wheeler shows up a the gate, its too tall to reach down to the call box made for the height of cars. Its useful for the security guard to just pick up the phone and dial the code so as not to inconvenience the truck driver.
When the security guard wants to initiate a command to the viking unit, like opening or closing the gate, they press 807 to access the Viking unit (807 is what they had before on the Avaya). Once you have dialed in, you get a secondary dial tone. You then press a code (we did 16) on the dialpad and then press #. Hang up the phone, and in about 2 seconds, the phone rings and you pick it up and dial the code (16 to open the gate in this case).
***NOTE THIS***
Now, something that really got me on this second Viking, where I was trying to get the Back Gate to work. I had a very hard time getting this going. When I went to the outside call box and pressed the button, it never rang the phone inside at the security station. However, I knew it was working, because I could take an IP phone and dial the analog phone, and it would ring just fine. So, why wouldn't the call box ring the analog phone? Because I had punched down NOT the analog phone wrong, but the Viking unit. But, it was on the ShoreGear 30 side where I punched it down. So, if you look up the amphenol cable's pinout (which I listed in another post on this site), it shows pins 1 and 26 as blue/white, blue. Pins 2 and 27 are orange/white, orange. Makes sense to me that we would use these two for ports 1 and 2 on the ShoreGear 30. However, the ShoreGear 30 does not line up that way. See below for the pinout to port chart. For some reason, they use pins 3 and 28 for port 2. I have no idea why, but this really had me stuck for several hours until TAC pointed that out to me. Ugh.
I hope this helps.
NOTE ADDED 4/10/2013*** I ran into another RC-2A that was slightly different. I posted about that install here.
To do this, we need an ShoreGear 30, so that we can make use of trunk lines. We will tie these lines directly to the Viking unit. See the topology below. Also note that Im using ShoreTel 12.1.
In ShoreTel Director, this is real easy to setup. For the Front Door, you configure ShoreGear 30 port 1 to be a trunk port. For the Back Gate, I used port 2. Two trunk ports for two separate Viking RC-2A units. The Viking units have nothing to do with each other. Two totally separate purposes. Below is the first step, to configure the ShoreGear 30 for the proper port settings.
Next, we configure a Trunk Group for the Front Door (and the Back Gate). Make sure you put in a destination for the Inbound destination. When they push the call button the on the call box, the call has to go somewhere.
Thanks to a post in the ShoreTel forums (ShoreTel sponsored, not the one I got banned from), I learned something that may be important. I read a post from a guy named TonyZ that talked about callerID on a trunk group. What he said makes sense to me, so I followed his advise. By the way, thank you TonyZ for your help in the forum. He says the following: "the Shoretel wants to listen for caller ID on the trunk, so it wont let the doorbox ring through immediately. So you have to disable this in the Shoretel trunk group." Well, Im happy to follow his advice, and here is what he says about how to do this:
"At the DIRECTOR login screen, hold shift+ctrl+alt and click the text that says "user id" - it should now say **support entry** in red below the login. Now just log in as normal. "
" Go to the DOORBOX trunk group, and at the very bottom there's a new field that says "custom" - click the EDIT box. In that window, type in ;1L (semicolon, the number one, capital L) - it has to be EXACT. Then save. This will stop the analog trunk group from looking for caller ID and let it ring through right away."
***NOTE*** I did this and I ran into no issues at all that I had to battle, dealing with this in particular. Again, Thanks TonyZ for your post in the forums.
Make all you physical connections, as shown similarly in the topology above. This involved 66 blocks, etc, but you get the idea in the above topology.
Now for the Viking RC-2A unit settings. For my install, this was already integrated with an Avaya system. So, I figured the settings were correct just the way they were. Here is a picture of the settings. If you cant tell for sure, dip switches 1-5 are down, and 6 and 7 are up. The three potentiometer looking things are actually settings. All three of mine are on "D". Yes, that is sunshine in the picture below. That thing is in an underground box outside.
Now, here is what happens. Ill use the back gate as an example. When someone presses the button on the call box by the gate (before entering), it rings the analog phone. Once you are on the phone, you can dial in 16 to open the gate (or the front door). The gate opens and the front door unlocks (separately of course). Guests are welcome to come in at this point. You do not have to do anything else. NOTE THIS*** You will want to know, you can not dial the Viking unit directly, that I am aware of (at this point anyway, TAC is working on this capability in my case). So, how do you initiate a command to the Viking without someone calling from the call box? Read the next paragraph. Why would you want to do this? Because if an 18 wheeler shows up a the gate, its too tall to reach down to the call box made for the height of cars. Its useful for the security guard to just pick up the phone and dial the code so as not to inconvenience the truck driver.
When the security guard wants to initiate a command to the viking unit, like opening or closing the gate, they press 807 to access the Viking unit (807 is what they had before on the Avaya). Once you have dialed in, you get a secondary dial tone. You then press a code (we did 16) on the dialpad and then press #. Hang up the phone, and in about 2 seconds, the phone rings and you pick it up and dial the code (16 to open the gate in this case).
***NOTE THIS***
Now, something that really got me on this second Viking, where I was trying to get the Back Gate to work. I had a very hard time getting this going. When I went to the outside call box and pressed the button, it never rang the phone inside at the security station. However, I knew it was working, because I could take an IP phone and dial the analog phone, and it would ring just fine. So, why wouldn't the call box ring the analog phone? Because I had punched down NOT the analog phone wrong, but the Viking unit. But, it was on the ShoreGear 30 side where I punched it down. So, if you look up the amphenol cable's pinout (which I listed in another post on this site), it shows pins 1 and 26 as blue/white, blue. Pins 2 and 27 are orange/white, orange. Makes sense to me that we would use these two for ports 1 and 2 on the ShoreGear 30. However, the ShoreGear 30 does not line up that way. See below for the pinout to port chart. For some reason, they use pins 3 and 28 for port 2. I have no idea why, but this really had me stuck for several hours until TAC pointed that out to me. Ugh.
I hope this helps.
NOTE ADDED 4/10/2013*** I ran into another RC-2A that was slightly different. I posted about that install here.
Friday, January 6, 2012
Cisco 3750 HSRP: with per VLAN load sharing instead of just HA (High Availability)
I did a pretty cool little thing today with two 3750 Cisco switches. I have a customer that has two 3750s setup as a redundant core. If one fails, the other takes over. Its called HSRP, and it works pretty well. However, I noticed that on the primary (active) 3750, the cpu utilization was really at various times. So, I thought I would separate the traffic as best as I could so that the primary took most of the vlans and the secondary took one vlan in particular (vlan 102). I happened to know for sure that vlan 102 had a ton of traffic on it, so I made my decision based on that. So, instead of the primary taking all the heat while the secondary sat idle waiting on a failed primary, I decided to load share them. Here is what the config looks like:
*****PRIMARY SWITCH*****:
interface Vlan10 <----------- Active vlan on Primary
description 1st floor
ip address 10.232.10.250 255.255.255.0 <----------- Real IP address of vlan interface
no ip redirects
standby 10 ip 10.232.10.254 <------------ Virtual IP address shared between Primary and Secondary for vlan 10
standby 10 timers 3 7 <----------- Send hellos every 3 seconds, switch over to secondary after 7 seconds
standby 10 priority 110 <----------- Notice the priority command for vlan 10, higher than the default of the secondary switch
interface Vlan102 <----------- Not Active vlan on Primary
description 2nd floor
ip address 10.10.2.254 255.255.252.0 <----------- Real IP address of vlan interface
standby 102 ip 10.10.2.1 <------------ Virtual IP address shared between Primary and Secondary for vlan 102
*****SECONDARY SWITCH*****:
interface Vlan10 <----------- Not Active vlan on Secondary
description 1st floor
ip address 10.232.10.251 255.255.255.0 <----------- Real IP address of vlan interface
no ip redirects
standby 10 ip 10.232.10.254 <------------ Virtual IP address shared between Primary and Secondary for vlan 10
standby 10 timers 3 7
interface Vlan102 <----------- Active vlan on Secondary
description 2nd floor
ip address 10.10.2.253 255.255.252.0 <----------- Real IP address of vlan interface
standby 102 ip 10.10.2.1 <------------ Virtual IP address shared between Primary and Secondary for vlan 102
standby 102 timers 3 7 <----------- Send hellos every 3 seconds, switch over to secondary after 7 seconds
standby 102 priority 120 <----------- Notice the priority command for vlan 102, higher than the default of the primary switch
I like this. So lets look at the "show standby brief" command for both:
*****PRIMARY SWITCH*****
pricoreswitch#sho stand bri
P indicates configured to preempt.
|
Interface Grp Prio P State Active Standby Virtual IP
Vl10 10 110 P Active local 10.232.10.251 10.232.10.254 <-------------- Active
Vl102 102 100 Standby 10.10.2.253 local 10.10.2.1 <-------------- NOT Active
*****SECONDARY SWITCH*****
seccoreswitch#sh standby bri
P indicates configured to preempt.
|
Interface Grp Prio P State Active Standby Virtual IP
Vl10 10 100 Standby 10.232.10.250 local 10.232.10.254 <-------------- NOT Active
Vl102 102 120 P Active local 10.10.2.254 10.10.2.1 <-------------- Active
Now, we have a "load sharing" scenario between the two HSRP 3750 switches. Very cool.
Oh wait, what happens if I power down a switch? Well, here is what happens when I powered down the secondary 3750:
*****PRIMARY SWITCH*****
pricoreswitch#sho stand bri
P indicates configured to preempt.
|
Interface Grp Prio P State Active Standby Virtual IP
Vl10 10 110 P Active local 10.232.10.251 10.232.10.254 <-------------- Active
Vl102 102 120 P Active local 10.10.2.253 10.10.2.1 <-------------- Active
Secondary was powered off, so no readings there. Just like a real failure.
*****PRIMARY SWITCH*****:
interface Vlan10 <----------- Active vlan on Primary
description 1st floor
ip address 10.232.10.250 255.255.255.0 <----------- Real IP address of vlan interface
no ip redirects
standby 10 ip 10.232.10.254 <------------ Virtual IP address shared between Primary and Secondary for vlan 10
standby 10 timers 3 7 <----------- Send hellos every 3 seconds, switch over to secondary after 7 seconds
standby 10 priority 110 <----------- Notice the priority command for vlan 10, higher than the default of the secondary switch
interface Vlan102 <----------- Not Active vlan on Primary
description 2nd floor
ip address 10.10.2.254 255.255.252.0 <----------- Real IP address of vlan interface
standby 102 ip 10.10.2.1 <------------ Virtual IP address shared between Primary and Secondary for vlan 102
*****SECONDARY SWITCH*****:
interface Vlan10 <----------- Not Active vlan on Secondary
description 1st floor
ip address 10.232.10.251 255.255.255.0 <----------- Real IP address of vlan interface
no ip redirects
standby 10 ip 10.232.10.254 <------------ Virtual IP address shared between Primary and Secondary for vlan 10
standby 10 timers 3 7
interface Vlan102 <----------- Active vlan on Secondary
description 2nd floor
ip address 10.10.2.253 255.255.252.0 <----------- Real IP address of vlan interface
standby 102 ip 10.10.2.1 <------------ Virtual IP address shared between Primary and Secondary for vlan 102
standby 102 timers 3 7 <----------- Send hellos every 3 seconds, switch over to secondary after 7 seconds
standby 102 priority 120 <----------- Notice the priority command for vlan 102, higher than the default of the primary switch
I like this. So lets look at the "show standby brief" command for both:
*****PRIMARY SWITCH*****
pricoreswitch#sho stand bri
P indicates configured to preempt.
|
Interface Grp Prio P State Active Standby Virtual IP
Vl10 10 110 P Active local 10.232.10.251 10.232.10.254 <-------------- Active
Vl102 102 100 Standby 10.10.2.253 local 10.10.2.1 <-------------- NOT Active
*****SECONDARY SWITCH*****
seccoreswitch#sh standby bri
P indicates configured to preempt.
|
Interface Grp Prio P State Active Standby Virtual IP
Vl10 10 100 Standby 10.232.10.250 local 10.232.10.254 <-------------- NOT Active
Vl102 102 120 P Active local 10.10.2.254 10.10.2.1 <-------------- Active
Now, we have a "load sharing" scenario between the two HSRP 3750 switches. Very cool.
Oh wait, what happens if I power down a switch? Well, here is what happens when I powered down the secondary 3750:
*****PRIMARY SWITCH*****
pricoreswitch#sho stand bri
P indicates configured to preempt.
|
Interface Grp Prio P State Active Standby Virtual IP
Vl10 10 110 P Active local 10.232.10.251 10.232.10.254 <-------------- Active
Vl102 102 120 P Active local 10.10.2.253 10.10.2.1 <-------------- Active
Secondary was powered off, so no readings there. Just like a real failure.
Subscribe to:
Posts (Atom)