Iperf is a tool to measure the bandwidth and the quality of a network link. Jperf can be associated with Iperf to provide a graphical frontend written in Java.
The network link is delimited by two hosts running Iperf.
The quality of a link can be tested as follows:
- Latency (response time or RTT): can be measured with the Ping command.
- Jitter (latency variation): can be measured with an Iperf UDP test.
- Datagram loss: can be measured with an Iperf UDP test.
The bandwidth is measured through TCP tests.
To be clear, the difference between TCP (Transmission Control Protocol) and UDP (User Datagram Protocol) is that TCP use processes to check that the packets are correctly sent to the receiver whereas with UDP the packets are sent without any checks but with the advantage of being quicker than TCP.
Iperf uses the different capacities of TCP and UDP to provide statistics about network links.
Finally, Iperf can be installed very easily on any UNIX/Linux or Microsoft Windows system. One host must be set as client, the other one as server.
SRX240 cluster management interface
You've discovered one of the more aggravating "features" of the SRX products. The fxp0 interfaces become "out of band" management, and I use the quotes because Juniper has a very different opinion of what "out of band" means than many other manufacturers and customers. Personally I think it's an incredibly impractical way to do management, and I don't even use fxp0 interfaces on my clusters because I can't stand the way Juniper thinks they should work.
Read moreEX4200 virtual-chassis upgrade with minimal downtime
If the stack is running 12.1 or later code, the least downtime method is to use the nonstop-upgrade option. That will do the upgrade member by member, taking only one down at a time. You do need to ensure that you have the virtual chassis configured to run in non-stop mode though.
set chassis redundancy graceful-switchover set ethernet-switching-options nonstop-bridging set routing-options nonstop-routing
Once the stack is configured properly, doing a non-stop upgrade is only slightly different from the method you used.
request system software nonstop-upgrade reboot <package>Read more
Rib groups - export-rib VS import-rib
There is alot of confusion regarding the subject. In order to better understand the difference I will perform several tests with both RIB types.
First, we will test export-rib. Juniper’s KB16133 defines the export-rib as such:
“The export-rib command tells the router, from which tables to take information. For any individual RIB group, only one table can be specified in the export-rib statement.”
This means that export-rib should only work with exchanging routes between two tables.
To test export-rib groups we will attempt the following configurations:
- Apply an export-rib group to a table to verify export-rib is working as intended
- Apply an export-rib group to the same table which it’s configured for
- Apply an export-rib group to multiple tables
Secondly, we will test import-rib. Juniper’s KB16133 defines the import-rib as such:
“Conversely, the import-rib command tells the router, into which tables to place information. Unlike its counterpart, the import-rib statement can specify multiple route tables.”
In the same KB article explains that the first routing table in an import-rib group is the source routing table and each subsequent routing table(s) are destination routing tables. This implies that the first routing table defined will be copied to the destination tables listed after. Jack Parks also concluded the same reasoning on the j-net forums.
To test import-rib groups we will attempt the following configurations.
- Apply an import-rib group to a table to verify it’s working as intended (include source and destination tables).
- Apply the import-rib group to the source table
- Only provide a source table but no destinations table
- Apply the import-rib to a different table than the source (a table not listed in the group)
- Define multiple destination tables in the group and assign the group to a single table
- Define multiple destination tables in the group and assign the group to a multiple table.
- Do routes that are present in the routing table because of a RIB group qualify to then be copied to another routing table?
If you're looking for the results, they're at the bottom of this post. Otherwise, continue on for a long winded post
Initial configuration:
[edit]
root@srx-core# show interfaces
ge-0/0/0 {
unit 0 {
family inet {
address 192.168.1.200/24;
}
}
}
ge-0/0/1 {
vlan-tagging;
unit 0 {
vlan-id 200;
family inet {
address 10.100.0.1/24;
}
}
unit 1 {
vlan-id 201;
family inet {
address 10.101.1.254/24;
}
}
unit 2 {
vlan-id 202;
family inet {
address 10.101.2.254/24;
}
}
unit 3 {
vlan-id 203;
family inet {
address 10.101.3.254/24;
}
}
unit 4 {
vlan-id 204;
family inet {
address 10.101.4.254/24;
}
}
unit 11 {
vlan-id 11;
family inet {
address 172.16.1.1/24;
}
}
unit 12 {
vlan-id 12;
family inet {
address 172.16.2.1/24;
}
}
}
[edit]
root@srx-core# show routing-instances
test1 {
instance-type virtual-router;
interface ge-0/0/1.11;
}
test2 {
instance-type virtual-router;
interface ge-0/0/1.12;
}
Export-rib Test 1
Apply an export-rib group to a table to verify export-rib is working as intended
[edit]
root@srx-core# set routing-options rib-groups export-test export-rib test1.inet.0
[edit]
root@srx-core# set routing-instances test2 routing-options interface-routes rib-group inet export-test
[edit]
root@srx-core# commit
[edit routing-instances test2 routing-options interface-routes]
'rib-group'
export-test: primary rib for instance test2 was not found in ribgroup configuration.
error: configuration check-out failed
Well that’s strange. Let’s see if we can use the same group in the test1.inet.0 table
[edit]
root@srx-core# delete routing-instances test2 routing-options interface-routes rib-group inet export-test
[edit]
root@srx-core# set routing-instances test1 routing-options interface-routes rib-group inet export-test
[edit]
root@srx-core# commit
[edit routing-instances test1 routing-options interface-routes]
'rib-group'
export-test: primary rib for instance test1 was not found in ribgroup configuration.
error: configuration check-out failed
[edit]
root@srx-core# delete routing-instances test1 routing-options interface-routes rib-group inet export-test
[edit]
root@srx-core# set routing-options interface-routes rib-group inet export-test
[edit]
root@srx-core# commit
commit complete
Well it committed without errors. Let’s look at the routing tables and see what happened:
[edit]
root@srx-core# run show route table test1.inet.0
test1.inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.1.0/24 *[Direct/0] 17:38:42
> via ge-0/0/1.11
172.16.1.1/32 *[Local/0] 17:38:42
Local via ge-0/0/1.11
[edit]
root@srx-core# run show route table inet.0
inet.0: 15 destinations, 15 routes (15 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.0.0/24 *[OSPF/10] 21:43:04, metric 12
> to 192.168.1.1 via ge-0/0/0.0
10.0.1.16/28 *[OSPF/10] 21:43:04, metric 11
> to 192.168.1.1 via ge-0/0/0.0
10.100.0.0/24 *[Direct/0] 21:43:11
> via ge-0/0/1.0
10.100.0.1/32 *[Local/0] 21:43:13
Local via ge-0/0/1.0
10.101.1.0/24 *[Direct/0] 21:43:11
> via ge-0/0/1.1
10.101.1.254/32 *[Local/0] 21:43:13
Local via ge-0/0/1.1
10.101.2.0/24 *[Direct/0] 21:43:11
> via ge-0/0/1.2
10.101.2.254/32 *[Local/0] 21:43:13
Local via ge-0/0/1.2
10.101.3.0/24 *[Direct/0] 21:43:11
> via ge-0/0/1.3
10.101.3.254/32 *[Local/0] 21:43:13
Local via ge-0/0/1.3
10.101.4.0/24 *[Direct/0] 21:43:11
> via ge-0/0/1.4
10.101.4.254/32 *[Local/0] 21:43:13
Local via ge-0/0/1.4
192.168.1.0/24 *[Direct/0] 21:43:11
> via ge-0/0/0.0
192.168.1.200/32 *[Local/0] 21:43:13
Local via ge-0/0/0.0
224.0.0.5/32 *[OSPF/10] 21:43:22, metric 1
MultiRecv
[edit]
root@srx-core#
It appears there has been no change in either the routing table used in the rib group or the table to which it was applied.
[edit]
root@srx-core# delete routing-options interface-routes
[edit]
root@srx-core# set routing-options rib-groups export-test export-rib inet.0
[edit]
root@srx-core# set routing-instances test1 routing-options interface-routes rib-group inet export-test
[edit]
root@srx-core# commit
[edit routing-instances test1 routing-options interface-routes]
'rib-group'
export-test: primary rib for instance test1 was not found in ribgroup configuration.
error: configuration check-out failed
Well that was a waste of time.
Export-rib rule #1 : They don’t workExport-rib rule #2 : The Junos Enterprise Routing book doesn’t even mention the existence of export-rib groups
Export-rib rule #3 : Searching Google for export-rib examples is futile
Let’s move on to something at least productive.
Remotely-Triggered Black Hole (RTBH) Routing
When the infrastructure is protected and stabilized, investigation can take full force and original sources of the attack identified and prevented from further denial of service attack at the intended target.
What I described above are the guiding ideas between two types of DoS protection mechanisms using remote triggered black hole filtering, also known in the industry as RTBH filtering. These two types are destination and source based RTBH filtering.
Here are some brief characteristics of both.
- Destination Based RTBH:
- Requires knowledge of the target (victim) address/network.
- Willingly sacrifices (black-holes) the communication of the target with the rest of the world.
- Relies on BGP to “signal” black-hole from trigger to one or more enforcers – usually edge (border) routers in the network.
- Uses unreachable next-hop to drop packets to the destination.
- Source-Based RTBH:
- Requires knowledge of the attack source/sources.
- Attack sources are unable to communicate with the entire protected infrastructure, not only the intended victims.
- Relies on BGP to “signal” black-hole from trigger to one or more enforcers – usually edge (border) routers in the network.
- Uses Unicast Reverse Path Forwarding (uRPF) to drop packets.
BGP unequal cost load balancing
With multipath, the distribution of routes would be almost even (50-50) to both ISP1 and ISP2. However when you want to override this default behavior, you tag the incoming prefixes with BANDWIDTH community to distribute unequal prefixes to ISP1 and ISP2.
Based on these bandwidth attribute, router internally calculates on how the distribution of these prefixes to ISP1 and ISP2.
multipath = Equal distribution to ISP1 and ISP2
multipath+bandwidth = Unequal distribution based on the bandwidth tag
Read moreIOS and JunOS commands
BGP looking glass
BGP Looking Glass servers are computers on the Internet running one of a variety of publicly available Looking Glass software implementations. A Looking Glass server (or LG server) is accessed remotely for the purpose of viewing routing info. Essentially, the server acts as a limited, read-only portal to routers of whatever organization is running the Looking Glass server. Typically, publicly accessible looking glass servers are run by ISPs or NOCs.
Click 'Read more' to see the list of BGP Looking glass servers accessible via telnet.
Category 2 - IPv4 and IPv6 BGP Route Servers by region (TELNET access)
Please send additions and updates to webmaster@bgp4.as, thanks!
LAB: Configuring MPLS in the Service Provider Network
MPLS lab with MP-BGP running between PE routers and RipV2 running in the core as well as with customers.
Read more
Anycast Addressing on the Internet
Anycast addressing is a useful technique for providing redundancy and load sharing to specific types of network services on the Internet. Anycast addressing is nothing more than assigning a common IP address to multiple instances of the same service, which are located at strategic points in the overal network topology. By utilizing the underlying routing infrastructure of the Internet, IP packets are forwarded to the nearest instance of an anycast service. Common network services that can most easily take advantage of anycast addressing include DNS, multicast rendezvous points (RPs), syslog, network flow export, IPv6 to IPv4 relay routers and sink hole networks.
This article will briefly examine what anycast addressing is all about, where it is used and some of the technical considerations involved in an anycast deployment. The focus here is on anycast addressing as used by the IPv4 Internet. IPv6 provides a similar, but operationally unique service called anycast that will not be discussed here. The author's area of expertise is with internetworking and information security. He has experience in anycast addressing for RPs in multicast-enabled networks and has just begun to embark on a trial anycast DNS deployment
Read moreIPV4 DNS Anycast
These documents describe how IP version 4 (IPV4) anycast works, how you can deploy this technology for improving load balancing and security for DNS services in your network, and provides specific configuration instructions for implementation.
This document is intended for network design architects, support engineers, and marketing professionals who are responsible for planning, designing, implementing, and operating networks.
The following is a list of PDF documents:
Source: http://wikipedia.org