I have been working on articles in the backend as of lately but a few upcoming changes…
Stay Tuned…
by 
Labs:
Books:
Courses:
Emulators:
Automation
o
Other
yum install rsyslog
yum install postfix
chkconfig rsyslog on
sudo mkdir /var/log/syslog
vim /etc/rsyslog.conf
Uncomment the UDP and TCP syslog reception items to match below:
# Provides UDP syslog reception
$ModLoad imudp
$UDPServerRun 514
# Provides TCP syslog reception
$ModLoad imtcp
$InputTCPServerRun 514
Add Template before GLOBAL DIRECTIVES
$template RemoteLogs,”/var/log/syslog/%HOSTNAME%/%$now%.log” *
*.* ?RemoteLogs
& ~
Make sure rsyslog is on on boot and restart it
systemctl enable rsyslog.service
systemctl restart rsyslog.service
Setup Email Alerting
$ModLoad ommail
$ActionMailSMTPServer localhost
$ActionMailFrom networkteam@pingpros.com
$ActionMailTo networkteam@pingpros.com
$template mailSubject,”Network Issue on %hostname%”
$template mailBody,”RSYSLOG Alert\nmsg=’%msg%'”
$ActionMailSubject mailSubject
# make sure we receive a mail only once in an
# hours (3600 seconds)
$ActionExecOnlyOnceEveryInterval 3600
# the if … then … mailBody must be on one line!
if ($msg contains ‘BGP’ or $msg contains ‘bgp’ or $msg contains ‘OSPF’ or $msg contains ‘ospf’ or $msg contains ‘FLAP’ or $msg contains ‘down’ or $msg contains ‘DOWN’ or $msg contains ‘SPAN’ or $msg contains ‘span’ or $msg contains ‘loop’ or $msg contains ‘LOOP’ or $msg contains ‘up’ or $msg contains ‘UP’) then :ommail:;mailBody
# re-set interval so that other actions are not affected
$ActionExecOnlyOnceEveryInterval 0
Setup logrotate
sudo vim /etc/logrotate.conf
At very bottom of the file do the following
# Rotate the log daily up to 5 years of retention 365 times 5
/var/log/syslog/*.log /var/log/syslog/*/*.log {
dateext
dateformat .%Y-%m-%d
daily
rotate 1825
compress
}
Test the rotations
logrotate -d /etc/logrotate.conf
shell> sudo apt-get update
shell> sudo apt-get upgrade
shell> sudo hostname turtle
shell> sudo vim /etc/hostname
turtle.pingpros.com
shell> sudo vim /etc/hosts
127.0.0.1 debian
127.0.0.1 turtle.pingpros.com
shell> sudo /etc/init.d/hostname.sh
shell> sudo apt-get install postfix
shell> sudo apt-get install sendmail
shell> sudo apt-get install smokeping
shell> apt-get install tcptraceroute
shell> cd /usr/bin/
shell> wget http://www.vdberg.org/~richard/tcpping
shell> chmod 755 tcpping
shell> cd /etc/apache2/conf-available
shell> sudo ln -s ../../smokeping/apache2.conf smokeping.conf
shell> sudo a2enconf smokeping
shell> sudo a2enmod cgid
shell> service apache2 reload
shell> sudo vim /etc/smokeping/config.d/General
cgiurl = http://turtle.pingpros.com/cgi-bin/smokeping.cgi
I’ve been perplexed with a problem lately as a network engineer. Obviously the use of Public/Hybrid clouds from third party providers causes a lack of any sort of visibility for a network engineers.
The question is…how do we…as network engineers gain the visibility necessary to see the health of the cloud and performance within the network.
Here are a few ideas that one can utilize to start gaining more visibility for an engineer to help with performance metrics and troubleshooting:
by
On Cisco NX-OS it’s very simple to accomplish:
monitor session 1
Note: See Step #4 in terms of why we choose the next hop to be 1.1.12
Step #2: Setup a firewall to mirror the port traffic
set firewall family inet filter port-mirror term 1 then port-mirror
set firewall family inet filter port-mirror term 1 then accept
set firewall family inet filter port-mirror term 2 then accept
Step #3: Map The Ports you want to mirror with the firewall filter
set interfaces ge-1/0/1 unit 0 family inet filter input port-mirror
set interfaces ge-1/0/1 unit 0 family inet filter output port-mirror
set interfaces ge-1/0/2 unit 0 family inet filter input port-mirror
set interfaces ge-1/0/2 unit 0 family inet filter output port-mirror
set interfaces ge-1/0/3 unit 0 family inet filter input port-mirror
set interfaces ge-1/0/3 unit 0 family inet filter output port-mirror
Having utilized routing-instances in the MX series to segregate management functions/protocols away from insecure internet sources I ran into an instance that’s quite unique to the SRX platform only.
Normally for management items on an MX series one would create a separate routing instance away from the routing instance (see image below). This allows for segregation and reduces potential security holes in your design.
Design Main Points:
Create a MGMT routing-instance and import/export ribs between the the main and mgmt inet.0 routing tables, NAT and re-route certain management protocols/functions (NTP, netconf, syslog, snmp, etc…) from the main routing table (inet.0) to mgmt.inet.0.
Note: This assumes that your company is very strict on opening ports and doing NAT device cross talk between your outside region. Valid in corporations with standards…not so much within smaller companies that don’t care for security of course.
Underlying Problem:
While most items can be re-routed and transferred over, one particular item is not doable on the SRX systems themselves.
If you want to use an internal ntp client to maintain and manage time for all of your server equipment SRX series routers simply cannot route ntp over any instance but the main one (IE. inet.0).
So why doesn’t it work on the SRX Series?
It’s the way the SRX bootup procedures are setup. It will always use the main routing table (inet.0).
KB Article:
http://kb.juniper.net/InfoCenter/index?page=content&id;=KB22499&actp;=RSS
The little things and difference are usually annoying so hopefully somebody will find this article in case they have similar designs and requirements.