Håvard Ose Nordstrand %!s(int64=2) %!d(string=hai) anos
pai
achega
9117577ba3

+ 2 - 1
index.md

@@ -99,7 +99,7 @@ _(Alphabetically sorted, so the ordering might seem a bit strange.)_
 ## Network
 
 - [Network Architecture](/networking/architecture/)
-- [BGP](/networking/bgp/)
+- [Border Gateway Protocol (BGP)](/networking/bgp/)
 - [Brocade FastIron Switches](/networking/brocade-fastiron-switches/)
 - [Cisco Application Centric Infrastructure (ACI)](/networking/cisco-aci/)
 - [Cisco Digital Network Architecture (DNA)](/networking/cisco-dna/)
@@ -123,6 +123,7 @@ _(Alphabetically sorted, so the ordering might seem a bit strange.)_
 - [Juniper EX Series Switches](/networking/juniper-junos-switches/)
 - [Linksys LGS Switches](/networking/linksys-lgs/)
 - [Linux Switching & Routing](/networking/linux/)
+- [Open Shortest Path First (OSPF)](/networking/ospf/)
 - [pfSense](/networking/pfsense/)
 - [Routing](/networking/routing/)
 - [Network Security](/networking/security/)

+ 1 - 1
networking/architecture.md

@@ -22,7 +22,7 @@ breadcrumbs:
     - L2 switches.
     - Connected to clients.
     - Typically one access-layer VLAN spans one or a few access switches.
-    - Should implement first-hop security.
+    - Should implement first-hop security (MAC, IPv4, IPv6).
     - Connected upstream to distribution switches.
 - Distribution layer:
     - Aka "distro" layer.

+ 6 - 2
networking/bgp.md

@@ -1,5 +1,5 @@
 ---
-title: BGP
+title: Border Gateway Protocol (BGP)
 breadcrumbs:
 - title: Network
 ---
@@ -34,7 +34,7 @@ breadcrumbs:
 - Letter of Agency (aka Letter of Authorization) (LOA) required in certain countries to be allowed to announce a prefix.
 - The "default-free zone" (DFZ) is the set of ASes which have full-ish BGP tables instead of default routes.
 - Communities are used to exchange arbitrary policy information for announcements between peers. See [BGP Well-known Communities (IANA)](https://www.iana.org/assignments/bgp-well-known-communities/bgp-well-known-communities.xhtml).
-- "Soft reconfiguration" is a feature to cache all incoming raw announcements from peers, such that the BGP table can be quickly rebuilt if it needs to be cleared. This reduces the impact of clearing the table and is recommended, but does increase memory usage.
+- "Soft reconfiguration" (IOS: `neighbor <ip> soft-reconfiguration inbound`) is a feature to cache all incoming raw announcements from peers, such that the BGP table can be quickly rebuilt if it needs to be cleared. This reduces the impact of clearing the table and is recommended, but does increase memory usage.
 
 ## Attributes
 
@@ -130,5 +130,9 @@ The path selection algorithm is used to select a single best path for a prefix.
 - Use and support the graceful shutdown community: The well-known community GRACEFUL_SHUTDOWN (65535:0) is used to signal graceful shutdown of announced routes. Peers should support this community by adding a policy matching the community, which reduces the LOCAL_PREF to 0 or similar such that other paths are preferred and installed in the routing table, to eliminate the impact when the router finally shuts down the session. See RFC 8326.
 - Use and support the blackhole community: The well-known community BLACKHOLE (65535:666) is used to signal that the peer should discard traffic destined toward the prefix. This is mainly intended to stop DDoS attacks targeting the certain prefix before reaching the router advertising it, such that other non-targeted traffic may continue to use the link. While announced prefixes should generally avoid exceeding a certain max length, announcements with the blackhole community are typically allowed to be as specific as possible to narrow down the blackhole addresses (e.g. /32 for IPv4 and /128 for IPv6). See RFC 7999.
 - Add reject-by-default policies to avoid leaking routes when no policies have been explicitly defined.
+- Use Soft reconfiguration (IOS: `neighbor <ip> soft-reconfiguration inbound`) to avoid temporary downtime if the BGP process is restarted or the table is cleared.
+- Which neighbor IP address to normally use:
+    - eBGP: Use the linknet address to avoid having to setup routing for the neighbor loopback address, except for special HA/LB setups.
+    - iBGP: Use the loopback address, which should be learned from an IGP. Set `neighbor <ip> update-source Loopback0` (IOS) to use the loopback address for routing.
 
 {% include footer.md %}

+ 2 - 2
networking/cisco-general.md

@@ -95,13 +95,13 @@ General Cisco networking equipment stuff.
     - `peer-keepalive destination <dst-ip> source <src-ip> vrf <vrf>` configures the keep-alive link for some interface with the given linknet IP address within the given VRF.
     - `vpc peer link` (interface) configures the peer link for the current interface (e.g. a trunk LAG).
     - `auto-recovery` (domain) allows the secondary peer to become primary after the peer link and then the and keep-alive link has gone down (e.g. if the previous primary has gone down, in that degredation order).
-    - `auto-recovery reload-delay <240-3600>` (domain) allows any peer to become primary of the keep-alive link does not come up after a delay (e.g. when booting both devices).
+    - `auto-recovery reload-delay <60-3600>` (domain) allows any peer to become primary of the keep-alive link does not come up after a delay (e.g. when booting both devices).
     - `peer-switch` (domain) should be used to share the STP virtual bridge ID and send BPDUs from both peers. This should only be used if the peers together are the roots of all VLAN STP trees.
     - `peer-gateway` (domain) may be used to allow one peer to forward packets on behalf of the other peer, in cases where the destination MAC address of a packet targets one peer but the packet is actually received on the other peer (e.g. caused by a bad host implementation). This avoids connectivity issues caused by packets arriving at the wrong peer and the loop avoidance causing them to be dropped by the other peer (when transferred over the peer link). If the peers are meant to participate in routing protocol adjacencies, then `layer3 peer-router` must be enabled immediately afterwards to avoid flapping.
     - `layer3 peer-router` (domain) may be used to enable routing protocol adjacencies over vPCs with both peers. On a technical level, this allows forwarding routing packets with a TTL of 1 across the peer link without decrementing it. PIM adjacencies are not supported while using this. Requires `peer-gateway` to be active. `no layer3 peer-router syslog` (domain) may be set to prevent certain pointless `VPC-2-L3_VPC_UNEQUAL_WEIGHT` syslog messages.
     - `ip arp synchronize` and `ipv6 nd synchronize` (domain) enable ARP and ND synchronization, to reduce convergence times after faults.
 - Member port configuration:
-    - `vpc <n>` (interface) configures the port-cannel as a member. It must use the same vPC number on both peers. The port-channel ID may be used as the vPC ID for consistency.
+    - `vpc <n>` (pc-interface) configures the port-cannel as a member. It must use the same vPC number on both peers. The port-channel ID may be used as the vPC ID for consistency. The port must be configured as switchport.
 - Orphan port configuration:
     - `vpc orphan-ports suspend` (interface) brings down the orphan port if the peer link goes down, similar to member ports. Useful e.g. for devices with active-passive uplinks to both peers.
 - Operation:

+ 11 - 1
networking/cisco-ios-switches.md

@@ -182,6 +182,16 @@ An example of a full configuration.
 - Show blocked VLANS: `sh span summary`
 - Show STP neighbors: `` **TODO**
 
+### IPv4 First-Hop Security
+
+**TODO**: DHCP snooping, MAC checking etc.
+
+### IPv6 First-Hop Security
+
+- Binding table:
+    - Built by ND and DHCP snooping/gleaning and used by guard features.
+- Destination guard: **TODO**
+
 ## Features
 
 ### VLAN Trunking Protocol (VTP)
@@ -215,7 +225,7 @@ An example of a full configuration.
 
 Hold the "mode" button for 30 seconds or until it says in the console that it's restarting and clearing the configuration.
 
-## Information
+## Miscellanea
 
 ### Ports and VLANs
 

+ 25 - 1
networking/ipv6.md

@@ -11,6 +11,7 @@ breadcrumbs:
 - [IETF RFC 7755: SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Center Environments](https://www.rfc-editor.org/rfc/rfc7755.html)
 - [IETF RFC 7934 (BCP 204): Host Address Availability Recommendations](https://datatracker.ietf.org/doc/html/rfc7934)
 - [IETF RFC 8200 (STD 86): Internet Protocol, Version 6 (IPv6) Specification](https://datatracker.ietf.org/doc/html/rfc8200)
+- [APNIC: IPv6 Best Current Practices](https://www.apnic.net/community/ipv6-program/ipv6-bcp/)
 
 ## Special Prefixes
 
@@ -386,6 +387,8 @@ breadcrumbs:
 
 ## Address Planning and Implementation
 
+***OUTDATED***
+
 - It should support both IPv4 and IPv6.
 - IPv6 should be native.
 - IPv4 may be provided through dual stack or as a service using translation or tunneling mechanisms.
@@ -423,7 +426,12 @@ breadcrumbs:
 - Use provisioning tools (IPAM).
 - Don't mirror the IPv4 address plan with all of its legacy problems.
 - Plan both for now and for the future.
-- Try to subnet on nibble boundaries since a nibble is one hex digit.
+- Subnet on nibble boundaries.
+    - Makes the address plan clearer since one nibble is one hexadecimal digit, so you avoid ranges within a digit and so you probably won't need a subnet calculator with a little bit of practice.
+    - Can *roughly* be compared with subnetting on bit boundaries for IPv4, since the address space is four times larger.
+    - Makes the address plan much more uniform while only sacrificing a small bit of granularity.
+    - Allows for DNS reverse zones that match exactly the prefixes.
+- Leave space for future expansion within prefixes. Avoid having to create multiple prefixes for the same purpose due to lack of space.
 - GUA VS ULA.
 - SLAAC VS DHCP.
     - Android and Chrome OS does not support SLAAC, by design.
@@ -441,4 +449,20 @@ breadcrumbs:
     - Potentally lower costs if the ISPs offer different prices for different services.
     - IPv6 supports native multihoming since interfaces can be assigned multiple prefixes from different routers.
 
+### Philip Smith: IPv6 Address Planning (2012)
+
+*IPv6 BCP according to APNIC.*
+
+- Focus on scalability and ease of use/application of security policies and network management.
+- IPv6 allows creating a more flexible address plan.
+- Always segment on nibble boundaries. Makes it simpler.
+- Allocate:
+    - One /48 for the infrastructure and other "units". Allocate separate ones for customer links at each PoP.
+    - Use the first /48 for infrastructure, to keep important addresses short.
+    - Within each /48, allocate all loopbacks within the first /64.
+    - Allocate linknets as separate /64s but address as /127.
+    - Allocate /64s for each LAN.
+- Customers generally get a /48.
+- Design a scheme to keep some structure.
+
 {% include footer.md %}

+ 86 - 0
networking/ospf.md

@@ -0,0 +1,86 @@
+---
+title: Open Shortest Path First (OSPF)
+breadcrumbs:
+- title: Network
+---
+{% include header.md %}
+
+### Related Pages
+{:.no_toc}
+
+- [Routing Theory](../routing/)
+
+## TODO
+
+- OSPFv3.
+- Auth for v2 and v3. Best practices.
+- Always redistribute into OSPF as external type 1 to allow updating OSPF metric (type 2, NSSA external, does not).
+
+
+
+## Theory
+
+### General
+
+- A link-state (LS) IGP, using Dijkstra's algorithm individually on all routers to calculate the shortest paths.
+- The metric used to calculate path lengths is the cumulative link cost, where the link costs are generally based on the capacity of the links.
+    - Cisco uses a rather low reference bandwidth where 100Mb/s Ethernet and everything above has the same cost of 1. This reference can be adjusted using the `ospf auto-cost reference-bandwidth <x>` command or apropriately setting `ip ospf cost <x>` for each interface.
+
+### Areas
+
+- Uses a two-tier hierarchy consisting of a backbone area (area 0) and zero or more regular areas.
+- Regular areas can only be connected to the backbone area and not to eachother.
+    - If a non-backbone router is connected to multiple areas, it will not become an ABR for the areas and it will not redistribute LSAs between them. Routes and LSAs will be kept separate. This design should probably be avoided.
+- Area IDs are 32-bit numbers represented in decimal or dotted decimal.
+- **Backbone area**:
+    - "Main" area (area 0), connected to all other areas.
+- **Regular area**:
+    - Any non-backbone area.
+- **Stub area**:
+    - Configured as `stub` (IOS) on the ABRs.
+    - For areas with external routes (i.e. ASBRs).
+    - Prevents external LSAs from flooding into the area and makes the ABR generate default route LSAs into the area, while still alowing normal summary LSAs from other areas.
+    - Don't support virtual links.
+- **Totally stubby area** (Cisco variant):
+    - Configured as `stub no-summary` (IOS) on the ABRs.
+    - Just like a stub area, but blocks summary LSAs (type 3 and 4) in addition to external LSAs.
+    - Only the default route generated by the ABRs is used.
+- **Not so stubby area (NSSA)**:
+    - Configured as `nssa` (IOS) on the ABRs.
+    - Like a stub area (no external LSAs flooded *into* it), but allows external routes (i.e. it allows ASBRs).
+    - The ASBRs generate NSSA external LSAs (type 7), which are translated to external LSAs (type 5) at the ABRs.
+    - NSSAs may be used to summarize external routes before they're distributed into the backbone area.
+    - Among the stub area types, this one is typically the most appropriate.
+- **Totally NSSA** (Cisco variant):
+    - Configured as `nssa no-summary` (IOS) on the ABRs.
+    - Like an NSSA, but without summary LSAs, like a totally stubby area.
+
+### Routers
+
+- Area boundaries in OSPF are through routers (not between), so OSPF routers have interfaces in one or more areas.
+- **Backbone router**:
+    - A router with an interface in the backbone area.
+    - Maintains state information about all backbone links, all summary links and all external links.
+- **Internal router**:
+    - A router with all interfaces inside a single area.
+- **Area border router (ABR)**:
+    - A router with interfaces in multiple areas.
+    - Is implicitly always a backbone router.
+    - May summarize routes for one of the areas.
+- **AS boundary router (ASBR)**:
+    - A router that imports routing information from another AS as external routes.
+    - Does not need to be a backbone router.
+    - May summorize external routes.
+
+### Link State Advertisements (LSAs)
+
+- LSAs contain link state information and are flooded to all routers in an area and partially to other areas.
+- LSA types:
+    - **Router LSA** (**type 1**): For XXX. Flooded to XXX.
+    - **Network LSA** (**type 2**):
+    - **Summary LSA** (**type 3**):
+    - **ASBR summary LSA** (**type 4**):
+    - **External LSA** (type 5**) (**external type 1**):
+    - **NSSA external LSA** (**type 7**) (**external type 2**):
+
+{% include footer.md %}