Sometimes running cable is just part of the network guy's job. Im pulling up floor tiles to get the cable where it needs to go. This was a tight job to get to. I had to break off pieces of a pallet and rubber band them together to get the cable where I needed it to go. Sometimes you just have to do what you have to do to get the job done.
This is the retired Shane Killen personal blog, an IT technical blog about configs and topics related to the Network and Security Engineer working with Cisco, Brocade, Check Point, and Palo Alto and Sonicwall. I hope this blog serves you well. -- May The Lord bless you and keep you. May He shine His face upon you, and bring you peace.
Friday, February 28, 2014
Thursday, February 27, 2014
Cisco ASA: Remote-Access VPN Problem - Two Default Gateways On The Client
I was asked to come in and work on this remote-access VPN problem for a customer the other day. They told me that when the Cisco ASA was configured, they never did get the remote-access working right. The problem was not Phase I or Phase II. That worked great. However, they just couldn't get to anything inside the network, like their servers, etc. So what was the problem?
Well, I have seen this sort of thing before. I was thinking that it was probably the nonat rule or the interesting traffic ACL didn't look right. Not much else really to look for in a VPN. But at first glance, things did look ok with those ACLs. Until I looked at my own routing table. I noticed that I had two default routes on my laptop when VPN'ed into that firewall. Why would that be? Here is why:
This is what the ACL looked like in the config before I got to it:
access-list nonat extended permit ip any 192.168.120.0 255.255.255.0
access-list remote_access extended permit ip any 192.168.120.0 255.255.255.0
Notice in the above ACL, that the source is an "any", meaning anything ip scheme. For remote-access VPNs, that basically equates to a default route, which explains why my routing table (on my laptop) looks like this below.
So, what do you do to fix this? You be specific in the ACL. Make sure that the source (in this case) is the network IP scheme of the inside of the network (192.168.1.X/24). It will look like this ACL below:
access-list nonat extended permit ip 192.168.1.0 255.255.255.0 192.168.120.0 255.255.255.0
access-list remote_access extended permit ip 192.168.1.0 255.255.255.0 192.168.120.0 255.255.255.0
Now, when I VPN in, my routing table looks correct:
You have to remember, for remote-access users, the 'source' address is really going to modify the routing table on the remote-access client laptop, along with telling the firewall what is allowed back across to the client.
Well, I have seen this sort of thing before. I was thinking that it was probably the nonat rule or the interesting traffic ACL didn't look right. Not much else really to look for in a VPN. But at first glance, things did look ok with those ACLs. Until I looked at my own routing table. I noticed that I had two default routes on my laptop when VPN'ed into that firewall. Why would that be? Here is why:
This is what the ACL looked like in the config before I got to it:
access-list nonat extended permit ip any 192.168.120.0 255.255.255.0
access-list remote_access extended permit ip any 192.168.120.0 255.255.255.0
Notice in the above ACL, that the source is an "any", meaning anything ip scheme. For remote-access VPNs, that basically equates to a default route, which explains why my routing table (on my laptop) looks like this below.
So, what do you do to fix this? You be specific in the ACL. Make sure that the source (in this case) is the network IP scheme of the inside of the network (192.168.1.X/24). It will look like this ACL below:
access-list nonat extended permit ip 192.168.1.0 255.255.255.0 192.168.120.0 255.255.255.0
access-list remote_access extended permit ip 192.168.1.0 255.255.255.0 192.168.120.0 255.255.255.0
Now, when I VPN in, my routing table looks correct:
You have to remember, for remote-access users, the 'source' address is really going to modify the routing table on the remote-access client laptop, along with telling the firewall what is allowed back across to the client.
Tuesday, February 25, 2014
Palo Alto: Useful CLI Commands
I got this document from a friend of mine, but Im sure its on Palo Alto's site. Here is a list of useful CLI commands. I thought it was worth posting here for reference if anyone needs it.
General system health
show system info –provides the system’s management IP, serial number and code version
show system statistics – shows the real time throughput on the device
show system software status – shows whether various system processes are running
show jobs processed – used to see when commits, downloads, upgrades, etc. are completed
show system disk--space-- show percent usage of disk partitions
show system logdb--quota – shows the maximum log file sizes
debug dataplane internal vif link – show management interface (eth0) counters
To monitor CPUs
show system resources -- shows processes running in the management plane similar to “top” command
show running resource--monitor – used to see the resource utilization in the data plane, such as dataplane CPU utilization
less mp--log mp--monitor.log – Every 15 minutes the system runs a script to monitor management plane resource usage, output is stored in this file.
less dp--log dp--monitor.log -- Every 15 minutes the system runs a script to monitor dataplane resource usage, output is stored in this file.
General dropped packet troubleshooting
ping source <IP_addr_src_int> host <IP_addr_host> -- allows to ping from the specified FW source interface
ping host <IP> -- ping from the MGT interface
show session all | match – used to show specific sessions in the session table. You can
enter any text after the word match. A good example would be a source or destination IP or an application
show session all | filter destination <IP> dest--port <port>-- shows all sessions going to a particular dest IP and port
show session id – shows the specifics behind a particular session by entering the ID number after the word "id”
show counter interface – shows interface counters
show counter global | match drop – used to troubleshoot dropped packets
show counter global delta yes | match [ drop | error | frag ] – show counter changes
since last time ran this command, filter on particular keyword
NAT
show running nat--policy-- shows current NAT policy table
show running ippool-- use to see if NAT pool leak
test nat--policy--match – simulate traffic going through the device, what NAT policy will it match?
Routing
show routing route – displays the routing table
test routing fib--lookup virtual--router <VR_name> ip <IP_addr_trying_reach> -- finds which route in the routing table will be used to reach the IP address that you are testing
Policies
show running security--policy – shows the current policy set
test security--policy--match from trust to untrust destination <IP>-- simulate a packet going through the system, which policy will it match?
PAN Agent
show user pan--agent statistics – used to see if the agent is connected and operational. Status should be connected OK and you should see numbers under users, groups and IPs.
show pan--agent user--IDs -- used to see if the FW has pulled groups from the PANAgent
show user ip--user--mapping – used to see IP to username mappings on the FW
clear user--cache all – clears the user--ID cache
debug device--server reset pan--agent <name> -- reset the firewall’s connection to the specified agent
URL
test url <url or IP> – used to test the categorization of a URL on the FW
tail follow yes mp--log pan_bc_download.log – shows the BrightCloud database update logs
request url--filtering download status – shows the status of the database download (essentially the very last line from the pan_bc_download.log file)
debug dataplane show url--cache statistics– shows statistics on the URL cache
show counter global | match url – shows statistics on URL processing
clear url--cache – used to clear the URL cache-- cache contains 100k of the most popular URLs on this network
show log url direction equal backward-- view the URL log, most recent entries first
To test connectivity to the BrightCloud servers:
ping host service.brightcloud.com
ping host database.brightcloud.com
Log viewing / deleting1
show log [ system | traffic | threat ] direction equal backward – will take you to the end of the specified log
show log [ system | traffic | threat ] direction equal forward – will take you to beginning of the specified log
clear log [ traffic | threat | acc ] – clear everything in the specified log
Software, Content, and Licenses
To upgrade the software on the FW:
tftp import software from <IP_addr_tftp_server> file <filename>
request system software install file <filename>
request restart system
request system software [info | check | download | install ] –manipulate PANOS software from the CLI
To upgrade the content on the FW:
tftp import content from <IP_addr_tftp_server> file <filename>
request content upgrade install file <filename>
request content downgrade install previous –downgrade to the previous content version
request system private--data--reset-- to clear config and logs/reports
debug swm [ status | list | revert ] – will show possible code to install, or code that was installed. “revert” is used to revert to last running OS version without having to do a
factory reset (such as from 4.0 to back to 3.1)
request license info – shows the license installed on the device
delete license key ? – use to delete a license file if having issues and want to retrieve new licenses, use question mark to list file names, only delete the files you see fit
Config diff/force/cli format
show config diff-- compares two versions of the config
commit force-- perform a commit, even if there are errors
set cli config--output--format set-- use to view the config in “set” format from within the configure prompt (#)
IPSec
To view detailed debug information for IPSec tunneling:
1. debug ike global on debug
2. less mp--log ikemgr.log
Misc
set deviceconfig setting session tcp--reject--non--syn no – used to ignore SYN when creating sessions; confirm command took effect with show session info
set deviceconfig setting session offload no –-- makes all packets go through CPU, otherwise all fastpath packets just go through EZ chip (turns off session offload to fastpath); confirm command took effect with show session info
debug dataplane pool statistics -- this will show the different dataplane buffers and can e used to see if the system is nearing capacity in certain functionality.
General system health
show system info –provides the system’s management IP, serial number and code version
show system statistics – shows the real time throughput on the device
show system software status – shows whether various system processes are running
show jobs processed – used to see when commits, downloads, upgrades, etc. are completed
show system disk--space-- show percent usage of disk partitions
show system logdb--quota – shows the maximum log file sizes
debug dataplane internal vif link – show management interface (eth0) counters
To monitor CPUs
show system resources -- shows processes running in the management plane similar to “top” command
show running resource--monitor – used to see the resource utilization in the data plane, such as dataplane CPU utilization
less mp--log mp--monitor.log – Every 15 minutes the system runs a script to monitor management plane resource usage, output is stored in this file.
less dp--log dp--monitor.log -- Every 15 minutes the system runs a script to monitor dataplane resource usage, output is stored in this file.
General dropped packet troubleshooting
ping source <IP_addr_src_int> host <IP_addr_host> -- allows to ping from the specified FW source interface
ping host <IP> -- ping from the MGT interface
show session all | match – used to show specific sessions in the session table. You can
enter any text after the word match. A good example would be a source or destination IP or an application
show session all | filter destination <IP> dest--port <port>-- shows all sessions going to a particular dest IP and port
show session id – shows the specifics behind a particular session by entering the ID number after the word "id”
show counter interface – shows interface counters
show counter global | match drop – used to troubleshoot dropped packets
show counter global delta yes | match [ drop | error | frag ] – show counter changes
since last time ran this command, filter on particular keyword
NAT
show running nat--policy-- shows current NAT policy table
show running ippool-- use to see if NAT pool leak
test nat--policy--match – simulate traffic going through the device, what NAT policy will it match?
Routing
show routing route – displays the routing table
test routing fib--lookup virtual--router <VR_name> ip <IP_addr_trying_reach> -- finds which route in the routing table will be used to reach the IP address that you are testing
Policies
show running security--policy – shows the current policy set
test security--policy--match from trust to untrust destination <IP>-- simulate a packet going through the system, which policy will it match?
PAN Agent
show user pan--agent statistics – used to see if the agent is connected and operational. Status should be connected OK and you should see numbers under users, groups and IPs.
show pan--agent user--IDs -- used to see if the FW has pulled groups from the PANAgent
show user ip--user--mapping – used to see IP to username mappings on the FW
clear user--cache all – clears the user--ID cache
debug device--server reset pan--agent <name> -- reset the firewall’s connection to the specified agent
URL
test url <url or IP> – used to test the categorization of a URL on the FW
tail follow yes mp--log pan_bc_download.log – shows the BrightCloud database update logs
request url--filtering download status – shows the status of the database download (essentially the very last line from the pan_bc_download.log file)
debug dataplane show url--cache statistics– shows statistics on the URL cache
show counter global | match url – shows statistics on URL processing
clear url--cache – used to clear the URL cache-- cache contains 100k of the most popular URLs on this network
show log url direction equal backward-- view the URL log, most recent entries first
To test connectivity to the BrightCloud servers:
ping host service.brightcloud.com
ping host database.brightcloud.com
Log viewing / deleting1
show log [ system | traffic | threat ] direction equal backward – will take you to the end of the specified log
show log [ system | traffic | threat ] direction equal forward – will take you to beginning of the specified log
clear log [ traffic | threat | acc ] – clear everything in the specified log
Software, Content, and Licenses
To upgrade the software on the FW:
tftp import software from <IP_addr_tftp_server> file <filename>
request system software install file <filename>
request restart system
request system software [info | check | download | install ] –manipulate PANOS software from the CLI
To upgrade the content on the FW:
tftp import content from <IP_addr_tftp_server> file <filename>
request content upgrade install file <filename>
request content downgrade install previous –downgrade to the previous content version
request system private--data--reset-- to clear config and logs/reports
debug swm [ status | list | revert ] – will show possible code to install, or code that was installed. “revert” is used to revert to last running OS version without having to do a
factory reset (such as from 4.0 to back to 3.1)
request license info – shows the license installed on the device
delete license key ? – use to delete a license file if having issues and want to retrieve new licenses, use question mark to list file names, only delete the files you see fit
Config diff/force/cli format
show config diff-- compares two versions of the config
commit force-- perform a commit, even if there are errors
set cli config--output--format set-- use to view the config in “set” format from within the configure prompt (#)
IPSec
To view detailed debug information for IPSec tunneling:
1. debug ike global on debug
2. less mp--log ikemgr.log
Misc
set deviceconfig setting session tcp--reject--non--syn no – used to ignore SYN when creating sessions; confirm command took effect with show session info
set deviceconfig setting session offload no –-- makes all packets go through CPU, otherwise all fastpath packets just go through EZ chip (turns off session offload to fastpath); confirm command took effect with show session info
debug dataplane pool statistics -- this will show the different dataplane buffers and can e used to see if the system is nearing capacity in certain functionality.
Monday, February 24, 2014
66 Block Punch Downs
There are times when I have to go do a voice port for a company where they change carriers. In this case, Im moving some analog lines that belonged to AT&T to now TWTelecom. I always have to find the physical lines myself. But its usually pretty easy when looking over the wiring closet/DMARC. Just find the new TWTelecom router (the Adtran in this case) and follow the amphenol cable to the 66 block. You can usually find the existing cabling by tracing back from the phone system. Find the new block and punch down appropriately. Then test the numbers after the port.
The two yellow lines below indicate the two particular poles I need on the 66 block. The black pair is the first pair, then red, and so on.
Saturday, February 22, 2014
Cisco ASA 5505: What Is The Difference Between A Base And Security Plus License?
I recently had to get an ASA 5505 ready for a remote site. One of the requirements was to implement vlans on the ASA. When I started the config, I noticed that the ASA had a Base license on it. You can do 3 VLANs with a Base license, but routing between the two internal (or DMZ) VLANs is not possible. Its going to take a Security Plus license for that, which the customer does not have.
So, what is the difference between a Base license and a Security Plus license? Here is a screenshot of the differences, according to Cisco:
So, if you have a Base license, what do you have to do to get 3 VLANs working? See below from the Cisco documentation. This is exactly what I did:
From the Cisco documentation:
Step 2 (Optional) For the Base license, allow this interface to be the third VLAN by limiting it from initiating contact to one other VLAN using the following command:
hostname(config-if)# no forward interface vlan number
Where number specifies the VLAN ID to which this VLAN interface cannot initiate traffic.
With the Base license, you can only configure a third VLAN if you use this command to limit it.
For example, you have one VLAN assigned to the outside for Internet access, one VLAN assigned to an inside business network, and a third VLAN assigned to your home network. The home network does not need to access the business network, so you can use the no forward interface command on the home VLAN; the business network can access the home network, but the home network cannot access the business network.
If you already have two VLAN interfaces configured with a nameif command, be sure to enter the no forward interface command before the nameif command on the third interface; the adaptive security appliance does not allow three fully functioning VLAN interfaces with the Base license on the ASA 5505 adaptive security appliance.
So, what is the difference between a Base license and a Security Plus license? Here is a screenshot of the differences, according to Cisco:
So, if you have a Base license, what do you have to do to get 3 VLANs working? See below from the Cisco documentation. This is exactly what I did:
From the Cisco documentation:
Step 2 (Optional) For the Base license, allow this interface to be the third VLAN by limiting it from initiating contact to one other VLAN using the following command:
hostname(config-if)# no forward interface vlan number
Where number specifies the VLAN ID to which this VLAN interface cannot initiate traffic.
With the Base license, you can only configure a third VLAN if you use this command to limit it.
For example, you have one VLAN assigned to the outside for Internet access, one VLAN assigned to an inside business network, and a third VLAN assigned to your home network. The home network does not need to access the business network, so you can use the no forward interface command on the home VLAN; the business network can access the home network, but the home network cannot access the business network.
If you already have two VLAN interfaces configured with a nameif command, be sure to enter the no forward interface command before the nameif command on the third interface; the adaptive security appliance does not allow three fully functioning VLAN interfaces with the Base license on the ASA 5505 adaptive security appliance.
Friday, February 21, 2014
Check Point: What Is The Difference In A Snapshot/Backup/Upgrade Export (Migrate Export)/Database Revision Control
I get asked this a lot it seems, and I usually have to look it up to verify the differences. Check Point offers different ways to backup the system and for different purposes. So I thought I would cover these different methods and what they do, as described in sk54100 on Check Points site. So when you read these, Im really doing a 'cut and paste' from what Check Point has described, so as to make sure you get accurate information on the topics.
Here are the differences:
Snapshot:
The snapshot utility backs up everything, including the drivers, and is available only on SecurePlatform.
Snapshot can be used to backup both your firewall and management modules.
The disadvantages of this utility are that the generated file is very big, and can only be restored to the same device, and exactly the same state (same OS, same Check Point version, same patch level).
Backups:
The backup utility backs up your Check Point configuration and your networking/OS system parameters (such as routing), and it is only available on SecurePlatform.
The backup utility can be used to backup both your firewall and management modules.
The resulting file will be smaller than the one generated by snapshot, but still pretty big.
Backup does not include the drivers, and can be restored to different machine (as opposed to snapshot, which cannot). However, it is recommended using the backup for restore to the same machine since it includes information such as MAC addresses of the NIC interfaces. (Note: Since MAC address gets restored as well, customers should be advised prior to restoring to make a note of original MAC on the new box, so it can be changed later on.) You only can restore it to the same OS, same Check Point version and patch level.
Database Revision Control:
This utility creates a version of your current policies, object database, IPS updates, etc. It is useful for minor changes or edits that you perform in SmartDashboard. It cannot be used to restore your system in case of failure.
Migrate Export (Upgrade Export):
'upgrade_export' tool backs up all Check Point configurations, independent of hardware, OS or Check Point version, but does not include OS information.
You can use this utility to backup Check Point configuration on the management station.
If you change the Check Point version you can only go up, in other words you can upgrade not downgrade.
The file will be much smaller (depending on the size of your policy), and if the system is not running on a highly loaded CPU, you can do a backup on a live system without interruption of the services.
This utility can be used only on command line and cannot be scheduled.
Here are the differences:
Snapshot:
The snapshot utility backs up everything, including the drivers, and is available only on SecurePlatform.
Snapshot can be used to backup both your firewall and management modules.
The disadvantages of this utility are that the generated file is very big, and can only be restored to the same device, and exactly the same state (same OS, same Check Point version, same patch level).
Backups:
The backup utility backs up your Check Point configuration and your networking/OS system parameters (such as routing), and it is only available on SecurePlatform.
The backup utility can be used to backup both your firewall and management modules.
The resulting file will be smaller than the one generated by snapshot, but still pretty big.
Backup does not include the drivers, and can be restored to different machine (as opposed to snapshot, which cannot). However, it is recommended using the backup for restore to the same machine since it includes information such as MAC addresses of the NIC interfaces. (Note: Since MAC address gets restored as well, customers should be advised prior to restoring to make a note of original MAC on the new box, so it can be changed later on.) You only can restore it to the same OS, same Check Point version and patch level.
Database Revision Control:
This utility creates a version of your current policies, object database, IPS updates, etc. It is useful for minor changes or edits that you perform in SmartDashboard. It cannot be used to restore your system in case of failure.
Migrate Export (Upgrade Export):
'upgrade_export' tool backs up all Check Point configurations, independent of hardware, OS or Check Point version, but does not include OS information.
You can use this utility to backup Check Point configuration on the management station.
If you change the Check Point version you can only go up, in other words you can upgrade not downgrade.
The file will be much smaller (depending on the size of your policy), and if the system is not running on a highly loaded CPU, you can do a backup on a live system without interruption of the services.
This utility can be used only on command line and cannot be scheduled.
Routing and interface information:
This information is useful to have on hand as a reference, if you are attempting to restore a configuration especially if your gateway module has a heavy routing table.
To create a copy of your routing and interface information:
# netstat -rn > routes.txt
# ipconfig -a > ipconfig.txt
# ifconfig > ifconfig.txt
Copy of /etc/sysconfig/netconf.C
I think its good information above. With that said, here below is also what Check Point recommends for a backup schedule. I personally dont go by their schedule.
Recommended backup schedule:
Snapshot - at least once, or before major change (for example: an upgrade), during a maintenance window.
Backup - every couple of months, depending how frequently you perform changes in your network/policy. Also before every major change, during a maintenance window.
upgrade_export - every month or more often, depending on how frequently you perform changes in your network/policy. Also important before upgrade or migration. Can be run outside a maintenance window.
Thursday, February 20, 2014
ShoreTel: 'Find Me' Feature
I think ShoreTel has some good things about it, along with some things I don't like about it. But one feature one of my customers asked about today was the 'Find Me' feature. They wanted the CEO to get a call, but if he didn't answer, it should go to his receptionist. However, IF she didn't answer, the call needed to go back to the CEO's voicemail, not the receptionists voicemail. Can that be done?
Why yes it can. Its called the 'Find Me' feature. Below is where you go and what to do. In ShoreTel communicator, go to Tools --> Options --> Find Me
Why yes it can. Its called the 'Find Me' feature. Below is where you go and what to do. In ShoreTel communicator, go to Tools --> Options --> Find Me
Wednesday, February 19, 2014
Cisco ASA: Stateful Failover And Stateless (Regular) Failover Configuration And Explanations
One of the things I like about doing this blog is that it can bring up some good conversation between tech guys. One of my hopes is that 'YOU' become better by reading this blog. On that same note, "I" also become better by your comments. I had a post some time back about zero downtime for ASA upgrades that were in HA mode. (You can see that post here) After the post, I had a guy bring up that what I showed was not really zero downtime. But what it really came down to was perception of what zero downtime really is. Now that dude was right in what he said. There is a difference in a 'blip', as he said, and zero downtime (really meaning a difference in 'stateful failover' and 'regular failover'). So this past weekend on that move I was doing, one of my tasks was to get the two ASAs they had in HA mode. Well that discussion between that dude and I rang in my head when I was doing that config. And I have to say, I much appreciated it too. His comments made me better this weekend. So, with that conversation in my head, I did the configuration of stateful failover as well.
So, here are two definitions we all need to know, as defined by Cisco documentation:
Here is what the config looked like at the end on the primary unit, using version 8.0(4). (<--- Yes, Im going to do an upgrade soon on these). Gig0/2 for is the stateful link. Gig0/3 is the stateless link.
failover lan unit primary
failover lan interface failover GigabitEthernet0/3
failover replication http
failover link state GigabitEthernet0/2
failover interface ip failover 172.20.20.1 255.255.255.252 standby 172.20.20.2
failover interface ip state 172.20.30.1 255.255.255.252 standby 172.20.30.2
failover
no monitor-interface management
So, what communications are moved over the 'stateless failover' link and the 'stateful failover' link? Good question. Here is what Cisco says for both:
So, here are two definitions we all need to know, as defined by Cisco documentation:
Stateless (Regular) Failover
When a failover occurs, all active connections are dropped. Clients need to reestablish connections when the new active unit takes over.
Stateful Failover
When Stateful Failover is enabled, the active unit continually passes per-connection state information to the standby unit. After a failover occurs, the same connection information is available at the new active unit. Supported end-user applications are not required to reconnect to keep the same communication session.
Here is what the config looked like at the end on the primary unit, using version 8.0(4). (<--- Yes, Im going to do an upgrade soon on these). Gig0/2 for is the stateful link. Gig0/3 is the stateless link.
failover lan unit primary
failover lan interface failover GigabitEthernet0/3
failover replication http
failover link state GigabitEthernet0/2
failover interface ip failover 172.20.20.1 255.255.255.252 standby 172.20.20.2
failover interface ip state 172.20.30.1 255.255.255.252 standby 172.20.30.2
failover
no monitor-interface management
So, what communications are moved over the 'stateless failover' link and the 'stateful failover' link? Good question. Here is what Cisco says for both:
Failover Link
The two units in a failover pair constantly communicate over a failover link to determine the operating status of each unit. The following information is communicated over the failover link: the unit state (active or standby), hello messages (keep-alives), network link status, MAC address exchange, and configuration replication and synchronization
Stateful Link
NAT translation table, TCP connection states, UDP connection states, the ARP table, the Layer 2 bridge table (when running in transparent firewall mode), the HTTP connection states (if HTTP replication is enabled), the ISAKMP and IPSec SA table, GTP PDP connection database, and the SIP signalling sessions.
Monday, February 17, 2014
PART II: Preparing For A Physical Network Move Of A Company From One Site To Another
I thought I would write about some things that are usually encountered during a company move (from the network guy's perspective), since I just did one and its fresh on my mind. My last post dealt with some preparations, but I wanted really to make a continuation of that post. So Ill name this post part II. Part I is located here.
When your do a move, expect some long hours. Usually its over a weekend. So I wouldn't really plan anything in your personal life for that weekend at all, except being at the move. Excluding drive time (4 hours total for me), me and another one of my coworkers did 21 hours onsite for the move in two days. Most of that was on day one. Day two was more 'fixing' things that needed attention (the unexpected).
So here is a list of things that you should really keep in mind. These are things you want to prepare for before the move. Here is a list that a network guy usually will encounter.
1. DNS changes - Your email, www servers, etc probably have access from the outside world. Outsiders rely on DNS to get to you, unless they know your public IP address. Make sure you change that to your new IP address scheme IF it changes with the new circuit. Sometimes it does, sometimes it does not.
2. VPNs (site to site) - Make sure you change your site to site VPNs (on the remote end) by giving them your new IP address of your firewall. If you dont, the VPN wont come up when you move. Again, that is IF your public IP address range changes.
3. VPNs (remote-access) - Same as #2, but for your remote-access clients. They need to know the new IP address. You may need to change your PCF file (in Cisco's case).
4. Notify any services you have outside the company that will only accept connections only from your IP address. IF your IP address changes on the public side with the move, you have to let the 3rd party companies know ahead of time and when this is going to happen. You don't want this serviced denied because you didn't let them know.
5. If there are topology changes, keep in mind other things that might be affected. Things like IPS, Web filters, etc. I had this happen this past weekend. Make sure you get everything in where it needs to go. Topology changes can certainly bring some challenges, but make sure you do the best you can to get everything where it needs to go.
When the move is done, test everything. Test voice (local calls, 911, 411, toll free, long distance, international). Test data (all VLAN access). Test applications. Test failover (things configured for HA). Literally, test everything you can think of.
Some other thoughts about move day that I have.
1. Wear comfortable shoes. Its likely going to be a long day/night. Be comfortable.
2. Pack some snacks in your bag. Not everyone eats the same time you do, and bailing when everyone else is working is usually frowned upon. If you need caffeine, pack a soda.
3. When its late and everyone is tired, you may easily see tempers get roused more easily. Just remember everyone is tired. Its not the normal circumstances. They want to be at home just like you do. Stay professional and courteous.
4. If other vendors are involved in the move, work with them. Its a move for the customer, and the goal is to get the customer moved and back up. Everyone just wants to get their job done and get the customer going. Sometimes it takes two vendors working together to troubleshoot something. Dont just say "Its not my problem." (<--- That statement ALWAYS pisses me off) Work with the other vendors to get resolution. Remember, they do think its your problem, so work through it together. It makes the night go a lot smoother, even though it takes some time away from what your immediate accomplishments may be. Plus, you never know, you may learn something.
5. Help your teammates when they ask you to. You will likely need their help too at some point.
6. Dont be surprised when the unexpected happens. You just rebuilt the whole network. Sometimes things just happen, so be prepared for the unexpected.
When your do a move, expect some long hours. Usually its over a weekend. So I wouldn't really plan anything in your personal life for that weekend at all, except being at the move. Excluding drive time (4 hours total for me), me and another one of my coworkers did 21 hours onsite for the move in two days. Most of that was on day one. Day two was more 'fixing' things that needed attention (the unexpected).
So here is a list of things that you should really keep in mind. These are things you want to prepare for before the move. Here is a list that a network guy usually will encounter.
1. DNS changes - Your email, www servers, etc probably have access from the outside world. Outsiders rely on DNS to get to you, unless they know your public IP address. Make sure you change that to your new IP address scheme IF it changes with the new circuit. Sometimes it does, sometimes it does not.
2. VPNs (site to site) - Make sure you change your site to site VPNs (on the remote end) by giving them your new IP address of your firewall. If you dont, the VPN wont come up when you move. Again, that is IF your public IP address range changes.
3. VPNs (remote-access) - Same as #2, but for your remote-access clients. They need to know the new IP address. You may need to change your PCF file (in Cisco's case).
4. Notify any services you have outside the company that will only accept connections only from your IP address. IF your IP address changes on the public side with the move, you have to let the 3rd party companies know ahead of time and when this is going to happen. You don't want this serviced denied because you didn't let them know.
5. If there are topology changes, keep in mind other things that might be affected. Things like IPS, Web filters, etc. I had this happen this past weekend. Make sure you get everything in where it needs to go. Topology changes can certainly bring some challenges, but make sure you do the best you can to get everything where it needs to go.
When the move is done, test everything. Test voice (local calls, 911, 411, toll free, long distance, international). Test data (all VLAN access). Test applications. Test failover (things configured for HA). Literally, test everything you can think of.
Some other thoughts about move day that I have.
1. Wear comfortable shoes. Its likely going to be a long day/night. Be comfortable.
2. Pack some snacks in your bag. Not everyone eats the same time you do, and bailing when everyone else is working is usually frowned upon. If you need caffeine, pack a soda.
3. When its late and everyone is tired, you may easily see tempers get roused more easily. Just remember everyone is tired. Its not the normal circumstances. They want to be at home just like you do. Stay professional and courteous.
4. If other vendors are involved in the move, work with them. Its a move for the customer, and the goal is to get the customer moved and back up. Everyone just wants to get their job done and get the customer going. Sometimes it takes two vendors working together to troubleshoot something. Dont just say "Its not my problem." (<--- That statement ALWAYS pisses me off) Work with the other vendors to get resolution. Remember, they do think its your problem, so work through it together. It makes the night go a lot smoother, even though it takes some time away from what your immediate accomplishments may be. Plus, you never know, you may learn something.
5. Help your teammates when they ask you to. You will likely need their help too at some point.
6. Dont be surprised when the unexpected happens. You just rebuilt the whole network. Sometimes things just happen, so be prepared for the unexpected.
Friday, February 14, 2014
Part I: Preparing For A Physical Network Move Of A Company From One Site To Another
Have you ever had to move a company's network infrastructure from one building to another? It seems that most of the hard work is the actual moving of equipment. But what do you do to prepare for the move? Here are some thoughts that I consider when moving a company, from a network guy's perspective:
1. I draw out a physical connections layout in something like MSPaint or Visio. You need to know all of the connections, meaning what switch/port connects to what switch/port on the next. See the drawing below for an example of what I mean. I have crossed out some names and IP addresses that belong to this customer, but you get the idea. NOTE** The server guy should also do something like this so they know where to plug back into the switch without the network guy having to change config.
2. Are there any changes in the network you want to consider in the NEW building? If so, write them down. Maybe the changes will happen, maybe not. Sometimes its hard to tell until you get there, but if you are planning on considering the changes, write them down so you dont forget them. Afterthoughts are usually too late when trying to get a network up and going.
3. Take a copy of all the configs of what you are moving. Its just safe practice. Do a 'show run' into a text file so you have a backup. If something bad happens, you have a copy you can just TFTP back to the unit and you are back in business (theoretically speaking). Take a good backup before you break everything down.
4. If you are making any changes in the physical space of the rack, make sure all team members in the move know where the network gear is physically going in the rack. Don't decide during the move. Everyone needs to be on the same page. If you network gear goes in the top of the rack, make sure everyone knows how many 'U' you need.
5. Make sure everyone is on the same page for 'power down' of the equipment. Get with your server guys, and everyone agrees when power down of equipment is. I have seen turning network equipment off that has negatively affected servers before. You dont want your server guy having problems. Problems for
him is problems for you as well. Everyone must agree on power down time.
6. Make sure your network gear is up at the new site first, before servers are on. Somewhat the same principle as #5.
There are many things to check for in the new facility. You just have to know what to look for. You dont want water pipes/sprinklers in the server room. You need to make sure enough cool air from the HVAC unit is going to cool the room for all the gear going in (that will heat up the room). Just use your head and common sense. There are a lot of things to look for. If you see something that seems odd to you, voice that opinion. You never know what everyone else has missed.
1. I draw out a physical connections layout in something like MSPaint or Visio. You need to know all of the connections, meaning what switch/port connects to what switch/port on the next. See the drawing below for an example of what I mean. I have crossed out some names and IP addresses that belong to this customer, but you get the idea. NOTE** The server guy should also do something like this so they know where to plug back into the switch without the network guy having to change config.
2. Are there any changes in the network you want to consider in the NEW building? If so, write them down. Maybe the changes will happen, maybe not. Sometimes its hard to tell until you get there, but if you are planning on considering the changes, write them down so you dont forget them. Afterthoughts are usually too late when trying to get a network up and going.
3. Take a copy of all the configs of what you are moving. Its just safe practice. Do a 'show run' into a text file so you have a backup. If something bad happens, you have a copy you can just TFTP back to the unit and you are back in business (theoretically speaking). Take a good backup before you break everything down.
4. If you are making any changes in the physical space of the rack, make sure all team members in the move know where the network gear is physically going in the rack. Don't decide during the move. Everyone needs to be on the same page. If you network gear goes in the top of the rack, make sure everyone knows how many 'U' you need.
5. Make sure everyone is on the same page for 'power down' of the equipment. Get with your server guys, and everyone agrees when power down of equipment is. I have seen turning network equipment off that has negatively affected servers before. You dont want your server guy having problems. Problems for
him is problems for you as well. Everyone must agree on power down time.
6. Make sure your network gear is up at the new site first, before servers are on. Somewhat the same principle as #5.
There are many things to check for in the new facility. You just have to know what to look for. You dont want water pipes/sprinklers in the server room. You need to make sure enough cool air from the HVAC unit is going to cool the room for all the gear going in (that will heat up the room). Just use your head and common sense. There are a lot of things to look for. If you see something that seems odd to you, voice that opinion. You never know what everyone else has missed.
Thursday, February 13, 2014
Visiting Memories From The Past: Adtran HTU
Before I got into IT, I used to be an electronics technician. I see these Adtran units all the time in provider smartjacks, but I saw this one sitting out and I visited my memories for a few minutes. I used to troubleshoot these HTU units (on 3rd shift) down to component level back when I used to work for a company called Adtran, before I even knew what these things were. That was a long time ago.
Take a look in your DMARC smartjack and you will see probably several of these inside.
Take a look in your DMARC smartjack and you will see probably several of these inside.
Wednesday, February 12, 2014
Cisco Switch: How To Check The Stacking Order Of The 3750-X Switches AND How To Manipulate It
I personally recommend you set the switch order that you want. You can do like most people and just connect everything together and boot up the switches in the order you want them in, but I recommend a different way. I say this because it doesn't always work out the way you want it to. I did come across a stack of 6 3750-X switches that switch 3 and 4 were swapped. Not because they were not connected up right, but because the switch stack determined it to be that way.
First, see the video below. This is the easiest way to check the stacking order. First, press the 'Mode' button 3 times. You want the 'stack' LED lit up.
Now, how do you change that order if you need to? See below. I have the original config of those 6 I told you about earlier. Switch 3 and 4 did not come up right in the order I wanted them to.
Switch#sh switch
Switch/Stack Mac Address : 10f3.11cb.0700
H/W Current
Switch# Role Mac Address Priority Version State
----------------------------------------------------------
*1 Master 10f3.11cb.0700 1 3 Ready
2 Member 7cad.7494.7a80 1 3 Ready
3 Member 7cad.7472.9b00 1 3 Ready
4 Member 7cad.748a.b300 1 3 Ready
5 Member 10f3.11cc.c980 1 3 Ready
6 Member 7cad.7472.a080 1 3 Ready
I need to reverse these two.
Switch(config)#switch 3 renumber 4
WARNING: Changing the switch number may result in a
configuration change for that switch.
The interface configuration associated with the old switch
number will remain as a provisioned configuration.
Do you want to continue?[confirm]
Switch(config)#switch 4 ren 3
WARNING: Changing the switch number may result in a
configuration change for that switch.
The interface configuration associated with the old switch
number will remain as a provisioned configuration.
Do you want to continue?[confirm]
Changing Switch Number 4 to Switch Number 3
New Switch Number will be effective after next reboot
Switch(config)#exit
Now, lets take a look. Notice the MAC address of switch 3 and 4.
Switch#sh switch
Switch/Stack Mac Address : 10f3.11cb.0700
H/W Current
Switch# Role Mac Address Priority Version State
----------------------------------------------------------
*1 Master 10f3.11cb.0700 15 3 Ready
2 Member 7cad.7494.7a80 10 3 Ready
3 Member 7cad.748a.b300 9 3 Ready
4 Member 7cad.7472.9b00 8 3 Ready
5 Member 10f3.11cc.c980 7 3 Ready
6 Member 7cad.7472.a080 6 3 Ready
So now how do we also set the priority value for the switches? Yes, I think you need to do this to make sure that your switches always come up in the proper switch placement that they are supposed to.
Notice the priority values that I have set for another stack:
Switch#show switch
Switch/Stack Mac Address : 10f3.11d1.6d00
H/W Current
Switch# Role Mac Address Priority Version State
----------------------------------------------------------
*1 Master 10f3.11d1.6d00 15 3 Ready
2 Member 7cad.7472.a300 10 3 Ready
3 Member 7cad.748a.a280 9 3 Ready
4 Member 7cad.748a.a300 8 3 Ready
5 Member 7cad.7494.5280 7 3 Ready
Notice a couple of things. First, the * means that the switch is the master. Second, the master switch is set to the highest priority (15). Then, numerically the priority number goes down as the switch stack goes up.
Here is how you make these changes:
Switch(config)# switch 1 pri 15
Switch(config)# switch 2 pri 10
Switch(config)# switch 3 pri 9
Switch(config)# switch 4 pri 8
Switch(config)# switch 5 pri 7
First, see the video below. This is the easiest way to check the stacking order. First, press the 'Mode' button 3 times. You want the 'stack' LED lit up.
Now, how do you change that order if you need to? See below. I have the original config of those 6 I told you about earlier. Switch 3 and 4 did not come up right in the order I wanted them to.
Switch#sh switch
Switch/Stack Mac Address : 10f3.11cb.0700
H/W Current
Switch# Role Mac Address Priority Version State
----------------------------------------------------------
*1 Master 10f3.11cb.0700 1 3 Ready
2 Member 7cad.7494.7a80 1 3 Ready
3 Member 7cad.7472.9b00 1 3 Ready
4 Member 7cad.748a.b300 1 3 Ready
5 Member 10f3.11cc.c980 1 3 Ready
6 Member 7cad.7472.a080 1 3 Ready
I need to reverse these two.
Switch(config)#switch 3 renumber 4
WARNING: Changing the switch number may result in a
configuration change for that switch.
The interface configuration associated with the old switch
number will remain as a provisioned configuration.
Do you want to continue?[confirm]
Switch(config)#switch 4 ren 3
WARNING: Changing the switch number may result in a
configuration change for that switch.
The interface configuration associated with the old switch
number will remain as a provisioned configuration.
Do you want to continue?[confirm]
Changing Switch Number 4 to Switch Number 3
New Switch Number will be effective after next reboot
Switch(config)#exit
Now, lets take a look. Notice the MAC address of switch 3 and 4.
Switch#sh switch
Switch/Stack Mac Address : 10f3.11cb.0700
H/W Current
Switch# Role Mac Address Priority Version State
----------------------------------------------------------
*1 Master 10f3.11cb.0700 15 3 Ready
2 Member 7cad.7494.7a80 10 3 Ready
3 Member 7cad.748a.b300 9 3 Ready
4 Member 7cad.7472.9b00 8 3 Ready
5 Member 10f3.11cc.c980 7 3 Ready
6 Member 7cad.7472.a080 6 3 Ready
So now how do we also set the priority value for the switches? Yes, I think you need to do this to make sure that your switches always come up in the proper switch placement that they are supposed to.
Notice the priority values that I have set for another stack:
Switch#show switch
Switch/Stack Mac Address : 10f3.11d1.6d00
H/W Current
Switch# Role Mac Address Priority Version State
----------------------------------------------------------
*1 Master 10f3.11d1.6d00 15 3 Ready
2 Member 7cad.7472.a300 10 3 Ready
3 Member 7cad.748a.a280 9 3 Ready
4 Member 7cad.748a.a300 8 3 Ready
5 Member 7cad.7494.5280 7 3 Ready
Notice a couple of things. First, the * means that the switch is the master. Second, the master switch is set to the highest priority (15). Then, numerically the priority number goes down as the switch stack goes up.
Here is how you make these changes:
Switch(config)# switch 1 pri 15
Switch(config)# switch 2 pri 10
Switch(config)# switch 3 pri 9
Switch(config)# switch 4 pri 8
Switch(config)# switch 5 pri 7
Tuesday, February 11, 2014
Cisco Switch: More 3750-X Stacking
In helping one of my customers out, I set out to do more preparing some closets for production use. Cisco 3750-Xs in the access layer, Ill start stacking them and getting them ready for redundant 1G fiber uplinks. In this closet, they have 5 units ready for stacking. Remember, the firmware has to match for stacking.
This is what the stacking will look like on the back of the units. Go from 1 down to 2 on the next unit.
Use these stacking cables.
Ill need to add these network modules, plus the GBICs.
Put the modules in and add the stacking cables.
Set your priority for unit you want to be master, etc. Below, the yellow arrow points to the master unit, indicated by the master LED.
This is what the stacking will look like on the back of the units. Go from 1 down to 2 on the next unit.
Use these stacking cables.
Ill need to add these network modules, plus the GBICs.
Put the modules in and add the stacking cables.
Set your priority for unit you want to be master, etc. Below, the yellow arrow points to the master unit, indicated by the master LED.
Monday, February 10, 2014
Palo Alto Firewall: Reset Palo Alto Firewall But Keep Software Install and Updates Intact
I have come across times when I needed to reset a Palo Alto firewall, but I needed to keep the licenses and software install intact. I only needed to get the customer specific data off the unit. Well there is a way to do that on the Palo units. You run the "request system private-data-reset " command. Here is what I did here recently when resetting a unit, but keeping the software and licenses intact:
When you reset this, you log back in, set the IP address/default gateway/DNS info, and re-connect to the Palo Alto site to license the box. Everything like the OS version you had plus the updates you did will be there, after you put the license back on. However, you may want to check for updates again to get it completely up to date.
UPDATE: I did this on another unit and it wouldn't boot up afterwards. I had to do a factory reset on it and build everything from scratch again. Just fyi
PA-3020> request system ?
> external-list Perform external-list refresh/sanity functions
> fqdn Perform fqdn refresh/reset functions
> private-data-reset Delete private data, keep software, content installations
> self-test FIPS/CC self test commands
> self-test-job Run FIPS/CC self test job
> software Perform system software installation functions
PA-3020> request system private-data-reset
Executing this command will remove all logs and configuration will revert back to factory defaults. The system will restart and then reset the data. Are you sure you want to continue? (y/n) (y or n) y
When you reset this, you log back in, set the IP address/default gateway/DNS info, and re-connect to the Palo Alto site to license the box. Everything like the OS version you had plus the updates you did will be there, after you put the license back on. However, you may want to check for updates again to get it completely up to date.
UPDATE: I did this on another unit and it wouldn't boot up afterwards. I had to do a factory reset on it and build everything from scratch again. Just fyi
Saturday, February 8, 2014
What Is An ACL (Access-list)? A General Overview
I was asked a few days ago about access-list and where would be a good source for learning about them. I'm sure there are a ton of sites that would talk about them. But, I thought I would write a basic overview of an ACL and how it works.
Imagine that you walk up to a door of a bank. You reach out your hand to open the door and it doesn't open. You are stuck on the outside and can not get in. You are denied access because the electronic switch that holds the door just wont let the door go to open it.
Now imagine that you walk up to that same door of the bank. You happen to work there, and are part of the trusted team to get into the bank. You walk up to the door, swipe your badge, reach out your hand, and open the door. You are trusted and the electronics permitted you access.
ACLs (Access-lists) are no different than the electronic system holding that door closed. They are a part of the security enforcement for the firewall/router/switch and can make or break security if you don't configure them correctly. If you allow untrusted people from the outside of the network in through your created ACLs, then its you responsible. You wouldn't want to do that at a bank would you? You have to keep intruders and untrusted people out from your internal network. Its no different than the security system allowing access via that door if you do or don't swipe a card that has permission to get inside.
Now, with that said, lets look at one line of an ACL from a Cisco router. Keep in mind, there are several variables you can implement into an ACL, but this is the foundation. Also keep in mind that there are cases where syntax for a subnet mask is different, depending on what you are trying to do. In the example below, I'm using an ACL I pulled off of a router. Again, this is a foundation ACL thought of the very basic of an ACL. You will have to dive deep into study for more info on the topic.
access-list 103 permit ip 10.1.10.0 0.0.0.255 any
The above access-list is named 103 (in violet). You can name it an actual name like "Bob" or "DMZ", but in this case, it is an extended ACL, so Im using the random number (100-199 for extended ACLs) of 103. I personally prefer to use numbers over names, but that is only my preference. I think most people prefer names so that they can name it what its actual function is. Not me, I just prefer numbers.
The next part is a 'permit' keyword (in red). It could either be 'permit' or 'deny'. Im allowing IP traffic (in orange) with a source of 10.1.10.0/24 (in yellow) access to 'any' destination (in green). Always remember that in an ACL, the source comes first, then the destination. It is never the other way around. So this ACL does two things. It allows traffic from 10.1.10.0/24 to any destination to be permitted. It also has an explicit 'deny ip any any' after that line. Its in by default and you can not change that.
The other thing you need to know is that an ACL is looked at from top to bottom. Line 1 is looked at first, then line 2, then line 3, and so on, until the bottom of the ACL. It never goes in any other way. Its always from top to bottom.
Again, this is a very basic overview of an ACL. So dive into a book about ACLs and learn more about them. They are a highly used item in the network world.
Imagine that you walk up to a door of a bank. You reach out your hand to open the door and it doesn't open. You are stuck on the outside and can not get in. You are denied access because the electronic switch that holds the door just wont let the door go to open it.
Now imagine that you walk up to that same door of the bank. You happen to work there, and are part of the trusted team to get into the bank. You walk up to the door, swipe your badge, reach out your hand, and open the door. You are trusted and the electronics permitted you access.
ACLs (Access-lists) are no different than the electronic system holding that door closed. They are a part of the security enforcement for the firewall/router/switch and can make or break security if you don't configure them correctly. If you allow untrusted people from the outside of the network in through your created ACLs, then its you responsible. You wouldn't want to do that at a bank would you? You have to keep intruders and untrusted people out from your internal network. Its no different than the security system allowing access via that door if you do or don't swipe a card that has permission to get inside.
Now, with that said, lets look at one line of an ACL from a Cisco router. Keep in mind, there are several variables you can implement into an ACL, but this is the foundation. Also keep in mind that there are cases where syntax for a subnet mask is different, depending on what you are trying to do. In the example below, I'm using an ACL I pulled off of a router. Again, this is a foundation ACL thought of the very basic of an ACL. You will have to dive deep into study for more info on the topic.
access-list 103 permit ip 10.1.10.0 0.0.0.255 any
The above access-list is named 103 (in violet). You can name it an actual name like "Bob" or "DMZ", but in this case, it is an extended ACL, so Im using the random number (100-199 for extended ACLs) of 103. I personally prefer to use numbers over names, but that is only my preference. I think most people prefer names so that they can name it what its actual function is. Not me, I just prefer numbers.
The next part is a 'permit' keyword (in red). It could either be 'permit' or 'deny'. Im allowing IP traffic (in orange) with a source of 10.1.10.0/24 (in yellow) access to 'any' destination (in green). Always remember that in an ACL, the source comes first, then the destination. It is never the other way around. So this ACL does two things. It allows traffic from 10.1.10.0/24 to any destination to be permitted. It also has an explicit 'deny ip any any' after that line. Its in by default and you can not change that.
The other thing you need to know is that an ACL is looked at from top to bottom. Line 1 is looked at first, then line 2, then line 3, and so on, until the bottom of the ACL. It never goes in any other way. Its always from top to bottom.
Again, this is a very basic overview of an ACL. So dive into a book about ACLs and learn more about them. They are a highly used item in the network world.
Friday, February 7, 2014
Ive Said It Before: Check That CPU Utilization On Those Devices
You have to keep an eye out on the network devices you have. Every now and then, check the CPU and other items like bandwidth utilization to keep a baseline on the network. Sometimes it can get ugly without you knowing it.
9798989898534379888899999890909766663353244469357069999899423354433389
3415051535445763988814620810100715627532880653919050520433787764246763
100 * * * * *
90 * ******** **************** * * **** ** **
80 * ******** *##****#********** * ** ******* **
70 ********** *###*###********** ** ** ********** **
60 ********** *########************* ** ********** * **
50 *******#*** * *########************* * * *** *****#****** * **
40 *########** ***########**######******** ****#***#######*#* ***** ****
30 *#########*****##################************#**##########***********#
20 ######################################################################
10 ######################################################################
0....5....1....1....2....2....3....3....4....4....5....5....6....6....7.
0 5 0 5 0 5 0 5 0 5 0 5 0
CPU% per hour (last 72 hours)
* = maximum CPU% # = average CPU%
9798989898534379888899999890909766663353244469357069999899423354433389
3415051535445763988814620810100715627532880653919050520433787764246763
100 * * * * *
90 * ******** **************** * * **** ** **
80 * ******** *##****#********** * ** ******* **
70 ********** *###*###********** ** ** ********** **
60 ********** *########************* ** ********** * **
50 *******#*** * *########************* * * *** *****#****** * **
40 *########** ***########**######******** ****#***#######*#* ***** ****
30 *#########*****##################************#**##########***********#
20 ######################################################################
10 ######################################################################
0....5....1....1....2....2....3....3....4....4....5....5....6....6....7.
0 5 0 5 0 5 0 5 0 5 0 5 0
CPU% per hour (last 72 hours)
* = maximum CPU% # = average CPU%
Thursday, February 6, 2014
Check Point Gaia: Upgrade From R76 To R77.10
I was onsite with a customer doing an upgrade on a 4600 Check Point box. We were going from the default R76 Gaia install to R77.10. I wanted to give you an idea of what to expect when doing an upgrade like this. You can go directly from R76 to R77.10 without any problem.
Log into the Gaia webUI and go down to the Upgrade option under Maintenance.
Notice above the arrow on the left. That is how you get to where you do the upgrade. Upload the image (.tgz file) and its going to ask you if you are sure you want to do the upgrade (which I dont like). Answer yes.
Wait for the install to finish and it will reboot. Log back in to Gaia and go to Overview page and verify the upgraded image version. You are good to go.
Log into the Gaia webUI and go down to the Upgrade option under Maintenance.
Notice above the arrow on the left. That is how you get to where you do the upgrade. Upload the image (.tgz file) and its going to ask you if you are sure you want to do the upgrade (which I dont like). Answer yes.
Wait for the install to finish and it will reboot. Log back in to Gaia and go to Overview page and verify the upgraded image version. You are good to go.
Wednesday, February 5, 2014
How Do I Keep Microsoft Windows From Trying To 'Identify The Network'?
Man I really hate this. Its just needless and Im pretty much anti Microsoft anyway when it comes to most things. Go to Services and disable the "Network List Service". Now this 'identifying' the network stops.
Tuesday, February 4, 2014
Cisco ASA: Can Not Send Secure Email From Behind Firewall
I got a call from a customer that said that they could not send out secure emails from their Exchange server from within their company to an outside email address. So me and the engineer that was with me went onsite, since we were close already, and almost immediately the guy that was with me mentioned that he had recently seen this and that he thought that the ASA inspection was blocking this outbound secure email. Well, that jogged my memory as well, and it seems like I have run into that a few times in the past as well. What was the solution?
Console into the Cisco ASA, then do the following:
ciscoasa# config t
ciscoasa(config)# policy-map global_policy
ciscoasa(config-pmap)# class inspection_default
ciscoasa(config-pmap-c)# no inspect esmtp
ciscoasa(config-pmap-c)#
I dont recall having to do this for any other firewall except the Cisco ASA. I know I have not for Check Point and Palo Alto. As for any other, Im not sure.
Console into the Cisco ASA, then do the following:
ciscoasa# config t
ciscoasa(config)# policy-map global_policy
ciscoasa(config-pmap)# class inspection_default
ciscoasa(config-pmap-c)# no inspect esmtp
ciscoasa(config-pmap-c)#
I dont recall having to do this for any other firewall except the Cisco ASA. I know I have not for Check Point and Palo Alto. As for any other, Im not sure.
Monday, February 3, 2014
Brocade TurboIron: Replacement Of A Power Supply
While I was onsite at a customer, one of the things I needed to do was to put in an extra power supply into a TurboIron switch. It had one already and was in production, but the customer wanted redundant power supplies in this unit, so I needed to get the second power supply in and operational. There is no magic to this at all. Its just put the module in and plug it up. That is all. You don't have to power down the unit either. Just plug the power supply in while in operation.
Saturday, February 1, 2014
Cisco Router: BGP Sample/Template Config
BGP is a routing protocol, and if you are reading this post, I suppose you know that already. I went onsite to a customer that needed some router config done for a connection to an MPLS. The ISP was using BGP for routing and so I needed to get that configured, among other interface config and some static routing. Here is the BGP template below if you need one. This config was for one connection to the MPLS.
router bgp 1234
bgp log-neighbor-changes
neighbor 10.12.51.14 remote-as 45677
!
address-family ipv4
network 10.10.0.0 mask 255.255.0.0
redistribute connected
neighbor 10.12.51.14 activate
neighbor 10.12.51.14 advertisement-interval 5
exit-address-family
router bgp 1234
bgp log-neighbor-changes
neighbor 10.12.51.14 remote-as 45677
!
address-family ipv4
network 10.10.0.0 mask 255.255.0.0
redistribute connected
neighbor 10.12.51.14 activate
neighbor 10.12.51.14 advertisement-interval 5
exit-address-family
Subscribe to:
Posts (Atom)