Skip to content

Monitoring in the Cloud as a Network Admin

Monitoring in the Cloud as a Network Admin published on No Comments on Monitoring in the Cloud as a Network Admin

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:

  1. Monitor all server equipment nic cards.
  2. Smokeping between different servers
  3. Monitor local bandwidth going out to the cloud
  4. Trending reports will tell you if the cloud has issues
  5. Have a Network Host in the cloud that is dedicated to running latency, jitter numbers utilizing smokeping
FacebooktwitterredditpinterestlinkedinmailFacebooktwitterredditpinterestlinkedinmailby feather

Multiple Ports, Port-Mirror on Juniper MX80 going to a directly connected TAP port

Multiple Ports, Port-Mirror on Juniper MX80 going to a directly connected TAP port published on No Comments on Multiple Ports, Port-Mirror on Juniper MX80 going to a directly connected TAP port

The Setup:

  • You have an MX80 with three ISP connections out to the internet.
  • Ports ge-1/0/0, ge-1/0/1, ge-1/0/2, and ge-1/0/3 all need to have their traffic mirrored
    • Bandwidth for all ports combined is 300 Mbps…so it will not be a problem with utilization another Gig Port to dump all data to
  • Port ge-1/0/4 is the port on the MX80 connecting directly to the Security Appliance
  • You have a security appliance with a TAP port configured to sniff all data transiting the MX 80
    • NO IP Address is assigned
    • You can obtain the MAC address which in this case is: 00:1b:17:37:17:24
MX80 Port Mirror(1)

The Problem:

On Cisco NX-OS it’s very simple to accomplish:
monitor session 1 

  source interface ge-1/0/0,ge-1/0/1,ge-1/0/2,ge-1/0/3 both
  destination interface ge-1/0/4
But…how do we achieve it on a Juniper MX80 Running Code that is applicable in the year 2012/2013?

The Solution:

Step #1: Setup the Port Forwarding
set forwarding-options port-mirroring input rate 1
set forwarding-options port-mirroring input run-length 1
set forwarding-options port-mirroring family inet output interface ge-1/0/4.0 next-hop 1.1.1.2
set forwarding-options port-mirroring family inet output no-filter-check

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

NOTE: If you have a filter applied to the interface it’s important that you put in the “then port-mirror” command on that filter.

Step #3: Map The Ports you want to mirror with the firewall filter

set interfaces ge-1/0/0 unit 0 family inet filter input port-mirror
set interfaces ge-1/0/0 unit 0 family inet filter output port-mirror

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

Step #4: Create a Private IP address and subnet range and map it to the dump port and create an ARP entry with another address to map the TAP port
 
set interfaces ge-1/0/4 unit 0 family inet address 1.1.1.1/30 arp 1.1.1.2 mac 00:1b:17:37:17:24
 
Notice: We are creating a fake IP address on ge-1/0/3 and giving it one particular address then we are creating an ARP entry with a completely different address in the same subset to map the TAP port for.

Juniper SRX management routing-instance limitations

Juniper SRX management routing-instance limitations published on No Comments on Juniper SRX management routing-instance limitations

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.

SRX-Limitations(1)

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.

Linux deprecated ifconfig commands in CentOS 7

Linux deprecated ifconfig commands in CentOS 7 published on No Comments on Linux deprecated ifconfig commands in CentOS 7

Linux ifconfig commands are being deprecated. Here is a quick overview.

 

Deprecated command

Replacement command(s)
arp ip n (ip neighbor)
ifconfig ip a (ip addr), ip link, ip -s (ip -stats)
iptunnel ip tunnel
iwconfig iw
nameif ip link, ifrename
netstat ss, ip route (for netstat-r), ip -s link (for netstat -i), ip maddr (for netstat-g)
route ip r (ip route)

Administrative Distances

Administrative Distances published on No Comments on Administrative Distances

If you plan on migrating routing protocols or have multiple routing protocols it’s important to note the administrative distance values so you are aware of which route preferences will be based on the protocol.

You can change the preferences of protocols by changing the values to a lower value.

Remember: The lower the number, the higher the routing preference (IE: OSPF with a value of 110 will be preferred over RIP with a value of 120).

 

The table below compares Cisco and Juniper Distance values below to show vendor similarities:

Route Source

Cisco Default Distance Values

Juniper Default Distance Values
Connected interface 0 0
Static route 1 1
Internal Access Route N/A 2
Access Route N/A 3
Enhanced Interior Gateway Routing Protocol (EIGRP) summary route 5 N/A
External Border Gateway Protocol (eBGP) 20 20
Internal EIGRP 90 N/A
IGRP 100 N/A
OSPF 110 110
Intermediate System-to-Intermediate System (IS-IS) 115 115
Routing Information Protocol (RIP) 120 120
Exterior Gateway Protocol (EGP) 140 N/A
On Demand Routing (ODR) 160 N/A
External EIGRP 170 N/A
Internal BGP (iBGP) 200 200
Unknown* 255 255