Juniper Tips 37: How to apply packet filter

1. Build a firewall filter

0> show configuration firewall family inet filter CPE1
from {
source-address {; }
then {
count CPE1;

from {
source-address {;
destination-port 2055;
then {

then {

2. Apply Filter into the intended interface

> show configuration interfaces ge-0/0/0.100
family inet {
filter {
input-list [ COMMON-FILTER CPE1 ];
service {
input { service-set NAT-GROUP-1; }
output {service-set NAT-GROUP-1; }

 3. Verify the filter

since the filter was applied as the filter set. It will not show the counter, as the single filter can be used in multiple interfaces.

#show firewall filter

Filter: gr-0/0/0.100-i
Name Bytes Packets
ALLOW-BGP-gr-0/0/0.100-i 2165275 43751
ALLOW-ICMP-gr-0/0/0.100-i 2436 29
ALLOW-NETFLOW-gr-0/0/0.100-i 5195740 31641
ALLOW-REMOTE-GRE-PACKET-gr-0/0/0.100-i 2874504 119771
CPE1-gr-0/0/0.100-i 844762395 7679678
DROP-ALL-ELSE-gr-0/0/0.100-i 2780 88
GRE-KEEPALIVE-gr-0/0/0.100-i 0 0

#show firewall filter CPE1 <-which only work if one filter in place

Filter: CPE1
Name Bytes Packets
CPE1 0 0

Hacking Tools 1: hping


Step 1: Install tcl-dev using command “sudo apt-get install tcl-dev”

or you will run into error during make.

/usr/bin/ld: cannot find -ltcl8.5
collect2: ld returned 1 exit status

Step 2 : Fix the warning message from TCL scripting support.

#hping3-20051105$ ./configure
build byteorder.c…
create byteorder.h…
===> Found Tclsh in: /usr/bin/tclsh8.4
==> WARNING: no Tcl header files found!
system type: LINUX

LIBPCAP      : PCAP=-lpcap
MANPATH      : /usr/local/man
USE_TCL      :
TCL_VER      : 8.4
TCL_INC      :
LIBTCL       : -ltcl8.5 -lm -lpthread
TCLSH        : /usr/bin/tclsh8.4

(to modify try configure –help)
creating Makefile…
creating dependences…
now you can try `make’

or you will run into error when run hping command.

Sorry, this hping binary was compiled without TCL scripting support

go back to step 1. recompile with TCL support.

$ sudo find / -name “tcl.h”

It’s running on tcl8.5, the configure script does not have 8.5 support. need to be modified.

for TCLPATH_TRY in “/usr/bin/” “/usr/local/bin/” “/bin/”
  for TCLVER_TRY in “8.5” “8.4” “8.2” “8.1” “8.0”
if [ -z $TCLSH ]
if [ -f $TCLSH_TRY ]
echo “===> Found Tclsh in: $TCLSH”

Step 3:  Install libpcap-dev by using command “sudo apt-get install libpcap-dev”

Otherwise you will run into error during make.

fatal error: pcap.h: No such file or directory compilation terminated.

Step 4: Creating softlink for net/bpf.h

#find / -name “bpf.h”

# sudo ln -s /usr/include/pcap/bpf.h /usr/include/net/bpf.h

libpcap_stuff.c:20:21: net/bpf.h: No such file or directory
make: *** [libpcap_stuff.o] Error 1

And it should work now!


Hping Examples:

/hping3 -S -V -s 7550 -p 339

-S Syn Packet, -F fin, -R RST, -U URG, -P PUSH, -A ACK,

-V verbose output, -s source port, -p destination port

If the port is not listening, you will receive RST ACK instead of SA.

hping3 –rand-source –S –L 0 –p <target port> <target IP>Here we are sending SYN packets (set value by replacing 0) with a random source.

hping3 –rand-source –SA –p <open port> <target IP>Here we are sending SYN + ACK packets from a random source.
hping3 –rand-source -–udp <target IP> –floodFlooding the target IP with UDP packets.
hping3 –rand-source –SAFRU –L 0 –M 0 –p <port> <target> — we are sending SYN+ACK+FIN+RST+URG packets with TCP ack (-L) and TCP seq (-M). Change the values after -L and -M.
hping3 –icmp –spoof <target address> <broadcast address> –floodFlooding with ICMP packets by spoofed IP (–spoof).

Ubuntu Tips 16: How to upgrade from an older version

I was seeing errors from apt-get install or apt-get update like:

W: Failed to fetch  404  Not Found

And errors from apt-get upgrade like:

Err oneiric-updates/main ncurses-bin i386 5.9-1ubuntu5.1
403  Forbidden

Luckily ubuntu provides a repository for old releases, aptly named To use it, open /etc/apt/sources.list replace all occurrences of or as the following.

deb oneiric main
deb-src oneiric main
deb oneiric-updates main
deb-src oneiric-updates main
deb oneiric universe
deb-src oneiric universe
deb oneiric-updates universe
deb-src oneiric-updates universe
deb oneiric-security main
deb-src oneiric-security main
deb oneiric-security universe
deb-src oneiric-security universe

Now you should run a full update to the latest release:

$ sudo do-release-update


Juniper Tips 36: How to use Tag to control route advertisement over BGP

1. Control receiving route from Peer1

#edit policy-option policy-statement From-PEER1

term 1 {
    from {
        route-filter exact; <-route-filter is more flexible than one statement, can be a collection of matching prefixes. When specifying a match prefix, you can specify an exact match with a particular route or a less precise match. You can configure either a common action that applies to the entire list or an action associated with each prefix.
    then {
        tag 1111;
term 2 {
    then reject;

#edit configuration protocols bgp group PEER1
type external;
import From-PEER1; <-control what to accept
peer-as 65534;

#show route receive-protocol bgp all

inet.0: 153 destinations, 153 routes (152 active, 0 holddown, 1 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
*       0                  65534 I       0                  65534 I <-this’s hidden route, since it does not match to the rule, which has been dropped.

2. Control advertising out route to PEER2

#Edit policy-options policy-statement To-PEER2


    from tag 1111;
    then accept;
    from {
        route-filter exact;
        condition gr-status1;
    then accept;
    from {
        route-filter orlonger;

        route-filter longer; (does not include
        route-filter prefix-length-range /26–/28 ; (only 172.8.100/26,/27,/28 are matching
        condition gr-status_521;

condition gr-status1 {
    if-route-exists {;
        table inet.0;
condition gr-status_521 {
    if-route-exists {;
        table inet.0;
  then accept;
    then reject;

#edit protocol bgp group PEER2

type external;
export To-PEER2; <-Control what to export to Peer2
peer-as 65060;

#show route advertising-protocol bgp

inet.0: 153 destinations, 153 routes (152 active, 0 holddown, 1 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
*          Self                                    I
*          Self                                    65534 I
*         Self                                    I


IGMP is a network layer (Layer 3) protocol used to establish membership in a Multicast group and can register a router to receive specific Multicast traffic. (Refer to RFC 1112 and RFC 2236 for information on IGMP versions 1 and 2.)


IGMP operates between the client computer and a local multicast router. Switches featuring IGMP snooping derive useful information by observing these IGMP transactions. Protocol Independent Multicast (PIM) is then used between the local and remote multicast routers, to direct multicast traffic from the multicast server to many multicast clients.

IGMP operates on the network layer, just the same as other network management protocols like ICMP.

The IGMP protocol is implemented on a particular host and within a router. A host requests membership to a group through its local router while a router listens for these requests and periodically sends out subscription queries.

Multicast filtering is achieved by dynamic group control management. By default, all Multicast traffic should be blocked until requested by a Multicast group member. The master of the IGMP filter lists is the router or switch that is configured to act as the IGMP Querier. The responsibility of the Querier is to send out IGMP group membership queries on a timed interval, to retrieve IGMP membership reports from active members, and to allow updating of the group membership tables.

A Layer 2 switch supporting IGMP Snooping can passively snoop on IGMP Query, Report, and Leave (IGMP version 2) packets transferred between IP Multicast routers/switches and IP Multicast hosts to determine the IP Multicast group membership. IGMP snooping checks IGMP packets passing through the network, picks out the group registration, and configures Multicasting accordingly.

Without IGMP Querying/Snooping, Multicast traffic is treated in the same manner as a Broadcast transmission, which forwards packets to all ports on the network. With IGMP Querying/Snooping, Multicast traffic is only forwarded to ports that are members of that Multicast group. IGMP Snooping generates no additional network traffic, which significantly reduces the Multicast traffic passing through your switch.