packet capture on Junos operational mode

Packet capture in real time on an interface is performed with the monitor command:

lab@vSRX> monitor traffic interface fxp0 ?
Possible completions:
  <[Enter]>            Execute this command
  absolute-sequence    Display absolute TCP sequence numbers
  brief                Display brief output
  count                Number of packets to receive (0..1000000 packets)
  detail               Display detailed output
  extensive            Display extensive output
  layer2-headers       Display link-level header on each dump line
  matching             Expression for headers of receive packets to match
  no-domain-names      Don't display domain portion of hostnames
  no-promiscuous       Don't put interface into promiscuous mode
  no-resolve           Don't attempt to print addresses symbolically
  no-timestamp         Don't print timestamp on each dump line
  print-ascii          Display packets in ASCII when displaying in hexadecimal format
  print-hex            Display packets in hexadecimal format
  read-file            Read packets from a given file
  resolve-timeout      Period of time to wait for each name resolution (seconds)
  size                 Amount of each packet to receive (bytes)
  write-file           Write packets to specified file
  |                    Pipe through a command
lab@vSRX> monitor traffic interface fxp0 write-file capture01.pcap 
Address resolution is ON. Use <no-resolve> to avoid any reverse lookup delay.
Address resolution timeout is 4s.
Listening on fxp0, capture size 96 bytes

^C
297 packets received by filter
0 packets dropped by kernel

lab@vSRX>

lab@vSRX> file list 

/var/home/lab/:
.lesshst
.ssh/
capture01.pcap
jt /

lab@vSRX> 

Then I open the freeBSD CLI and open the pcap file using tcpdump:

Next Hop Values

On R2, verify that there is a BGP route to 1.1.1.1.

user1@R2>
user1@R2> show route 1.1.1.1

inet.0: 15 destinations, 15 routes (15 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

1.1.1.1/32         *[BGP/170] 5d 13:58:29, localpref 100
                      AS path: 17 17 17 17 I, validation-state: unverified
                    >  to 10.10.10.1 via ge-0/0/1.0

On R1, configure static route to 10.22.1.32/27 with next-hop 10.10.10.2, preference 6. The ping from R1’s loopback to R2’s 10.22.1.34 interface must succeed. How RIB looks like, when a static route is configured with a next hop set to the IP address of the directly-attached host:

verifying sent and received routes to and from a BGP neighbor

The show route advertising-protocol bgp and show route receive-protocol bgp were my quick way to verify which NLRIs are sent and received with a particular BGP neighbor.

Too much relying on the output of show route advertising-protocol bgp and show route receive-protocol bgp without paying attention to the BGP neighor in the command slowly led me to assume the absence of NLRI exchange between the BGP peers, when the output of those commands is empty. The following example depicts the configuration of iBGP using route reflector technology to build a VXLAN overlay for a leaf-spine topology. Each spine acts as a route reflector to its own client group:

Definition

Firewall filters in Juniper Junos are stateless packet filters that act pretty much like the access lists in Cisco IOS, IOS XE and NX-OS. Once configured, they must be assigned in the input or output direction of one or more interfaces to become effective.

Example scenario: preventing ping packets to be initiated from one direction while allowing the other direction

Topology

R1:ge-0/0/5(.1) <— 10.10.7.0/30 —> (.2)ge-0.0.1:R5

Configuration

On R5:

OSPF in Junos

lab@vSRX> show configuration interfaces ge-0/0/2 
unit 0 {
    family inet {
        address 192.168.11.2/24;
    }
}

lab@vSRX> show configuration protocols ospf 
area 0.0.0.0 {
    interface ge-0/0/2.0;
}

lab@vSRX> 

lab@vSRX> show ospf interface 
Interface           State   Area            DR ID           BDR ID          Nbrs
ge-0/0/2.0          BDR     0.0.0.0         192.168.1.1     192.168.31.1       1

lab@vSRX> 

lab@vSRX> show ospf neighbor 
Address          Interface              State           ID               Pri  Dead
192.168.11.1     ge-0/0/2.0             Full            192.168.1.1      128    39

lab@vSRX>

lab@vSRX> show route protocol ospf  

inet.0: 24 destinations, 38 routes (24 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

192.168.1.1/32     *[OSPF/10] 01:58:32, metric 1
                    >  to 192.168.11.1 via ge-0/0/2.0
224.0.0.5/32       *[OSPF/10] 01:58:42, metric 1
                       MultiRecv

inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)

lab@vSRX>

MTU mismatch

lab@vSRX> show ospf neighbor 
Address          Interface              State           ID               Pri  Dead
192.168.11.1     ge-0/0/2.0             ExStart         192.168.1.1      128    35

lab@vSRX>

lab@vSRX> show interfaces ge-0/0/2 | match mtu 
  Link-level type: Ethernet, MTU: 1400, LAN-PHY mode, Link-mode: Full-duplex, Speed: 10Gbps,
    Protocol inet, MTU: 1386

lab@vSRX> show configuration interfaces ge-0/0/2 | display inheritance 
##
## '1400' was inherited from group 'group1'
##
mtu 1400;
unit 0 {
    family inet {
        ##
        ## 'no-neighbor-learn' was inherited from group 'group1'
        ##
        no-neighbor-learn;
        address 192.168.11.2/24 {
            arp 192.168.11.1 mac 00:50:56:a9:50:92;
        }
    }
}

lab@vSRX> 

lab@vMX-2> show interfaces ge-0/0/2 | match mtu 
  Link-level type: Ethernet, MTU: 1514, MRU: 1522, LAN-PHY mode, Speed: 1000mbps, BPDU Error: None,
    Protocol inet, MTU: 1500
    Protocol multiservice, MTU: Unlimited

lab@vMX-2> 

lab@vMX-2> show configuration interfaces ge-0/0/2 | display inheritance 
description "vr1 to vsrx1";
unit 0 {
    family inet {
        address 192.168.11.1/24;
    }
}

lab@vMX-2> 

The solution in this case is to change the MTU value of the physical interface on either side of the link: