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:

Notes from a Juniper Junos troubleshooting course

Packets reaching the irb interface trigger a routing lookup.

When using vMX, typically in a lab, then there should be two VMs: one for the control plane and one for the forwarding plane, named something like vmx1-vcp and vmx1-vfp respectively.

When pinging the IP address of an aggregate Ethernet interface, the ICMP Echo Reply packets are duplicated:

lab@vEX> ping 172.16.200.2 count 3    
PING 172.16.200.2 (172.16.200.2): 56 data bytes
64 bytes from 172.16.200.2: icmp_seq=0 ttl=63 time=3.034 ms
64 bytes from 172.16.200.2: icmp_seq=0 ttl=63 time=3.209 ms (DUP!)
64 bytes from 172.16.200.2: icmp_seq=0 ttl=63 time=3.251 ms (DUP!)
64 bytes from 172.16.200.2: icmp_seq=0 ttl=63 time=3.295 ms (DUP!)
64 bytes from 172.16.200.2: icmp_seq=0 ttl=63 time=3.346 ms (DUP!)
64 bytes from 172.16.200.2: icmp_seq=0 ttl=63 time=3.387 ms (DUP!)
64 bytes from 172.16.200.2: icmp_seq=0 ttl=63 time=3.418 ms (DUP!)
64 bytes from 172.16.200.2: icmp_seq=0 ttl=63 time=3.448 ms (DUP!)
64 bytes from 172.16.200.2: icmp_seq=1 ttl=63 time=3.641 ms
64 bytes from 172.16.200.2: icmp_seq=1 ttl=63 time=3.688 ms (DUP!)
64 bytes from 172.16.200.2: icmp_seq=1 ttl=63 time=3.711 ms (DUP!)
64 bytes from 172.16.200.2: icmp_seq=1 ttl=63 time=3.717 ms (DUP!)
64 bytes from 172.16.200.2: icmp_seq=1 ttl=63 time=3.871 ms (DUP!)
64 bytes from 172.16.200.2: icmp_seq=1 ttl=63 time=3.883 ms (DUP!)
64 bytes from 172.16.200.2: icmp_seq=1 ttl=63 time=3.919 ms (DUP!)
64 bytes from 172.16.200.2: icmp_seq=1 ttl=63 time=3.923 ms (DUP!)
64 bytes from 172.16.200.2: icmp_seq=2 ttl=63 time=2.626 ms

--- 172.16.200.2 ping statistics ---
3 packets transmitted, 3 packets received, +14 duplicates, 0% packet loss
round-trip min/avg/max/stddev = 2.626/3.492/3.923/0.343 ms

lab@vEX> 

The ‘hot swappable’ and ‘hot pluggable’ are chassis capabilities and are not the same.

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:

replacing UCS B-series blade servers that are managed by UCSM requires their decommission and deletion from the inventory of UCSM first. The new blade servers must be commissioned with UCSM.

Note: CIMC vs UCSM and Intersight

• When a UCS C-series rackmount server is managed by UCSM, it can no longer be managed by CIMC.
• Only UCS C-series rackmount servers that are in standalone mode can be managed through CIMC.

Register a UCS C-series rackmount server in UCSM

A new UCS C-series rackmount server comes pre-configured to integrate with UCSM through the connection to the FIs. Once the UCS C-series server is cabled to the FIs, I wait for some minutes and I will see the server pop up in the UCSM page:

common concepts

• L4-7 service insertion common concepts
• service function(s)
• Service Type: firewall, ADC.

service device

• L4-7 Logical Device aka L4-7 Cluster Device, is composed of Concrete Devices, has a relationship with the Service Type, has L4-7 Service Device Interfaces aka cluster Interfaces; consumer-side interfaces and provider-side interfaces.
• Service Bridge Domains

service graph

• Service Graph management modes
• Service Graph template: used in Standard Service Graphs and in Service Graph Redirects (PBR)

multi-node service insertion with service graphs

• failover traffic management
• active-active firewall cluster:
  • L1, L2 or go-through mode: not supported
  • go-to mode:
    • active-active firewall cluster in multi-site design
    • active-active firewall cluster in single-pod and multi-pod designs
• active-standby firewall cluster:
  • in ACI single-pod designs
    • go-to mode
  • in ACI multi-pod designs
    • with VRF sandwich and L3Outs
    • go-to mode
  • in ACI multi-site designs
    • with Standard Service Graphs
    • with Service Graph Redirect

Exam Objectives

• Understand and use essential tools
  • Access a shell prompt and issue commands with correct syntax
  • Use input-output redirection (>, », |, 2>, etc.)
  • Use grep and regular expressions to analyze text
  • Access remote systems using SSH
  • Log in and switch users in multi-user targets
  • Archive, compress, unpack, and uncompress files using tar, gzip, and bzip2
  • Create and edit text files
  • Create, delete, copy, and move files and directories
  • Create hard and soft links
  • List, set, and change standard ugo/rwx permissions
  • Locate, read, and use system documentation including man, info, and files in /usr/share/doc

Manage software

- Configure access to RPM repositories
- Install and remove RPM software packages
- Configure access to Flatpak repositories
- Install and remove Flatpak software packages

Create simple shell scripts

- Conditionally execute code (use of: if, test, [], etc.)
- Use Looping constructs (for, etc.) to process file, command line input
- Process script inputs ($1, $2, etc.)
- Processing output of shell commands within a script

Operate running systems

- Boot, reboot, and shut down a system normally
- Boot systems into different targets manually
- Interrupt the boot process in order to gain access to a system
- Identify CPU/memory intensive processes and kill processes
- Adjust  process scheduling
- Manage tuning profiles
- Locate and interpret system log files and journals
- Preserve system journals
- Start, stop, and check the status of network services
- Securely transfer files between systems

Configure local storage

• List, create, and delete partitions on GPT disks

aka Network Stitching. This is the manual method to insert L4-7 services; VLANs, EPGs and bridge domains are manually created, and EPGs are manually assigned to the L4-7 device interfaces, statically with Static Path Binding or dynamically with a VMM domain. If we have to insert more than one L4-7 device, repeat the above process as much as there are devices to integrate.

L4-7 device vs L4-7 Device

An L4-7 device in the manual stitching context is one firewall, one ADC, etc. A L4-7 Device in Service Graphs is the Logical Device, which might contain one or more Concrete Devices.

If I configure the IP default gateways of the (Provider, Consumer) pair on ACI and attach an L4-7 Device to ACI, IP routing traffic involving the (Provider, Consumer) pair will bypass the Service Device due to routing in ACI itself. To circumvent that, there are three known methods to force traffic toward the L4-7 Device.

Method 1: NAT on the L4-7 Device

Method 2: SGR (no NAT on the L4-7 Device)

Method 3: VRF Sandwich and L3Outs

No NAT on the L4-7 Device.

Certificates

Issuing a Digital Certificate

Certificate server, Certificate Authority. The entities that want the CA to issue a digital certificate for them must send their public key, their IP address and their FQDN to the CA. The CA replies with a digital certificate, aka identity certificate, aka public key certificate which means ‘I certify that the entity named in this certificate own the public key mentioned in this digital certificate.’ The digital certificate does not last forever; It has a validity period. The digital certificate is a file with the extension .cer.