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:
- Monitor all server equipment nic cards.
- Smokeping between different servers
- Monitor local bandwidth going out to the cloud
- Trending reports will tell you if the cloud has issues
- Have a Network Host in the cloud that is dedicated to running latency, jitter numbers utilizing smokeping
- 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
On Cisco NX-OS it’s very simple to accomplish:
monitor session 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 126.96.36.199
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
Step #3: Map The Ports you want to mirror with the firewall filter
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
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.
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).
The little things and difference are usually annoying so hopefully somebody will find this article in case they have similar designs and requirements.
Linux ifconfig commands are being deprecated. Here is a quick overview.
|arp||ip n (ip neighbor)|
|ifconfig||ip a (ip addr), ip link, ip -s (ip -stats)|
|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)|
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:
Cisco Default Distance Values
Juniper Default Distance Values
|Internal Access Route||N/A||2|
|Enhanced Interior Gateway Routing Protocol (EIGRP) summary route||5||N/A|
|External Border Gateway Protocol (eBGP)||20||20|
|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|
|Internal BGP (iBGP)||200||200|