Your Custom Text Here
Service provider style requires explicit configuration of each feature on the interface, and the bridge domains need to reference the interface.
Enterprise style does not require explicit configuration for each feature, which reduces the amount of configuration but also reduces the number of features.
Read moreRouters can forward a multicast packet by using either a dense-mode multicast routing protocol or a sparse-mode multicast routing protocol.
Multicast Forwarding Using Dense Mode
The design of a dense-mode routing protocol instructs the router to forward the multicast traffic on all the configured interfaces, with some exceptions to prevent looping.
Dense-mode routers typically do not want to receive multicast packets for a particular group if both of the following are true:
■ The router does not have any active downstream routers that need packets for that group.
■ The router does not know of any hosts on directly connected subnets that have joined that group.
Multicast routers use a Reverse Path Forwarding (RPF) check to prevent loops. The RPF check adds this additional step to a dense-mode router’s forwarding logic:
Look at the source IP address of the multicast packet. If my route that matches the source lists an outgoing interface that is the actual interface on which the packet was received, the packet passes the RPF check. If not, do not replicate and forward the packet.
The RPF check implements a strategy by which routers accept packets that arrive over the shortest path, and discard those that arrive over longer routes.
“Necessity is the mother of all invention,” a saying derived from Plato’s Republic, holds very true in the world of technology. In the late 1980s, Dr. Steve Deering was working on a project that required him to send a message from one computer to a group of computers across a Layer 3 network. After studying several routing protocols, Dr. Deering concluded that the functionality of the routing protocols could be extended to support “Layer 3 multicasting.” This concept led to more research, and in 1991, Dr. Deering published his doctoral thesis, “Multicast Routing in a Datagram Network,” in which he defined the components required for IP multicasting, their functions, and their relationships with each other. The most basic definition of IP multicasting is as follows: Sending a message from a single source to selected multiple destinations across a Layer 3 network in one data stream.
Read moreJuniper switch or router can get a filesystem corrupted and won't boot. You have to reinstall the OS using two options:
First, when the OS is booting and you see "Loading /boot/defaults/loader.conf" message, hit space bar key to get into the loader cli:
Then from here you can either install the OS from TFTP server. Lets assume, that the switch management port (172.16.50.100/24) is directly connected to ftp server (172.16.50.10/24). You need to configure the IP address on the switch and start the installation:
If you want to install the OS from the usb stick, you need to first format it using FAT32, copy the software, turn off the switch or router, insert the stick, turn the switch or router back on, get into the loader command line and run the following command:
Good luck!
We will be using passwordless ssh access to the switch, so ssh-rsa key has to be configured on the target switch.
All we need to do here is to ssh to the switch, run the command: "show interfaces vlan terse | match inet" and get vlan interface IDs from the output.
If the switch has vlan interfaces configured, the output will look like this:
vlan.501upup inet 10.5.5.10/24 vlan.601upup inet 10.6.6.10/24
The following python regex will be used to get vlan interface numbers:
pulled_vlans = re.findall(r'vlan.(\d{3})', cli_output)We need to write a simple custom Python ansible module that will be called from the playbook.
**TIP: To make a custom module available to Ansible, you can either specify the path to your custom module in an environment variable, ANSIBLE_LIBRARY; use the --module-path command-line option, or drop the modules in a ./library directory alongside your top-level playbooks.
Read moreThis post follows on from my last post about the Junos EZ Library, Jeremy Schulman’s work to make Junos devices easily manageable via Python, even for those of us who are not hard core programmers by trade.
In order to run the Junos EZ library I had to prepare my Ubuntu system with a few pre-requisites. Jeremy’s first post talks about what’s required on his CentOS Developer Workstation; this post does the same for Ubuntu server.
# Install the NETCONF 'ncclient' library:
pip-2.7 install git+https://github.com/Juniper/ncclient.git
# Install the Junos "EZ" library:
pip-2.7 install git+https://github.com/jeremyschulman/py-junos-eznc.git
But hold on, because those commands need other things to be in place in order to succeed. At the very least, along with the above, you will need Python 2.7 and the “pip–2.7” tool. On my Ubuntu server, I had Python 2.7 installed, but the rest took a few more steps.
Read moreip prefix-list provides the most powerful prefix based filtering mechanism
Here is a quick little tutorial on Prefix-lists for you.
A normal access-list CANNOT check the subnet mask of a network. It can only check bits to make sure they match, nothing more. A prefix-list has an advantage over an access-list in that it CAN check BOTH bits and subnet mask - both would have to match for the network to be either permitted or denied.
For checking bits a prefix list ALWAYS goes from left to right and CANNOT skip any bits. A
Read more
Proper clustering is very important to provide desired redundancy in an RR-based architecture. Consider the topology on the left side of Figure, in which two RRs use the same cluster ID. When the prefix 172.16.0.0/16 is advertised from R4, two RRs advertise to R1 and to each other. However, the updates between RRs are discarded because they are in the same cluster.
Obviously two RRs provide redundancy to clients, but is that enough? The answer depends on how RRs are configured, as explained in this section. R1 has two BGP paths to the destination—one learned from R2 and the other learned from R3. Between the two paths, R1 picks one best path—perhaps the path via R2 (it does not make any difference for this
discussion which path is the best path).
Now assume that the BGP next hop can be reached via two equal-cost IGP paths. R1 loadshares the packets using these two IGP paths. So far everything is fine. Lets say that the iBGP session between R4 and R3 is down, perhaps due to misconfiguration or administrative shutdown. While R2 continues to forward the traffic as before, the traffic via R3 is discarded because it has no path for the prefix, even though the physical link between R3 and R4 is still functioning. This results in about 50% packet loss.
To correct the problem, consider the design on the right of Figure. In this design, two RRs are in different clusters. In the case of iBGP session failure between R4 and R3, R3 continues to forward the traffic, because the prefix is also learned from R2. This design not only provides physical redundancy against a link failure but also provides logical redundancy against a failure of the iBGP session between a client and an RR. Note however that this design leads to more memory use due to the extra path.
Tasks:
1. Implement Route Reflectors;
2. Configure a Route Reflector and Internal BGP session;
3. Restrict Route Propagation to a Client;
4. Implement BGP Security Options;
5. Implement BGP Neighbor Authentication Using Key Chains;
6. Enable BGP TTL Security Check;
7. Enable CoPP;
8. Enable RTBG Filtering;
9. Improve BGP Scalability;
10. Improve BGP Convergence by Changing the BGP Scan and Advertisement Interval;
11. Improve BGP Convergence by Enabling BFD;
12. Implement BGP Route Dampening;
Read more
Junos PyEZ is a Python "micro-framework" to remotely manage or automate Junos OS devices. The user is NOT required to be a software programmer, have sophisticated knowledge of Junos OS, or have a complex understanding of the Junos OS XML API.
This library was built for two types of users:
This means that non-programmers, for example, the Network Engineer, can use the native Python shell on their management server (laptop, tablet, phone, and so on) as their point-of-control for remotely managing Junos OS devices. The Python shell is an interactive environment that provides the necessary means to perform common automation tasks, such as conditional testing, for-loops, macros, and templates. These building blocks are similar enough to other "shell" environments, like Bash, to enable the non-programmer to use the Python shell as a power tool, instead of a programming language. From the Python shell, a user can manage Junos OS devices using native hash tables, arrays, and so on, instead of using device-specific Junos OS XML or resorting to "screen scraping" the actual Junos OS CLI.
There is a growing interest and need to automate the network infrastructure into larger IT systems. To do so, traditional software programmers, DevOps, hackers, and so on, need an abstraction library of code to further those activities. Junos PyEZ is designed for extensibility so that the programmer can quickly and easily add new widgets to the library in support of their specific project requirements. There is no need to "wait on the vendor" to provide new functionality. Junos PyEZ is not specifically tied to any version of Junos OS or any Junos OS product family.
Read morePrerequisites
The knowledge and skills that a learner must have before attending this course are as follows:
#show configuration groups junos-defaults applications
#
# File Transfer Protocol
#
application junos-ftp {
application-protocol ftp;
protocol tcp;
destination-port 21;
}
#
# Trivial File Transfer Protocol
#
application junos-tftp {
application-protocol tftp;
protocol udp;
destination-port 69;
}
#
# Real Time Streaming Protocol
#
application junos-rtsp {
application-protocol rtsp;
protocol tcp;
destination-port 554;
}
#
# Network Basic Input Output System- networking protocol used on
# Windows networks session service port
Read moreAnsible is an IT automation tool. It can configure systems, deploy software, and orchestrate more advanced IT tasks such as continuous deployments or zero downtime rolling updates.
Ansible’s goals are foremost those of simplicity and maximum ease of use. It also has a strong focus on security and reliability, featuring a minimum of moving parts, usage of OpenSSH for transport (with an accelerated socket mode and pull modes as alternatives), and a language that is designed around auditability by humans – even those not familiar with the program.
Read moreThe underlying mechanism for the Aruba redundancy solution is the Virtual Router Redundancy Protocol (VRRP)
-If VRRP preemption is disabled (the default setting) and all controllers share the same priority, the first controller that comes up becomes the master.
OR
-If VRRP preemption is enabled and all controllers share the same priority, the controller with the highest IP address becomes the master.
SRX are stateful firewalls and will only allow traffic which matches an existing session. Sessions are created when a TCP SYN packet is received and it is permitted by the security policy. This of course means that the firewall needs to see both directions of a flow (client-server and server-client), otherwise these checks will block legitimate packets.
Whenever possible its best to ensure that asymmetric flows can't occur, but this is not always possible. Therefor you can disable these checks globally on the SRX: