Public time servers that can be used as time sources by anyone.
== the server that provides time to the enterprise NTP clients usually connects to an internet time server
An NTP node that receives time from an NTP server When it loses its connection to the NTP server, it requests time from the other available NTP peer(s).
(do a blog search for “service_insertion”)
The default host-based firewall in RHEL allows all outgoing connections and blocks all incoming ones, except those explicitely permitted.
The firewall daemon is called firewalld. To interact with it, use the firewall-cmd tool. The firewalld daemon translates the instructions of firewall-cmd into policies that use the syntax of the kernel’s netfilter and nftables.
A rule dictates that a service is allowed to be accessed by an inbound connection. A firewalld service is added with firewall-cmd --add-service or removed with firewall-cmd --remove-service.
Name resolution in Linux is a pipeline of verification jobs, not a single file: a process consults the Name Service Switch, which has a configuration file at /etc/nsswitchconf. This file contains a list of entries. Each entry describes a database and the list of sources to refer to in the order of their appearance in the entry.
An entry is written in this format: DatabaseName NameService1 [Status=Action] NameService2
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:
Syslogs contain subsets of information on faults, events, audit & session data, all related the monitored objects. Not all logs depict errors. Syslog can include audit and event logs.
Any program or process capable of generating syslogs.
aka syslog severity levels or syslog priorities. The describe different levels of importance. Example of syslog severities: emergency, alert, critical, informational, warnings.
Verify the version of rsyslogd deployed on a RHEL machine:
graph LR
net1(LAN1_172.17.99.0/24)
net1 <--> R1
R1 <--> |WAN1_10.10.10.8/30|R4
Desired outcome: I want to configure a generated route on R1 for the prefix 172.17.99.0. Currently, the prefix 172.17.99.0/24 is directly attached to ge-0/0/6. I want to make R1 advertise the generated route 172.17.96.0/19 toward its BGP neighbor R4 only when R1 receives the BGP route 10.22.1.0/26 from R4 (which is configured as an aggregate route on R4) and successfully imports it from BGP into inet.0. On R1, at the moment there is only one contributing route for the generated route, which is 17.17.99.0/24.
graph LR
net1(LAN1_172.17.99.0/24)
net1 <--> R1
R1 <--> |WAN1_10.10.10.8/30|R4
The default next hop of an aggregate route is reject:
root@R4> show configuration routing-options rib inet.0 aggregate
defaults {
preference 189;
}
route 10.22.1.0/26;
root@R4>
root@R4> show route protocol aggregate
inet.0: 15 destinations, 17 routes (15 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.22.1.0/26 *[Aggregate/189] 00:00:58
Reject
inet6.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
root@R4>
root@R4> show route 10.22.1.0/26 exact detail
inet.0: 15 destinations, 17 routes (15 active, 0 holddown, 0 hidden)
10.22.1.0/26 (1 entry, 1 announced)
*Aggregate Preference: 189
Next hop type: Reject, Next hop index: 0
Address: 0x77c5434
Next-hop reference count: 2
Kernel Table Id: 0
State: <Active Int Ext>
Local AS: 22
Age: 7:22
Validation State: unverified
Task: Aggregate
Announcement bits (2): 0-KRT 5-Resolve tree 3
AS path: I (LocalAgg)
Flags: Depth: 0 Active
AS path list:
AS path: I Refcount: 2
Contributing Routes (2):
10.22.1.0/27 proto Direct
10.22.1.32/27 proto Static
Thread: junos-main
root@R4>
#LessonLearned The contributing routes may be of different routing protocols or pseudoprotocols.
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:
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:
CIMC is the management interface of the server hardware that underlies the APIC software.
CIMC software != APIC software.
Connect your laptop to the console port of the APIC server (usually the RJ-45 port at the far right). Use baud rate of 115200 (or configure that as speed under the async interface, if you’re connecting to CIMC through terminal services)