├── .gitignore ├── .travis.yml ├── Makefile ├── README.md ├── additional-resources.rst ├── conf.py ├── configs ├── deployment-and-management │ ├── issu.cfg │ └── sflow.cfg └── mclag │ ├── iccp.output │ ├── lldp.output │ ├── ospf.output │ ├── ping.output │ ├── qfx1.cfg │ ├── qfx2.cfg │ ├── qfx3.cfg │ └── qfx4.cfg ├── contributors.rst ├── dc-deployment-and-management.rst ├── docs ├── CNAME ├── _sources │ ├── additional-resources.rst.txt │ ├── contributors.rst.txt │ ├── dc-deployment-and-management.rst.txt │ ├── index.rst.txt │ ├── lab-objectives.rst.txt │ ├── layer-2-fabrics.rst.txt │ ├── layer-3-fabrics.rst.txt │ ├── mc-lag.rst.txt │ ├── vxlan-evpn.rst.txt │ └── vxlan.rst.txt ├── additional-resources.html ├── contributors.html ├── dc-deployment-and-management.html ├── genindex.html ├── index.html ├── jncip-dc-notes.pdf ├── lab-objectives.html ├── layer-2-fabrics.html ├── layer-3-fabrics.html ├── mc-lag.html ├── objects.inv ├── search.html ├── searchindex.js ├── static │ ├── ajax-loader.gif │ ├── alabaster.css │ ├── basic.css │ ├── comment-bright.png │ ├── comment-close.png │ ├── comment.png │ ├── custom.css │ ├── doctools.js │ ├── documentation_options.js │ ├── down-pressed.png │ ├── down.png │ ├── file.png │ ├── jquery-3.2.1.js │ ├── jquery.js │ ├── language_data.js │ ├── minus.png │ ├── plus.png │ ├── pygments.css │ ├── searchtools.js │ ├── underscore-1.3.1.js │ ├── underscore.js │ ├── up-pressed.png │ ├── up.png │ └── websupport.js ├── vxlan-evpn.html └── vxlan.html ├── index.rst ├── lab-objectives.rst ├── layer-2-fabrics.rst ├── layer-3-fabrics.rst ├── mc-lag.rst ├── requirements.txt ├── vxlan-evpn.rst └── vxlan.rst /.gitignore: -------------------------------------------------------------------------------- 1 | # Ignore Sphinx dirs 2 | _build/ 3 | _templates/ 4 | 5 | # Ignore vscode 6 | .vscode/ 7 | 8 | # Ignore virtualenv 9 | .venv/ 10 | -------------------------------------------------------------------------------- /.travis.yml: -------------------------------------------------------------------------------- 1 | sudo: false 2 | language: python 3 | python: 4 | - "3.6" 5 | cache: pip 6 | script: 7 | - '[[ "${TRAVIS_COMMIT_MESSAGE}" == *"Deploy"* ]] && exit 0 || true' 8 | - make publish 9 | branches: 10 | only: 11 | - master 12 | deploy: 13 | provider: pages 14 | target_branch: master 15 | email: code@tylerc.me 16 | name: Deployment Bot 17 | skip_cleanup: true 18 | github_token: $GITHUB_TOKEN 19 | keep_history: true 20 | on: 21 | branch: master 22 | -------------------------------------------------------------------------------- /Makefile: -------------------------------------------------------------------------------- 1 | # Minimal makefile for Sphinx documentation 2 | # 3 | 4 | # You can set these variables from the command line. 5 | SPHINXOPTS = 6 | SPHINXBUILD = sphinx-build 7 | SOURCEDIR = . 8 | BUILDDIR = _build 9 | 10 | # Put it first so that "make" without argument is like "make help". 11 | help: 12 | @$(SPHINXBUILD) -M help "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O) 13 | 14 | .PHONY: help Makefile 15 | 16 | prepare: 17 | mv docs/jncip-dc-notes.pdf ./jncip-dc-notes.pdf 18 | 19 | clean: 20 | rm -rf _build/* 21 | rm -rf docs/* 22 | html: 23 | @$(SPHINXBUILD) -M html "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O) 24 | mv _build/html/* docs/ 25 | mv docs/_static docs/static 26 | for i in `ls docs/*.html`; do sed -i -e 's/_static/static/g' $$i; done 27 | for i in `ls docs/*.html`; do sed -i -e 's,static/jquery.js,https://code.jquery.com/jquery-3.4.1.min.js,g' $$i; done 28 | 29 | pdf: 30 | @$(SPHINXBUILD) -M rinoh "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O) 31 | mv jncip-dc-notes.pdf docs/jncip-dc-notes.pdf || true 32 | [ `du -k "_build/rinoh/jncip-dc-notes.pdf"` -eq `du -k "docs/jncip-dc-notes.pdf"` ] && exit 0 || true 33 | mv _build/rinoh/jncip-dc-notes.pdf docs/ 34 | 35 | publish: prepare clean html pdf 36 | echo "jncip-dc.tylerc.me" > docs/CNAME 37 | 38 | # Catch-all target: route all unknown targets to Sphinx using the new 39 | # "make mode" option. $(O) is meant as a shortcut for $(SPHINXOPTS). 40 | %: Makefile 41 | @$(SPHINXBUILD) -M $@ "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O) 42 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # UNMAINTAINED 2 | 3 | Some of these notes are probably still valid, at least to some degree. 4 | However, the exam has changed significantly since this was written. I 5 | don't have the time to maintain these notes, so I'm archiving the repo. 6 | 7 | # jncip-dc-notes 8 | 9 | This repository contains both the source and the compiled HTML for 10 | https://jncip-dc.tylerc.me, a set of notes on the 11 | [JNCIP-DC exam](https://www.juniper.net/us/en/training/certification/certification-tracks/data-center-track?tab=jncip-dc). 12 | 13 | ## Genesis 14 | 15 | I'm studying for the JNCIP-DC, JNCDA, and JNCDS-DC. I needed to take 16 | notes, and so I spent some time investigating the best way I could take 17 | notes. I had a few requirements from the start: 18 | 19 | - I'm a Linux user, so Microsoft Word was out 20 | - I wanted to write in a markup language of some sort because I didn't 21 | want to worry so much about formatting and presentation, so Evernote 22 | was out 23 | - I wanted to have a call out to specific areas of interest, so Markdown 24 | was out 25 | - I wanted to focus on content and not markup, so LaTeX was out 26 | 27 | Given these requirements (and the subsequent ruling out of other 28 | systems), I settled on ReStructured Text (RST). I had used Sphinx in 29 | the past to generate API documentation, so I set to work determining if 30 | I could use Sphinx to generate a prettier version of my notes. As it 31 | turns out, I can. Learning just enough RST wasn't too difficult, 32 | either. 33 | 34 | ## Contributing 35 | 36 | The sections below describe some areas where I'm looking for 37 | contributions. In general, just open an issue here in GitHub to start 38 | the dialogue. 39 | 40 | Ultimately, contributions are welcome either in the form of pull 41 | requests that offer direct updates to the source or GitHub issues that 42 | lead to updates and contributions to this project. In either case, I 43 | will update the list of 44 | [Contributors](https://jncip-dc.tylerc.me/contributors.html) unless 45 | explicitly requested otherwise. 46 | 47 | ### Diagrams 48 | 49 | Unfortunately, being a Linux user has (to date) been the source of a 50 | significant struggle: diagrams. I'm not good at them to begin with, but 51 | beyond this, there isn't a Linux application that _really_ works 52 | anywhere near as well as Visio. Are there those that can accomplish the 53 | same goals? Sure. Are they as easy as Visio? Nope. And so this 54 | entire project's biggest shortcoming is a current lack of diagrams. 55 | 56 | If you're great at making diagrams, this is an area where I would love 57 | some help. Contributions and collaboration would be most welcome. This 58 | is the area where I could use the most help. 59 | 60 | ### Labs 61 | 62 | More labs are always better. I would love to see this become a 63 | community-driven lab book! I will be contributing my own for each 64 | topic, but they may not be exhaustive or in-depth. Some of them might 65 | just scratch the surface, particularly if I happen to know an area well 66 | already. 67 | 68 | ### Other Content 69 | 70 | This project has started as a place for me to take my notes while 71 | studying. This naturally means that I might gloss over certain topics 72 | because I already have familiarity with them. For this reason, another 73 | area would I would welcome community contribution is additional content. 74 | This might be expanding on an area that is already covered or 75 | introducing an entirely new section. 76 | 77 | ### Technical Corrections 78 | 79 | I also welcome technical corrections. My only request is that if a 80 | technical correction is offered, a source be provided. I've tried to 81 | find (and sometimes document) where I've found certain information, so 82 | I'd like to have authoritative sources. 83 | -------------------------------------------------------------------------------- /conf.py: -------------------------------------------------------------------------------- 1 | # Configuration file for the Sphinx documentation builder. 2 | # 3 | # This file only contains a selection of the most common options. For a full 4 | # list see the documentation: 5 | # http://www.sphinx-doc.org/en/master/config 6 | 7 | # -- Path setup -------------------------------------------------------------- 8 | 9 | # If extensions (or modules to document with autodoc) are in another directory, 10 | # add these directories to sys.path here. If the directory is relative to the 11 | # documentation root, use os.path.abspath to make it absolute, like shown here. 12 | # 13 | # import os 14 | # import sys 15 | # sys.path.insert(0, os.path.abspath('.')) 16 | 17 | 18 | # -- Project information ----------------------------------------------------- 19 | 20 | project = 'jncip-dc-notes' 21 | copyright = '2019, Tyler Christiansen' 22 | author = 'Tyler Christiansen' 23 | description = 'JNCIP-DC Study Notes' 24 | 25 | # -- General configuration --------------------------------------------------- 26 | 27 | # Add any Sphinx extension module names here, as strings. They can be 28 | # extensions coming with Sphinx (named 'sphinx.ext.*') or your custom 29 | # ones. 30 | extensions = ['sphinx.ext.autodoc', 'rinoh.frontend.sphinx'] 31 | 32 | master_doc = 'index' 33 | 34 | # Add any paths that contain templates here, relative to this directory. 35 | templates_path = ['_templates'] 36 | 37 | # List of patterns, relative to source directory, that match files and 38 | # directories to ignore when looking for source files. 39 | # This pattern also affects html_static_path and html_extra_path. 40 | exclude_patterns = ['_build', 'Thumbs.db', '.DS_Store', '.venv'] 41 | 42 | pdf_documents = [('index', project, description, author),] 43 | 44 | 45 | # -- Options for HTML output ------------------------------------------------- 46 | 47 | # The theme to use for HTML and HTML Help pages. See the documentation for 48 | # a list of builtin themes. 49 | # 50 | html_theme = 'alabaster' 51 | 52 | # Add any paths that contain custom static files (such as style sheets) here, 53 | # relative to this directory. They are copied after the builtin static files, 54 | # so a file named "default.css" will overwrite the builtin "default.css". 55 | html_static_path = ['static'] 56 | 57 | latex_elements = { 58 | 'papersize': 'letterpaper', 59 | 'pointsize': '10pt', 60 | 'preamble': '', 61 | 'figure_align': 'htbp' 62 | } 63 | -------------------------------------------------------------------------------- /configs/deployment-and-management/issu.cfg: -------------------------------------------------------------------------------- 1 | system { 2 | commit synchronize; 3 | } 4 | chassis { 5 | redundancy { 6 | graceful-switchover; 7 | } 8 | } 9 | routing-options { 10 | nonstop-routing; 11 | } 12 | protocols { 13 | layer2-control { 14 | nonstop-bridging; 15 | } 16 | } -------------------------------------------------------------------------------- /configs/deployment-and-management/sflow.cfg: -------------------------------------------------------------------------------- 1 | protocols { 2 | sflow { 3 | polling-interval 10; 4 | sample-rate { 5 | ingress 50; 6 | egress 50; 7 | } 8 | collector 10.0.0.30 { 9 | udp-port 9000; 10 | } 11 | interfaces xe-0/0/0.0; 12 | } 13 | } -------------------------------------------------------------------------------- /configs/mclag/iccp.output: -------------------------------------------------------------------------------- 1 | root@vQFX-1> show iccp 2 | 3 | Redundancy Group Information for peer 10.0.0.1 4 | TCP Connection : Established 5 | Liveliness Detection : Up 6 | Redundancy Group ID Status 7 | 100 Up 8 | 9 | Client Application: lacpd 10 | Redundancy Group IDs Joined: None 11 | 12 | Client Application: MCSNOOPD 13 | Redundancy Group IDs Joined: None 14 | 15 | Client Application: l2ald_iccpd_client 16 | Redundancy Group IDs Joined: None 17 | 18 | {master:0} 19 | 20 | root@vQFX-2> show iccp 21 | 22 | Redundancy Group Information for peer 10.0.0.0 23 | TCP Connection : Established 24 | Liveliness Detection : Up 25 | Redundancy Group ID Status 26 | 100 Up 27 | 28 | Client Application: lacpd 29 | Redundancy Group IDs Joined: None 30 | 31 | Client Application: MCSNOOPD 32 | Redundancy Group IDs Joined: None 33 | 34 | Client Application: l2ald_iccpd_client 35 | Redundancy Group IDs Joined: None 36 | 37 | {master:0} -------------------------------------------------------------------------------- /configs/mclag/lldp.output: -------------------------------------------------------------------------------- 1 | root@vQFX-1> show lldp neighbors 2 | Local Interface Parent Interface Chassis Id Port info System Name 3 | xe-0/0/0 ae0 02:05:86:71:68:00 xe-0/0/0 vQFX-2 4 | xe-0/0/1 ae0 02:05:86:71:68:00 xe-0/0/1 vQFX-2 5 | xe-0/0/2 ae1 02:05:86:71:bc:00 xe-0/0/2 vQFX-3 6 | xe-0/0/3 ae2 02:05:86:71:c5:00 xe-0/0/3 vQFX-4 7 | {master:0} 8 | 9 | root@vQFX-2> show lldp neighbors 10 | Local Interface Parent Interface Chassis Id Port info System Name 11 | xe-0/0/4 ae1 02:05:86:71:bc:00 xe-0/0/4 vQFX-3 12 | xe-0/0/5 ae2 02:05:86:71:c5:00 xe-0/0/5 vQFX-4 13 | xe-0/0/1 ae0 02:05:86:71:fa:00 xe-0/0/1 vQFX-1 14 | xe-0/0/0 ae0 02:05:86:71:fa:00 xe-0/0/0 vQFX-1 15 | 16 | {master:0} 17 | 18 | root@vQFX-3> show lldp neighbors 19 | Local Interface Parent Interface Chassis Id Port info System Name 20 | xe-0/0/4 ae0 02:05:86:71:68:00 xe-0/0/4 vQFX-2 21 | xe-0/0/2 ae0 02:05:86:71:fa:00 xe-0/0/2 vQFX-1 22 | 23 | {master:0} 24 | 25 | root@vQFX-4> show lldp neighbors 26 | Local Interface Parent Interface Chassis Id Port info System Name 27 | xe-0/0/5 ae0 02:05:86:71:68:00 xe-0/0/5 vQFX-2 28 | xe-0/0/3 ae0 02:05:86:71:fa:00 xe-0/0/3 vQFX-1 29 | 30 | {master:0} -------------------------------------------------------------------------------- /configs/mclag/ospf.output: -------------------------------------------------------------------------------- 1 | root@vQFX-1> show ospf neighbor 2 | Address Interface State ID Pri Dead 3 | 192.168.200.4 irb.2000 Full 4.4.4.4 128 30 4 | 192.168.200.3 irb.2000 Full 2.2.2.2 128 36 5 | 6 | {master:0} 7 | 8 | root@vQFX-2> show ospf neighbor 9 | Address Interface State ID Pri Dead 10 | 192.168.200.4 irb.2000 Full 4.4.4.4 128 32 11 | 192.168.200.2 irb.2000 Full 1.1.1.1 128 34 12 | 13 | {master:0} 14 | 15 | root@vQFX-4> show ospf neighbor 16 | Address Interface State ID Pri Dead 17 | 192.168.200.2 ae0.0 Full 1.1.1.1 128 33 18 | 192.168.200.3 ae0.0 Full 2.2.2.2 128 39 19 | 20 | {master:0} -------------------------------------------------------------------------------- /configs/mclag/ping.output: -------------------------------------------------------------------------------- 1 | root@vQFX-3> ping 192.168.100.0 rapid count 5 2 | PING 192.168.100.0 (192.168.100.0): 56 data bytes 3 | !!!!! 4 | --- 192.168.100.0 ping statistics --- 5 | 5 packets transmitted, 5 packets received, 0% packet loss 6 | round-trip min/avg/max/stddev = 306.100/365.522/380.486/29.711 ms 7 | 8 | {master:0} 9 | 10 | root@vQFX-3> ping 192.168.200.4 rapid count 5 11 | PING 192.168.200.4 (192.168.200.4): 56 data bytes 12 | !!!!! 13 | --- 192.168.200.4 ping statistics --- 14 | 5 packets transmitted, 5 packets received, 0% packet loss 15 | round-trip min/avg/max/stddev = 239.258/425.293/601.453/129.111 ms 16 | 17 | {master:0} 18 | 19 | root@vQFX-4> ping 192.168.100.1 rapid count 5 20 | PING 192.168.100.1 (192.168.100.1): 56 data bytes 21 | !!!!! 22 | --- 192.168.100.1 ping statistics --- 23 | 5 packets transmitted, 5 packets received, 0% packet loss 24 | round-trip min/avg/max/stddev = 114.584/234.628/287.023/67.643 ms 25 | 26 | {master:0} -------------------------------------------------------------------------------- /configs/mclag/qfx1.cfg: -------------------------------------------------------------------------------- 1 | # qfx1 2 | chassis { 3 | aggregated-devices { 4 | ethernet { 5 | device-count 3; 6 | } 7 | } 8 | } 9 | interfaces { 10 | xe-0/0/0 { 11 | ether-options { 12 | 802.3ad ae0; 13 | } 14 | } 15 | xe-0/0/1 { 16 | ether-options { 17 | 802.3ad ae0; 18 | } 19 | } 20 | xe-0/0/2 { 21 | ether-options { 22 | 802.3ad ae1; 23 | } 24 | } 25 | xe-0/0/3 { 26 | ether-options { 27 | 802.3ad ae2; 28 | } 29 | } 30 | ae0 { 31 | aggregated-ether-options { 32 | lacp { 33 | active; 34 | periodic slow; 35 | } 36 | } 37 | unit 0 { 38 | family ethernet-switching { 39 | interface-mode trunk; 40 | vlan { 41 | members all; 42 | } 43 | } 44 | } 45 | } 46 | ae1 { 47 | aggregated-ether-options { 48 | lacp { 49 | active; 50 | periodic slow; 51 | system-id 00:00:00:11:11:11; 52 | admin-key 1; 53 | } 54 | mc-ae { 55 | mc-ae-id 1; 56 | redundancy-group 100; 57 | chassis-id 0; 58 | mode active-active; 59 | status-control active; 60 | init-delay-time 15; 61 | } 62 | } 63 | unit 0 { 64 | family ethernet-switching { 65 | interface-mode access; 66 | vlan { 67 | members v1000; 68 | } 69 | } 70 | } 71 | } 72 | ae2 { 73 | aggregated-ether-options { 74 | lacp { 75 | active; 76 | periodic slow; 77 | system-id 00:00:00:22:22:22; 78 | admin-key 2; 79 | } 80 | mc-ae { 81 | mc-ae-id 2; 82 | redundancy-group 100; 83 | chassis-id 1; 84 | mode active-active; 85 | status-control standby; 86 | init-delay-time 15; 87 | } 88 | } 89 | unit 0 { 90 | family ethernet-switching { 91 | interface-mode access; 92 | vlan { 93 | members v2000; 94 | } 95 | } 96 | } 97 | } 98 | irb { 99 | unit 100 { 100 | family inet { 101 | address 10.0.0.0/31; 102 | } 103 | } 104 | unit 1000 { 105 | family inet { 106 | address 192.168.100.0/31; 107 | } 108 | } 109 | unit 2000 { 110 | family inet { 111 | address 192.168.200.2/29 { 112 | arp 192.168.200.3 l2-interface ae0.0 mac 02:05:86:71:93:00; 113 | vrrp-group 1 { 114 | virtual-address 192.168.200.1; 115 | priority 200; 116 | accept-data; 117 | } 118 | } 119 | } 120 | } 121 | } 122 | } 123 | multi-chassis { 124 | multi-chassis-protection 10.0.0.1 { 125 | interface ae0; 126 | } 127 | } 128 | routing-options { 129 | router-id 1.1.1.1; 130 | } 131 | protocols { 132 | ospf { 133 | area 0.0.0.0 { 134 | interface irb.2000; 135 | interface irb.1000 { 136 | passive; 137 | } 138 | } 139 | } 140 | iccp { 141 | local-ip-addr 10.0.0.0; 142 | peer 10.0.0.1 { 143 | session-establishment-hold-time 50; 144 | redundancy-group-id-list 100; 145 | liveness-detection { 146 | minimum-receive-interval 300; 147 | transmit-interval { 148 | minimum-interval 300; 149 | } 150 | } 151 | } 152 | } 153 | rstp { 154 | interface ae0 { 155 | disable; 156 | } 157 | interface ae1 { 158 | edge; 159 | } 160 | interface ae2 { 161 | edge; 162 | } 163 | interface all { 164 | mode point-to-point; 165 | } 166 | bpdu-block-on-edge; 167 | } 168 | } 169 | switch-options { 170 | service-id 1; 171 | } 172 | vlans { 173 | v100 { 174 | vlan-id 100; 175 | l3-interface irb.100; 176 | } 177 | v1000 { 178 | vlan-id 1000; 179 | l3-interface irb.1000; 180 | mcae-mac-synchronize; 181 | } 182 | v2000 { 183 | vlan-id 2000; 184 | l3-interface irb.2000; 185 | } 186 | } -------------------------------------------------------------------------------- /configs/mclag/qfx2.cfg: -------------------------------------------------------------------------------- 1 | # qfx2 2 | chassis { 3 | aggregated-devices { 4 | ethernet { 5 | device-count 3; 6 | } 7 | } 8 | } 9 | interfaces { 10 | xe-0/0/0 { 11 | ether-options { 12 | 802.3ad ae0; 13 | } 14 | } 15 | xe-0/0/1 { 16 | ether-options { 17 | 802.3ad ae0; 18 | } 19 | } 20 | xe-0/0/4 { 21 | ether-options { 22 | 802.3ad ae1; 23 | } 24 | } 25 | xe-0/0/5 { 26 | ether-options { 27 | 802.3ad ae2; 28 | } 29 | } 30 | ae0 { 31 | aggregated-ether-options { 32 | lacp { 33 | active; 34 | periodic slow; 35 | } 36 | } 37 | unit 0 { 38 | family ethernet-switching { 39 | interface-mode trunk; 40 | vlan { 41 | members all; 42 | } 43 | } 44 | } 45 | } 46 | ae1 { 47 | aggregated-ether-options { 48 | lacp { 49 | active; 50 | periodic slow; 51 | system-id 00:00:00:11:11:11; 52 | admin-key 1; 53 | } 54 | mc-ae { 55 | mc-ae-id 1; 56 | redundancy-group 100; 57 | chassis-id 1; 58 | mode active-active; 59 | status-control standby; 60 | init-delay-time 15; 61 | } 62 | } 63 | unit 0 { 64 | family ethernet-switching { 65 | interface-mode access; 66 | vlan { 67 | members v1000; 68 | } 69 | } 70 | } 71 | } 72 | ae2 { 73 | aggregated-ether-options { 74 | lacp { 75 | active; 76 | periodic slow; 77 | system-id 00:00:00:22:22:22; 78 | admin-key 2; 79 | } 80 | mc-ae { 81 | mc-ae-id 2; 82 | redundancy-group 100; 83 | chassis-id 0; 84 | mode active-active; 85 | status-control active; 86 | init-delay-time 15; 87 | } 88 | } 89 | unit 0 { 90 | family ethernet-switching { 91 | interface-mode access; 92 | vlan { 93 | members v2000; 94 | } 95 | } 96 | } 97 | } 98 | irb { 99 | unit 100 { 100 | family inet { 101 | address 10.0.0.1/31; 102 | } 103 | } 104 | unit 1000 { 105 | family inet { 106 | address 192.168.100.0/31; 107 | } 108 | } 109 | unit 2000 { 110 | family inet { 111 | address 192.168.200.3/29 { 112 | arp 192.168.200.2 l2-interface ae0.0 mac 02:05:86:71:62:00; 113 | vrrp-group 1 { 114 | virtual-address 192.168.200.1; 115 | priority 100; 116 | accept-data; 117 | } 118 | } 119 | } 120 | } 121 | } 122 | } 123 | multi-chassis { 124 | multi-chassis-protection 10.0.0.0 { 125 | interface ae0; 126 | } 127 | } 128 | routing-options { 129 | router-id 2.2.2.2; 130 | } 131 | protocols { 132 | ospf { 133 | area 0.0.0.0 { 134 | interface irb.2000; 135 | interface irb.1000 { 136 | passive; 137 | } 138 | } 139 | } 140 | iccp { 141 | local-ip-addr 10.0.0.1; 142 | peer 10.0.0.0 { 143 | session-establishment-hold-time 50; 144 | redundancy-group-id-list 100; 145 | liveness-detection { 146 | minimum-receive-interval 300; 147 | transmit-interval { 148 | minimum-interval 300; 149 | } 150 | } 151 | } 152 | } 153 | rstp { 154 | interface ae0 { 155 | disable; 156 | } 157 | interface ae1 { 158 | edge; 159 | } 160 | interface ae2 { 161 | edge; 162 | } 163 | interface all { 164 | mode point-to-point; 165 | } 166 | bpdu-block-on-edge; 167 | } 168 | } 169 | switch-options { 170 | service-id 1; 171 | } 172 | vlans { 173 | v100 { 174 | vlan-id 100; 175 | l3-interface irb.100; 176 | } 177 | v1000 { 178 | vlan-id 1000; 179 | l3-interface irb.1000; 180 | mcae-mac-synchronize; 181 | } 182 | v2000 { 183 | vlan-id 2000; 184 | l3-interface irb.2000; 185 | } 186 | } -------------------------------------------------------------------------------- /configs/mclag/qfx3.cfg: -------------------------------------------------------------------------------- 1 | # vQFX-3 2 | chassis { 3 | aggregated-devices { 4 | ethernet { 5 | device-count 1; 6 | } 7 | } 8 | } 9 | interfaces { 10 | xe-0/0/2 { 11 | ether-options { 12 | 802.3ad ae0; 13 | } 14 | } 15 | xe-0/0/4 { 16 | ether-options { 17 | 802.3ad ae0; 18 | } 19 | } 20 | ae0 { 21 | aggregated-ether-options { 22 | lacp { 23 | active; 24 | periodic slow; 25 | } 26 | } 27 | unit 0 { 28 | family inet { 29 | address 192.168.100.1/31; 30 | } 31 | } 32 | } 33 | } 34 | routing-options { 35 | static { 36 | route 0.0.0.0/0 next-hop 192.168.100.0; 37 | } 38 | router-id 3.3.3.3; 39 | } -------------------------------------------------------------------------------- /configs/mclag/qfx4.cfg: -------------------------------------------------------------------------------- 1 | # vQFX-4 2 | chassis { 3 | aggregated-devices { 4 | ethernet { 5 | device-count 1; 6 | } 7 | } 8 | } 9 | interfaces { 10 | xe-0/0/3 { 11 | ether-options { 12 | 802.3ad ae0; 13 | } 14 | } 15 | xe-0/0/5 { 16 | ether-options { 17 | 802.3ad ae0; 18 | } 19 | } 20 | ae0 { 21 | aggregated-ether-options { 22 | lacp { 23 | active; 24 | periodic slow; 25 | } 26 | } 27 | unit 0 { 28 | family inet { 29 | address 192.168.200.4/29; 30 | } 31 | } 32 | } 33 | } 34 | routing-options { 35 | router-id 4.4.4.4; 36 | } 37 | protocols { 38 | ospf { 39 | area 0.0.0.0 { 40 | interface ae0.0; 41 | } 42 | } 43 | } -------------------------------------------------------------------------------- /contributors.rst: -------------------------------------------------------------------------------- 1 | .. _contributors: 2 | 3 | Contributors 4 | ============ 5 | 6 | This page lists any contributors to these notes, whether they are issues 7 | reported, pull requests submitted, or suggestions made. The following 8 | format is used: 9 | 10 | * (@): 11 | (link to GitHub issue(s) and/or pull request(s)) 12 | 13 | All of this is optional. Anything that is either not relevant or 14 | requested to be left out will not be present in the entry. 15 | 16 | * `Steve Rossen `_ (`@steve `_): It's Saturday night and you are studying: `Issue #1 `_ Closed, Won't Fix. 17 | * `Mircea Ulinic `_ (`@mirceaulinic `_): `#17: Generate PDF document on publishing notes `_ 18 | * `Said van de Klundert `_ (`@saidvandeklunde `_): `#2: Add "Juniper Networks EVPN Implementation for Next-Generation Architectures" to Additional Resources `_ 19 | -------------------------------------------------------------------------------- /dc-deployment-and-management.rst: -------------------------------------------------------------------------------- 1 | Data Center Deployment and Management 2 | ===================================== 3 | 4 | This blueprint item covers a number of topics: 5 | 6 | * :ref:`ztp` 7 | * :ref:`ha` 8 | * :ref:`monitoring` 9 | * :ref:`analytics` 10 | 11 | Unfortunately, the blueprint doesn't indicate to what level those items 12 | should be known, and all of those options seem to require physical 13 | hardware, which I do not have. So this guide will only be theory until 14 | someone contributes configuration sections. 15 | 16 | .. _ztp: 17 | 18 | Zero-Touch Provisioning 19 | ----------------------- 20 | 21 | ZTP is a process for upgrading software and applying configuration 22 | automatically on first boot. This is accomplished by using a stadard 23 | DHCP server with a little bit of extra configuration so that each 24 | ``DISCOVER`` is associated with the correct switch so that the correct 25 | configuration can be retrieved. 26 | 27 | When configuring the DHCP server, the following DHCP options can be 28 | used: 29 | 30 | * ``12``: Switch Hostname 31 | * ``42``: NTP Server 32 | * ``43.00``: Software image filename 33 | * ``43.01``: Configuration file filename 34 | * ``43.02``: Symbolic link flag for filename 35 | * ``43.03``: Transfer mode (HTTP, FTP, TFTP) 36 | * ``43.04``: Alternate software image filename 37 | * ``66``: DNS FQDN for the HTTP/FTP/TFTP server 38 | * ``150``: IP Address for the HTTP/FTP/TFTP server 39 | 40 | The reason that both ``44.00`` and ``44.04`` can both be used is that 41 | some DHCP servers may not support ``44.00``. If both options are 42 | defined, ``44.00`` takes precedence. 43 | 44 | When setting the ``44.00`` or ``44.04`` location to a symlink, you also 45 | need to set the ``44.02`` option to the value ``symlink`` so that the 46 | system knows that the image is a symlink. 47 | 48 | ``44.03`` lets you specify whether the file transfer method will be FTP, 49 | TFTP, or HTTP. The default is TFTP. 50 | 51 | If DHCP options ``66`` and ``150`` are both specified, then ``150`` 52 | takes precedence. 53 | 54 | When the configuration file starts with a shebang (``#!``), Junos will 55 | attempt to run the file as a script. This means you can use one Python 56 | or shell script to dynamically configure your switches instead of 57 | handcrafting a configuration file for each switch. 58 | 59 | By default, a QFX5100 will attempt to perform ZTP through both its 60 | management interface and its revenue ports. This means you can perform 61 | ZTP through a dedicated OOB management network (recommended) or in-band. 62 | 63 | After the switch knows the details of its ZTP process, it first 64 | downloads the required configuration file and then the required software 65 | image (if necessary). If a software image was downloaded, then the 66 | switch performs the software upgrade. Finally, it applies the 67 | configuration file that was downloaded. 68 | 69 | ZTP can also be performed by Junos Space with Network Director. When 70 | this is done, the switch is automatically added to Network Director for 71 | future management. 72 | 73 | For more information on ZTP (including configuration examples), see the 74 | following blogs/articles: 75 | 76 | * `Zero Touch Provisioning: How to Build a Network Without Touching Anything `_ 77 | * `Zero Touch Provisioning on Juniper devices using Linux `_ 78 | 79 | You can also read Chapter 6 of the QFX5100 Series book from O'Reilly [#f1]_. 80 | 81 | .. _ha: 82 | 83 | High Availability 84 | ----------------- 85 | 86 | The QFX5100 has a virtualized control plane. There is a Linux host 87 | running KVM, and Junos runs as a VM. The hypervisor can run up to four 88 | VMs: two of them are reserved for Junos, one is a guest of the 89 | operator's choice, and the last is reserved. 90 | 91 | Each Junos VM has four management interfaces. The first two, ``em0`` 92 | and ``em1``, map to the physical management ports on the switch. The 93 | third, ``em2``, is used for communicating with the hypervisor. The last 94 | interface, ``em3``, is used when performing a Topology-independent 95 | In-Service Software Upgrade, or TISSU. The second Junos VM is only 96 | created during a TISSU. In order to perform a TISSU, NSR, NSB, and GRES 97 | must be configured. 98 | 99 | The high-level process for TISSU is as follows [#f2]_: 100 | 101 | 1: Create the backup Junos VM running the new version requested 102 | 2: Synchronize state between the Junos VMs using ``ksyncd`` 103 | 3: Makes the new VM the master RE 104 | 4: Renames the slot ID of the new VM from ``1`` to ``0`` 105 | 5: The former master Junos VM is shut down 106 | 107 | When performing a TISSU, keep the following in mind: 108 | 109 | * Downgrades and rollbacks are not supported 110 | * TISSU should not be used when transitioning between different base 111 | images (e.g., ``standard`` to ``enhanced-automation``) 112 | * The CLI is inaccessible during a TISSU 113 | * Log files are located in ``/var/log/vjunos-log.tgz`` 114 | * BFD timers need to be >= 1 second [#f3]_ 115 | * ``system internet-options no-tcp-reset drop-all-tcp`` must not be 116 | configured [#f3]_ 117 | 118 | A configuration sample for enabling NSR, NSB, and GRES is below. 119 | 120 | .. literalinclude:: configs/deployment-and-management/issu.cfg 121 | :language: perl 122 | 123 | Once the configuration is in place, you can perform a TISSU with the 124 | ``request system software in-service-upgrade `` command. 125 | 126 | For more information, see Chapter 2 of the Juniper QFX5100 Series book 127 | [#f1]_. 128 | 129 | .. _monitoring: 130 | 131 | Monitoring 132 | ---------- 133 | 134 | Junos supports streaming telemetry as well as more traditional methods 135 | of monitoring such as SNMP. 136 | 137 | TODO: Add configuration for SNMPv2c, SNMPv3, and Streaming Telemetry. 138 | 139 | .. _analytics: 140 | 141 | Analytics 142 | --------- 143 | 144 | The QFX5100 supports two methods of analytics: sFlow and Enhanced 145 | Analytics. These are described below, but it's important to understand 146 | that they should be used together as neither provides the entire picture 147 | on its own. 148 | 149 | sFlow 150 | ^^^^^ 151 | 152 | The QFX5100 supports sFlow, which samples every ``n`` packets. This 153 | sampled data is exported every 1500 bytes or every 250ms. Any alerting 154 | on this data must be performed off-box with the sFlow collector. On the 155 | QFX5100, only switchports can be sampled. Layer 3 interfaces cannot be 156 | sampled. The first 128 bytes of the packet are sampled, and this 157 | includes information such as the source and destination MACs, IPs, and 158 | Ports. Higher sampling rates require more processing power. 159 | 160 | To combat this on high-traffic switches, the QFX5100 can dynamically 161 | adjust sample rates based on interface traffic. This is known as 162 | adaptive sampling. An agent checks the interfaces every 5 seconds. 163 | A list of the top five interfaces is created. An algorithm reduces the 164 | load by half for the top five interfaces and allocates those samples to 165 | lower traffic interfaces. 166 | 167 | An sFlow configuration is shown below. 168 | 169 | .. literalinclude:: configs/deployment-and-management/sflow.cfg 170 | :language: perl 171 | 172 | .. note:: 173 | The ``polling-interval`` tells Junos how frequently, in seconds, to 174 | poll for data; the ``sampling-rate`` tells Junos how many packets to 175 | sample. 176 | 177 | Juniper Enhanced Analytics 178 | ^^^^^^^^^^^^^^^^^^^^^^^^^^ 179 | 180 | The QFX5100 also supports Juniper Enhanced Analytics. This system can 181 | poll as frequently as every 8ms, and data is exported as soon as it is 182 | collected. You can set thresholds on-box down to 1ns. Enhanced 183 | Analytics can monitor: 184 | 185 | * Traffic statistics 186 | * Queue depth 187 | * Latency 188 | * Jitter 189 | 190 | This data can be streamed using the following formats: 191 | 192 | * Protobuf 193 | * JSON 194 | * CSV 195 | * TSV 196 | 197 | Enhanced Analytics is performed by two systems: the Analytics Daemon and 198 | the Analytics Manager. 199 | 200 | The Analytics Daemon (``analyticsd``) collects information from the 201 | Analytics Manager's ring buffers and exports it to collectors. 202 | 203 | The Analytics Manager runs in the PFE and collects the data that is 204 | placed into ring buffers for ``analyticsd`` to collect. 205 | 206 | TODO: Add configuration examples for Enhanced Analytics. 207 | 208 | For more information, see Chapter 9 of the Juniper QFX5100 Series book 209 | [#f1]_. 210 | 211 | .. rubric:: Footnotes 212 | 213 | .. [#f1] `Juniper QFX5100 Series `_ 214 | .. [#f2] `Understanding In-Service Software Upgrade (ISSU) `_ 215 | .. [#f3] `Performing an In-Service Software Upgrade (ISSU) with Non-Stop Routing `_ 216 | -------------------------------------------------------------------------------- /docs/CNAME: -------------------------------------------------------------------------------- 1 | jncip-dc.tylerc.me 2 | -------------------------------------------------------------------------------- /docs/_sources/contributors.rst.txt: -------------------------------------------------------------------------------- 1 | .. _contributors: 2 | 3 | Contributors 4 | ============ 5 | 6 | This page lists any contributors to these notes, whether they are issues 7 | reported, pull requests submitted, or suggestions made. The following 8 | format is used: 9 | 10 | * (@): 11 | (link to GitHub issue(s) and/or pull request(s)) 12 | 13 | All of this is optional. Anything that is either not relevant or 14 | requested to be left out will not be present in the entry. 15 | 16 | * `Steve Rossen `_ (`@steve `_): It's Saturday night and you are studying: `Issue #1 `_ Closed, Won't Fix. 17 | * `Mircea Ulinic `_ (`@mirceaulinic `_): `#17: Generate PDF document on publishing notes `_ 18 | * `Said van de Klundert `_ (`@saidvandeklunde `_): `#2: Add "Juniper Networks EVPN Implementation for Next-Generation Architectures" to Additional Resources `_ 19 | -------------------------------------------------------------------------------- /docs/_sources/dc-deployment-and-management.rst.txt: -------------------------------------------------------------------------------- 1 | Data Center Deployment and Management 2 | ===================================== 3 | 4 | This blueprint item covers a number of topics: 5 | 6 | * :ref:`ztp` 7 | * :ref:`ha` 8 | * :ref:`monitoring` 9 | * :ref:`analytics` 10 | 11 | Unfortunately, the blueprint doesn't indicate to what level those items 12 | should be known, and all of those options seem to require physical 13 | hardware, which I do not have. So this guide will only be theory until 14 | someone contributes configuration sections. 15 | 16 | .. _ztp: 17 | 18 | Zero-Touch Provisioning 19 | ----------------------- 20 | 21 | ZTP is a process for upgrading software and applying configuration 22 | automatically on first boot. This is accomplished by using a stadard 23 | DHCP server with a little bit of extra configuration so that each 24 | ``DISCOVER`` is associated with the correct switch so that the correct 25 | configuration can be retrieved. 26 | 27 | When configuring the DHCP server, the following DHCP options can be 28 | used: 29 | 30 | * ``12``: Switch Hostname 31 | * ``42``: NTP Server 32 | * ``43.00``: Software image filename 33 | * ``43.01``: Configuration file filename 34 | * ``43.02``: Symbolic link flag for filename 35 | * ``43.03``: Transfer mode (HTTP, FTP, TFTP) 36 | * ``43.04``: Alternate software image filename 37 | * ``66``: DNS FQDN for the HTTP/FTP/TFTP server 38 | * ``150``: IP Address for the HTTP/FTP/TFTP server 39 | 40 | The reason that both ``44.00`` and ``44.04`` can both be used is that 41 | some DHCP servers may not support ``44.00``. If both options are 42 | defined, ``44.00`` takes precedence. 43 | 44 | When setting the ``44.00`` or ``44.04`` location to a symlink, you also 45 | need to set the ``44.02`` option to the value ``symlink`` so that the 46 | system knows that the image is a symlink. 47 | 48 | ``44.03`` lets you specify whether the file transfer method will be FTP, 49 | TFTP, or HTTP. The default is TFTP. 50 | 51 | If DHCP options ``66`` and ``150`` are both specified, then ``150`` 52 | takes precedence. 53 | 54 | When the configuration file starts with a shebang (``#!``), Junos will 55 | attempt to run the file as a script. This means you can use one Python 56 | or shell script to dynamically configure your switches instead of 57 | handcrafting a configuration file for each switch. 58 | 59 | By default, a QFX5100 will attempt to perform ZTP through both its 60 | management interface and its revenue ports. This means you can perform 61 | ZTP through a dedicated OOB management network (recommended) or in-band. 62 | 63 | After the switch knows the details of its ZTP process, it first 64 | downloads the required configuration file and then the required software 65 | image (if necessary). If a software image was downloaded, then the 66 | switch performs the software upgrade. Finally, it applies the 67 | configuration file that was downloaded. 68 | 69 | ZTP can also be performed by Junos Space with Network Director. When 70 | this is done, the switch is automatically added to Network Director for 71 | future management. 72 | 73 | For more information on ZTP (including configuration examples), see the 74 | following blogs/articles: 75 | 76 | * `Zero Touch Provisioning: How to Build a Network Without Touching Anything `_ 77 | * `Zero Touch Provisioning on Juniper devices using Linux `_ 78 | 79 | You can also read Chapter 6 of the QFX5100 Series book from O'Reilly [#f1]_. 80 | 81 | .. _ha: 82 | 83 | High Availability 84 | ----------------- 85 | 86 | The QFX5100 has a virtualized control plane. There is a Linux host 87 | running KVM, and Junos runs as a VM. The hypervisor can run up to four 88 | VMs: two of them are reserved for Junos, one is a guest of the 89 | operator's choice, and the last is reserved. 90 | 91 | Each Junos VM has four management interfaces. The first two, ``em0`` 92 | and ``em1``, map to the physical management ports on the switch. The 93 | third, ``em2``, is used for communicating with the hypervisor. The last 94 | interface, ``em3``, is used when performing a Topology-independent 95 | In-Service Software Upgrade, or TISSU. The second Junos VM is only 96 | created during a TISSU. In order to perform a TISSU, NSR, NSB, and GRES 97 | must be configured. 98 | 99 | The high-level process for TISSU is as follows [#f2]_: 100 | 101 | 1: Create the backup Junos VM running the new version requested 102 | 2: Synchronize state between the Junos VMs using ``ksyncd`` 103 | 3: Makes the new VM the master RE 104 | 4: Renames the slot ID of the new VM from ``1`` to ``0`` 105 | 5: The former master Junos VM is shut down 106 | 107 | When performing a TISSU, keep the following in mind: 108 | 109 | * Downgrades and rollbacks are not supported 110 | * TISSU should not be used when transitioning between different base 111 | images (e.g., ``standard`` to ``enhanced-automation``) 112 | * The CLI is inaccessible during a TISSU 113 | * Log files are located in ``/var/log/vjunos-log.tgz`` 114 | * BFD timers need to be >= 1 second [#f3]_ 115 | * ``system internet-options no-tcp-reset drop-all-tcp`` must not be 116 | configured [#f3]_ 117 | 118 | A configuration sample for enabling NSR, NSB, and GRES is below. 119 | 120 | .. literalinclude:: configs/deployment-and-management/issu.cfg 121 | :language: perl 122 | 123 | Once the configuration is in place, you can perform a TISSU with the 124 | ``request system software in-service-upgrade `` command. 125 | 126 | For more information, see Chapter 2 of the Juniper QFX5100 Series book 127 | [#f1]_. 128 | 129 | .. _monitoring: 130 | 131 | Monitoring 132 | ---------- 133 | 134 | Junos supports streaming telemetry as well as more traditional methods 135 | of monitoring such as SNMP. 136 | 137 | TODO: Add configuration for SNMPv2c, SNMPv3, and Streaming Telemetry. 138 | 139 | .. _analytics: 140 | 141 | Analytics 142 | --------- 143 | 144 | The QFX5100 supports two methods of analytics: sFlow and Enhanced 145 | Analytics. These are described below, but it's important to understand 146 | that they should be used together as neither provides the entire picture 147 | on its own. 148 | 149 | sFlow 150 | ^^^^^ 151 | 152 | The QFX5100 supports sFlow, which samples every ``n`` packets. This 153 | sampled data is exported every 1500 bytes or every 250ms. Any alerting 154 | on this data must be performed off-box with the sFlow collector. On the 155 | QFX5100, only switchports can be sampled. Layer 3 interfaces cannot be 156 | sampled. The first 128 bytes of the packet are sampled, and this 157 | includes information such as the source and destination MACs, IPs, and 158 | Ports. Higher sampling rates require more processing power. 159 | 160 | To combat this on high-traffic switches, the QFX5100 can dynamically 161 | adjust sample rates based on interface traffic. This is known as 162 | adaptive sampling. An agent checks the interfaces every 5 seconds. 163 | A list of the top five interfaces is created. An algorithm reduces the 164 | load by half for the top five interfaces and allocates those samples to 165 | lower traffic interfaces. 166 | 167 | An sFlow configuration is shown below. 168 | 169 | .. literalinclude:: configs/deployment-and-management/sflow.cfg 170 | :language: perl 171 | 172 | .. note:: 173 | The ``polling-interval`` tells Junos how frequently, in seconds, to 174 | poll for data; the ``sampling-rate`` tells Junos how many packets to 175 | sample. 176 | 177 | Juniper Enhanced Analytics 178 | ^^^^^^^^^^^^^^^^^^^^^^^^^^ 179 | 180 | The QFX5100 also supports Juniper Enhanced Analytics. This system can 181 | poll as frequently as every 8ms, and data is exported as soon as it is 182 | collected. You can set thresholds on-box down to 1ns. Enhanced 183 | Analytics can monitor: 184 | 185 | * Traffic statistics 186 | * Queue depth 187 | * Latency 188 | * Jitter 189 | 190 | This data can be streamed using the following formats: 191 | 192 | * Protobuf 193 | * JSON 194 | * CSV 195 | * TSV 196 | 197 | Enhanced Analytics is performed by two systems: the Analytics Daemon and 198 | the Analytics Manager. 199 | 200 | The Analytics Daemon (``analyticsd``) collects information from the 201 | Analytics Manager's ring buffers and exports it to collectors. 202 | 203 | The Analytics Manager runs in the PFE and collects the data that is 204 | placed into ring buffers for ``analyticsd`` to collect. 205 | 206 | TODO: Add configuration examples for Enhanced Analytics. 207 | 208 | For more information, see Chapter 9 of the Juniper QFX5100 Series book 209 | [#f1]_. 210 | 211 | .. rubric:: Footnotes 212 | 213 | .. [#f1] `Juniper QFX5100 Series `_ 214 | .. [#f2] `Understanding In-Service Software Upgrade (ISSU) `_ 215 | .. [#f3] `Performing an In-Service Software Upgrade (ISSU) with Non-Stop Routing `_ 216 | -------------------------------------------------------------------------------- /docs/_sources/index.rst.txt: -------------------------------------------------------------------------------- 1 | .. jncip-dc-notes documentation master file, created by 2 | sphinx-quickstart on Thu May 16 17:05:25 2019. 3 | You can adapt this file completely to your liking, but it should at least 4 | contain the root `toctree` directive. 5 | 6 | JNCIP-DC Study Notes 7 | ==================== 8 | 9 | Welcome to `Tyler Christiansen `_'s 10 | notes for the 11 | `JNCIP-DC `_ 12 | exam. These notes are open source. I would love to see additional 13 | collaboration and contribution from others who are either pursuing the 14 | exam or who are far more knowledgeable than myself. If you're 15 | interested in contributing, please see the :ref:`contributing` section 16 | below. 17 | 18 | These notes have been taken and organized in the order of the listed 19 | `JNCIP-DC `_ 20 | exam objectives. The primary reference has been the 21 | `QFX5100 Series `_ 22 | book, but other references such as the 23 | `MX Series `_ 24 | book and official Juniper documentation have been used. I've tried to 25 | remember to credit any sources I've had while taking notes, but I'm sure 26 | I've left sources off. If you're aware of a particular source for 27 | something, please let me know so that I can attribute credit. 28 | 29 | .. note:: 30 | Links to Amazon may be present. They are *not* affiliate links. I 31 | do not make any money if you follow them. I do not make any money 32 | for any link you follow on this site. There is no monetization 33 | whatsoever here. I'm only interested in publishing my JNCIP-DC notes 34 | as open source. 35 | 36 | These are my personal notes -- they're not guaranteed to be accurate or 37 | representative of the exam in any way, shape, or form. If you find 38 | something that is incorrect, please let me know via e-mail or GitHub. 39 | You can even submit a pull request to correct the error! 40 | 41 | .. _contributing: 42 | 43 | Contributing 44 | ------------ 45 | 46 | I'll take contributions however I can get them, but here are a few areas 47 | in which I'm particularly interested: 48 | 49 | * Diagrams: I'm really terrible at making diagrams. I actually tried to 50 | to make a few for this project, but I became far too frustrated with 51 | the tools available to me (I don't have Visio). If you can contribute 52 | diagrams, it would be incredibly helpful. 53 | * Technical Corrections: These are my notes for an exam; I'm not an 54 | authority on the technologies, and I could definitely be wrong. I 55 | don't have a technical reviewer. If you find technical errors, please 56 | let me know either via e-mail, a GitHub issue, or a pull request to 57 | correct the issue. All I ask is that for any technical correction, a 58 | source to the correct information be provided. 59 | * Grammatical Correction: This may seem odd, but if there's a grammar 60 | issue, I'd appreciate a correction. 61 | * Labs and Configurations: More labs and configuration examples are 62 | always better! I'm trying to provide examples, but it's sometimes 63 | difficult to capture. In some cases, I can't provide any labs or 64 | configuration snippets because it requires physical gear (such as 65 | Virtual Chassis) and I only have access to vQFX10k. So if you can 66 | contribute labs or configuration snippets, they would be greatly 67 | appreciated! 68 | 69 | If you have any other contribution to make, it's 100% welcome. The best 70 | place to contribute and collaborate is the 71 | `GitHub repository `_. 72 | Issues can be reported, and if you're familiar with GitHub and/or 73 | ReStructured Text (the markup language in which these notes are 74 | written), you can submit pull requests to contribute. 75 | 76 | All contributions will be added to the :ref:`contributors` page unless 77 | the contributor requests otherwise. 78 | 79 | .. toctree:: 80 | :maxdepth: 5 81 | :caption: Contents: 82 | 83 | dc-deployment-and-management 84 | mc-lag 85 | layer-2-fabrics 86 | layer-3-fabrics 87 | vxlan 88 | vxlan-evpn 89 | lab-objectives 90 | additional-resources 91 | contributors 92 | 93 | * :ref:`search` 94 | -------------------------------------------------------------------------------- /docs/_sources/lab-objectives.rst.txt: -------------------------------------------------------------------------------- 1 | Technology-Oriented Labs 2 | ======================== 3 | 4 | TODO: Flesh this out more. A lot more. 5 | 6 | Right now, this page is a sort of scratch pad on things that are likely 7 | to be on the exam. It's lab-oriented, with some specific implementation 8 | details. 9 | 10 | Lab 1 (Multicast and CRB with QFX) 11 | ---------------------------------- 12 | 13 | This lab should focus on multicast for BUM replication and VTEP 14 | discovery. It should implement VxLAN routing at the spine layer. The 15 | spines should be QFX10k Series devices. 16 | 17 | Lab 2 (Multicast and CRB with MX) 18 | --------------------------------- 19 | 20 | This lab should focus on multicast for BUM replication and VTEP 21 | discovery. It should implement VxLAN routing at the spine layer. The 22 | spines should be MX Series devices. 23 | 24 | Lab 3 (Multicast and ERB) 25 | ------------------------- 26 | 27 | This lab should focus on multicast for BUM replication and VTEP 28 | discovery. It should implement VxLAN routing at the leaf layer. Use 29 | either the QFX10k or QFX5110 Series for the leaf layer. 30 | 31 | Lab 4 (EVPN and CRB with QFX) 32 | ----------------------------- 33 | 34 | This lab should focus on BGP EVPN and ingress replication for VTEP 35 | discovery. It should implement VxLAN routing at the spine layer. The 36 | spines should be QFX10k Series devices. 37 | 38 | Lab 5 (EVPN and CRB with MX) 39 | ---------------------------- 40 | 41 | This lab should focus on BGP EVPN and ingress replication for VTEP 42 | discovery. It should implement VxLAN routing at the spine layer. The 43 | spines should be MX Series devices. 44 | 45 | Lab 6 (EVPN and ERB) 46 | -------------------- 47 | 48 | This lab should focus on BGP EVPN and ingress replication for VTEP 49 | discovery. It should implement VxLAN routing at the leaf layer. Use 50 | either the QFX10k or QFX5110 Series for the leaf layer. 51 | 52 | Lab 7 (EVPN Multihoming with QFX) 53 | --------------------------------- 54 | 55 | This lab should focus on EVPN using a QFX at the leaf layer. Use any of 56 | labs 3 through 6 as the base topology and add EVPN Multihoming at the 57 | leaf layer with a QFX Series device. 58 | 59 | Lab 8 (EVPN Multihoming with MX) 60 | --------------------------------- 61 | 62 | This lab should focus on EVPN using an MX at the leaf layer. Use any of 63 | labs 3 through 6 as the base topology and add EVPN Multihoming at the 64 | leaf layer with an MX Series device. 65 | 66 | Lab 9 (DCI with MX Series EVPN Stitching) 67 | ----------------------------------------- 68 | 69 | Implement a DCI solution with lab 7 or 8 as a starting point and MX 70 | Series devices as WAN routers. They should stitch a VxLAN EVPN to an 71 | MPLS EVPN solution. 72 | 73 | Lab 10 (DCI with MX Series L3VPN) 74 | --------------------------------- 75 | 76 | Implement a DCI solution with lab7 or 8 as a starting point and MX 77 | Series devices as WAN routers. The VxLAN EVPN solution should simply 78 | ride over a normal MPLS L3VPN. 79 | 80 | Lab 11 (DCI with VxLAN EVPN and MX) 81 | ----------------------------------- 82 | 83 | Implement a DCI solution with lab7 or 8 as a starting point and MX 84 | Series devices as spines. The solution should be implemented using only 85 | VxLAN BGP EVPN. 86 | 87 | Lab 12 (DCI with VxLAN EVPN and QFX) 88 | ------------------------------------ 89 | 90 | Implement a DCI solution with lab7 or 8 as a starting point and QFX10k 91 | Series devices as spines. The solution should be implemented using only 92 | VxLAN BGP EVPN. 93 | -------------------------------------------------------------------------------- /docs/_sources/layer-2-fabrics.rst.txt: -------------------------------------------------------------------------------- 1 | Layer 2 Fabrics 2 | =============== 3 | 4 | This blueprint item primarily covers the following topics: 5 | 6 | * :ref:`vc` 7 | * :ref:`vcf` 8 | 9 | .. note:: 10 | Both :ref:`vc` and :ref:`vcf` are hardware-based architectures. 11 | Unfortunately, I do not have access to real hardware; all of my 12 | labbing is based on the vQFX0000. This means that although there 13 | may be configurations presented, I don't currently have a way of 14 | validating. If you have access to physical gear and can validate 15 | the configurations (or present more interesting 16 | topologies/configurations), I would love to see them contributed! 17 | 18 | 19 | .. _vc: 20 | 21 | Virtual Chassis 22 | --------------- 23 | 24 | The EX4300, QFX3500, QFX3600, and QFX5100 can form a mixed mode Virtual 25 | Chassis. If you are familiar with mixed mode Virtual Chassis from the 26 | Enterprise track (EX4200/EX4500/EX4550), the concept is very similar. 27 | Up to 10 switches are supported in a stack, although some switches, such 28 | as the QFX5100-96S, may not be supported. 29 | 30 | The first step in creating a mixed mode Virtual Chassis is to tell each 31 | individual switch that it will be participating in a mixed mode VC with 32 | the ``request virtual-chassis mode mixed reboot`` command. However, 33 | when building a new stack, the 34 | ``request virtual-chassis mode mixed all-members reboot`` command can be 35 | used to set all members in the stack to mixed mode at the same time. 36 | 37 | .. note:: 38 | When operating in a mixed mode Virtual Chassis, the scaling numbers 39 | are reduced to the lowest common denominator. This severely limits 40 | the scalability of a deployment. The lowest common denominator is 41 | the lowest scaling factor of the smallest possible PFE. This means 42 | that if you have a mixed Virtual Chassis of QFX3500 and QFX5100, even 43 | if there is no EX4300, each device will still be limited to the 44 | maximum scale of an EX4300. 45 | 46 | The benefits of a mixed mode Virtual Chassis are the same as those of a 47 | regular Virtual Chassis: 48 | 49 | * Redundant Routing Engines 50 | * NSR and NSB 51 | * One control plane for multiple data planes 52 | * Potential elimination of xSTP 53 | 54 | By default, the 40G QSFP+ ports on an EX4300 are enabled for Virtual 55 | Chassis; however, on the QFX5100, these ports are disabled for Virtual 56 | Chassis. When a mixed mode VC contains QFX5100 switches, only the 57 | QFX5100 can become an RE. As with many protocols consisting of primary 58 | and secondary nodes, the VC mastership process follows an election 59 | process. The first tie-breaker is priority, which is 128 by default. 60 | Higher is better. If the priority values are the same, the next factor 61 | to consider is which node was the master prior to a reboot. Next, the 62 | member with the highest uptime; however, the difference in uptime must 63 | be more than 60 seconds. Finally, all else being equal (and difference 64 | in uptime being less than 60 seconds), the member with the *lowest* MAC 65 | address will be elected as the master. The backup is elected according 66 | to the same criteria. 67 | 68 | When implementing Virtual Chassis, you can use the 69 | ``virtual-chassis auto-sw-upgrade`` configuration to automatically 70 | upgrade members with the ``LC (Line Card)`` state when their software 71 | version does not match that of the Master RE. Additionally, Split 72 | Detection can be disabled with the 73 | ``virtual-chassis no-split-detection`` configurtation. However, this 74 | should only be done when there are only two members in the Virtual 75 | Chassis. 76 | 77 | On a QFX5100, you will need to set ports as Virtual Chassis Ports with 78 | the ``request virtual-chassis vc-port set pic-slot 0 port 48`` 79 | operational command. 80 | 81 | Virtual Chassis supports a special deviation of ISSU called NSSU: 82 | Non-Stop Software Upgrade. For NSSU to work, the physical topology must 83 | be a ring -- it cannot be a braid. The master and backup must be 84 | adjacent; this means that the roles of each switch must be 85 | deterministic. For this reason, only pre-provisioned Virtual Chassis is 86 | supported. Additionally, both NSR and GRES must be configured; NSB is 87 | optional. To initiate an NSSU, issue the 88 | ``request system software nonstop-upgrade [ ]`` 89 | command. 90 | 91 | .. _vcf: 92 | 93 | Virtual Chassis Fabric 94 | ---------------------- 95 | 96 | Virtual Chassis Fabric is an extension of Virtual Chassis. It works 97 | with QFX3500, QFX3600, QFX5100, and EX4300 series switches. 98 | New switches added to a VCF are automatically discovered and brought 99 | online. 100 | 101 | .. note:: 102 | The node limit is unclear. In Chapter 5 of the O'Reilly QFX5100 103 | Series book [#f1]_, a passage indicates that the maximum number of 104 | switches is 32; however, recent Juniper documentation publications 105 | [#f2]_ indicate that the limit is 20. Because the documentation is 106 | more recent than the published book, even though there is no 107 | confirmed and published errata [#f3]_, readers should assume a limit 108 | of 20 nodes. 109 | 110 | Like :ref:`vc`, VCF uses IS-IS between switches. The links between 111 | switches, however, come up as "Smart Trunks." This is part of what 112 | enables VCF to perform unequal cost multipath load balancing in certain 113 | designs and failure scenarios. The other technology that enables 114 | unueqal cost multipath is Adaptive Load Balancing. ALB hashes TCP 115 | flowlets to different links. 116 | 117 | These flowlets are tracked in a hash bucket table. This table can hold 118 | hundreds of thousands of entries -- enough to prevent "elephant flows" 119 | from overloading a given link. When the flowlet egresses the switch, 120 | the hash table is updated with a timestamp and the link via which it 121 | egressed. When a new packet for the same flowlet egresses, it is 122 | checked against an expiration or inactivity timer. If the time since 123 | the last packet was seen is greater than the inactivity timer, then the 124 | flowlet is hashed to a new uplink. The egress link selection is also 125 | based on a moving average of the load and queue depth on each interface. 126 | 127 | ALB is disabled by default; to enable it in a VCF, use the 128 | ``set fabric-load-balance flowlet`` configuration command. 129 | 130 | Not all switches can be spine switches, but all switches can be leaf 131 | switches. A general rule of thumb is that a fiber-based QFX5100 can be 132 | a leaf switch or a spine switch; any other switch can only be a leaf 133 | switch. 134 | 135 | Provisioning Options 136 | ^^^^^^^^^^^^^^^^^^^^ 137 | 138 | When configuring a VCF, you have three options: auto-provisioned, 139 | pre-provisioned, and non-provisioned. Each has its own benefits and 140 | drawbacks; auto-provisioned is less secure, while the non-provisioned 141 | mode is more configuration-intensive and less predictable. 142 | 143 | With an auto-provisioned VCF, you must specify the role and serial 144 | number for each spine switch; the leaf switches are automatically added. 145 | The Virtual Chassis Ports are automatically discovered and added. 146 | 147 | With a pre-provisioned VCF, you specify each spine *and* leaf member. 148 | Virtual Chassis Ports are also automatically discovered and added. 149 | Configuring a VCF in this mode is the same as configuring a :ref:`vc` 150 | in pre-provisioned mode. 151 | 152 | .. note:: 153 | If you do not want links between switches to be converted to VCPs 154 | automatically, delete the LLDP configuration before powering on 155 | additional switches. 156 | 157 | .. note:: 158 | If you're using a mixed mode :ref:`vcf`, you need to disable the 159 | VCPs on any EX4300 switch in order for the VCPs to autonegotiate 160 | successfully. Converting VCPs to network interfaces is covered 161 | in the :ref:`data-plane` section. 162 | 163 | The non-provisioned mode is similar to the pre-provisioned mode, except 164 | that the Virtual Chassis Ports are not automatically discovered and 165 | added, and the roles are not automatically defined; instead, a 166 | priority-based election process occurs. 167 | 168 | To create a VCF, you need to set the master RE switch into the VCF mode 169 | with ``request virtual-chassis mode fabric reboot``. At least one leaf 170 | switch needs to be installed next, and it should be cabled to the second 171 | spine switch before bringing up the second spine switch. 172 | 173 | .. note:: 174 | If you need a Mixed Mode :ref:`vcf`, such as when building a fabric 175 | with the QFX5100 and EX4300, you need to use the 176 | ``request virtual-chassis mode fabric mixed reboot`` operational 177 | command. When operating a mixed mode :ref:`vcf`, you can set the 178 | master's mode to ``mixed``, then add all members, and then set all 179 | switches to ``mixed`` mode at the same time with the operational 180 | ``request virtual-chassis mode fabric mixed all-members reboot`` 181 | command. 182 | 183 | Mastership Election 184 | ^^^^^^^^^^^^^^^^^^^ 185 | 186 | In auto-provisioned and pre-provisioned, modes, the QFX5100 that has the 187 | highest uptime is elected the master. The QFX5100 with the 188 | second-highest uptime is elected the backup. Any other QFX5100s in the 189 | spine role are line cards. If one of the masters fails, then one of the 190 | QFX5100 spines operating as a line card will be elected the new backup 191 | following the same uptime rules. 192 | 193 | For a non-provisioned VCF, the following rules dictate master selection: 194 | 195 | 1: Highest priority (default is 128) 196 | 2: QFX5100 operating as master prior to reboot 197 | 3: QFX5100 with longest uptime (greater than one minute) 198 | 4: QFX5100 with lowest MAC address 199 | 200 | For the backup RE, the process is repeated. 201 | 202 | .. note:: 203 | You might notice that this the same mastership election process as 204 | for :ref:`vc`. 205 | 206 | Control Plane 207 | ^^^^^^^^^^^^^ 208 | 209 | ``vccpd`` runs on all nodes and is based on IS-IS. It is responsible 210 | for topology discovery. It also distributes any VCCP-specific state 211 | information. For unicast traffic, shortest path first is used; however, 212 | to support BUM traffic, bidirection multicast trees are used. Finally, 213 | for control plane traffic, a unique Class of Service queue is 214 | automatically created and used. All of this operational complexity is 215 | abstracted by :ref:`vcf`. 216 | 217 | When deploying a VCF, GRES, NSR, and NSB are used to keep the master and 218 | backup REs in sync. 219 | 220 | For console access, each switch runs a virtual console server. When you 221 | attach to the console of any member switch, this virtual console server 222 | software automatically redirects your connection to the master RE. Once 223 | you're on the master RE, you can access a specific node with the 224 | ``request session member `` command. 225 | 226 | As with :ref:`vc`, the OOB management interface becomes a ``vme`` 227 | interface. 228 | 229 | When a switch is removed, its member ID does not get released 230 | automatically. If you want to release the member ID to be used by the 231 | next switch attached, you can use the 232 | ``request virtual-chassis recycle member-id `` operational cmmand. 233 | 234 | When adding a new switch, the software versions must be compatible. You 235 | can either upgrade the devices manually, or you can use the 236 | ``auto-sw-upgrade`` configuration. When using this, you must have the 237 | images for each series (EX4300, QFX3500, QFX5100) in your fabric on the 238 | master RE or a remote URL. Use the 239 | ``set virtual-chassis auto-sw-upgrade ex-4300 `` configuration 240 | command to set the path for an EX4300. Replace ``ex-4300`` with 241 | ``qfx-3`` or ``qfx-5`` for the QFX3500 or QFX5100, respectively. 242 | 243 | When performing a software upgrade, the Non-Stop Software Upgrade (NSSU) 244 | feature can be used if using the ``preprovisioned`` mode. Additionally, 245 | ``no-split-detection`` (covered in the :ref:`fabric-partition` section) 246 | must be configured. 247 | 248 | .. _data-plane: 249 | 250 | Data Plane 251 | ^^^^^^^^^^ 252 | 253 | :ref:`vcf` has a concept of "Smart Trunks." When two or more links 254 | between two devices are connected, they will automatically form a LAG. 255 | Each path is weighted based on the bandwidth ratio. Traffic is 256 | distributed across multiple unequal paths, taking into account the 257 | minimum possible bandwidth on any links in the path. 258 | 259 | A 16 byte Fabric Header is added to each packet received or sent by an 260 | ingress or egress device, similar to MPLS. It contains the incoming 261 | member ID, incoming port ID, destination member ID, and destination port 262 | ID, among other fields. 263 | 264 | For load balancing hashing, the following fields are used: 265 | 266 | Layer 2+Fabric Header: 267 | 268 | * Source MAC 269 | * Destination MAC 270 | * Ethertype 271 | * VLAN ID 272 | * Incoming Port ID 273 | * Incoming Member ID 274 | 275 | Layer 3+4: 276 | 277 | * Source IP 278 | * Destination IP 279 | * Source Port 280 | * Destination Port 281 | * Protocol 282 | * Incoming Port ID 283 | * Incoming Member ID 284 | * Next Header (IPv6 Only) 285 | 286 | If you need to convert an interface to a VCP, the 287 | ``request virtual-chassis vc-port set pic-slot port member `` 288 | command can be used. The ``member `` corresponds to the FPC number 289 | in the interface's representation. To do the opposite, replace ``set`` 290 | with ``delete``. For example, 291 | ``request virtual-chassis vc-port delete pic-slot 0 port 1 member 7``. 292 | 293 | Finally, MAC learning is similar to a :ref:`vc`: when a member learns a 294 | new MAC address, it notifies the master of the MAC address. The master 295 | then programs all other members with the MAC-to-interface entry. 296 | 297 | BUM Traffic 298 | ^^^^^^^^^^^ 299 | 300 | BUM traffic is distributed according to a Multicast Distribution Tree 301 | (MDT). There are multiple trees in a :ref:`vcf`, each rooted at each 302 | switch. Therefore, there are ``N`` MDTs, where ``N`` is the number of 303 | switches in the :ref:`vcf`. Each switch can load balance across all of 304 | the available MDTs for sending BUM traffic. This traffic is hashed 305 | based on the VLAN ID. 306 | 307 | .. note:: 308 | In a :ref:`vcf`, all members receive a copy of all BUM traffic. 309 | 310 | .. _fabric-partition: 311 | 312 | Fabric Partition 313 | ^^^^^^^^^^^^^^^^ 314 | 315 | Sometimes, a fabric may become partitioned or "split." This occurs when 316 | one or more switches become isolated from one or more other switches in 317 | the fabric. When this happens, one of the new fabrics will remain 318 | active, and the others will be deactivated. 319 | 320 | .. note:: 321 | "Isolated" refers to communications via the Virtual Chassis Ports. 322 | Even if IP connectivity would otherwise exist, the fabric is 323 | considered partitioned if it cannot communicate over the VCPs. 324 | 325 | To determine which fabric will remain active, the following rules are 326 | evaluated, in order: 327 | 328 | 1: The fabric contains both the master and the backup RE from the 329 | previous fabric 330 | 2: The fabric contains the original master RE and at least half of the 331 | members from the previous fabric 332 | 2: The fabric contains the backup master RE and at least half of the 333 | members from the previous fabric 334 | 335 | If your design can function when a partition happens, you can disable 336 | the default behavior with the ``set virtual-chassis no-split-detection`` 337 | configuration command. This disables the deactivation of partitioned 338 | fabrics described above. 339 | 340 | .. rubric:: Footnotes 341 | 342 | .. [#f1] `Juniper QFX5100 Series `_ 343 | .. [#f2] `Planning a Virtual Chassis Fabric Deployment `_ 344 | .. [#f3] `Errata for Juniper QFX5100 Series `_ 345 | -------------------------------------------------------------------------------- /docs/_sources/layer-3-fabrics.rst.txt: -------------------------------------------------------------------------------- 1 | .. _layer-3-fabrics: 2 | 3 | Layer 3 Fabrics 4 | =============== 5 | 6 | This blueprint item primarily covers the following topics: 7 | 8 | * :ref:`clos` 9 | * :ref:`ip-fabric-routing` 10 | * :ref:`ip-fabric-scaling` 11 | * :ref:`best-practices` 12 | 13 | .. _clos: 14 | 15 | 3-Stage Clos Architecture 16 | ------------------------- 17 | 18 | A Clos network was originally a circuit switching architecture for the 19 | PSTN. It provided for connecting one input to one output with no 20 | blocking. In other words, connectivity was always possible. This was 21 | because of the intermediate switches that connected ingress and egress 22 | switches. 23 | 24 | In IP networking, this concept has been applied in the "spine-leaf" 25 | architecture. In this design, a number of interconnecting transport 26 | switches (spines) connect to ingress and egress switches (leafs). They 27 | provide multiple paths for communications and can be designed in a way 28 | that is "non-blocking" if zero oversubscription is desired. These 29 | fabrics make better use of their links. They are classified as 30 | ``n-stage``, where ``n`` is (more or less) the number of network devices 31 | a packet will traverse when ingressing and egressing from any point in 32 | the fabric to any point in the fabric. A 3-stage architecture consists 33 | of three network devices from point A to point Z: the ingress leaf, a 34 | spine, and an egress leaf. This means that you can have predictable 35 | network characteristics such as hop count and latency. For example, for 36 | intra-fabric communications, any destination is exactly two hops from 37 | its source (excluding advanced services such as overlay networking, 38 | firewalls, load balancers, etc.). 39 | 40 | .. _ip-fabric-routing: 41 | 42 | IP Fabric Routing 43 | ----------------- 44 | 45 | When designing an IP fabric, there are two primary designs, though both 46 | leverage BGP. 47 | 48 | .. _ibgp: 49 | 50 | iBGP 51 | ^^^^ 52 | 53 | In an iBGP design, an IGP such as OSPF or IS-IS is used to provide 54 | multipathing. iBGP peerings are formed over loopback interfaces, and 55 | route reflectors can be used to increase the scale of the solution. 56 | Route reflection, however, introduces its own issues. 57 | 58 | When the same prefix is received from multiple leafs by a route 59 | reflector spine, it will (by default) only advertise the best path to 60 | the non-route-reflector spines. This results in suboptimal traffic 61 | forwarding, and in congested scenarios may result in avoidable 62 | congestion and degradation of service. To resolve this issue, BGP 63 | ADD-PATH can be used. BGP ADD-PATH causes the router to prefix a unique 64 | path identifier to a prefix advertisement; because of this, all routers 65 | at the spine level must support and be configured for BGP ADD-PATH. 66 | 67 | .. _ebgp: 68 | 69 | eBGP 70 | ^^^^ 71 | 72 | With eBGP, there is no IGP -- BGP acts in a similar role as an IGP. In 73 | this design, each leaf node is given a unique ASN and all spines either 74 | share the same ASN or have unique ASNs per node. 75 | 76 | .. note:: 77 | The QFX5100 Series book [#f1]_, particularly Chapter 7: IP Fabrics 78 | (Clos), seems to suggest that the spine switches should each have a 79 | unique ASN. However, multiple other sources such as RFC7938 [#f2]_ 80 | and BGP in the Data Center [#f3]_ suggest giving the spines the same 81 | ASN while allowing the leafs to have unique ASNs. This is likely to 82 | avoid the nead for ``multipath multiple-as`` on every leaf and to 83 | simplify spine configuration. However, even following this numbering 84 | scheme, the spines will ultimately require ``multipath multiple-as``. 85 | 86 | You might notice that because of this design, you will still need extra 87 | configuration to handle the scenario where a prefix is received from 88 | multiple switches. To work around this, use the 89 | ``set protocols bgp group multipath multiple-as`` BGP 90 | configuration. The biggest difference between this an the requirement 91 | for ADD-PATH in an :ref:`ibgp` is that ADD-PATH is a feature negotiated 92 | between peers, whereas ``multipath multiple-as`` is not. This results 93 | in less complexity and fewer places for things to go wrong. It also 94 | increases vendor and platform interoperability since ADD-PATH is not 95 | guaranteed to be supported on a given platform or vendor, but even 96 | without ``multipath multiple-as``, the fabric will still function 97 | (suboptimally). Additionally, if the spine switches are given the same 98 | ASN instead of a unique ASN per spine switch, the number of places that 99 | require ``multipath multiple-as`` might be reduced depending on your 100 | design and requirements. 101 | 102 | .. note:: 103 | ``multipath multiple-as`` is recommended on all nodes. You *can* get 104 | away with only deploying it in certain places, but that doesn't mean 105 | you should. One of the benefits of deploying an IP fabric is 106 | reproducibility, and when you start tailoring to such a degree, it 107 | increases the cognitive load on engineers supporting the fabric 108 | because they can no longer assume similar behavior amongst nodes. 109 | 110 | .. _ip-fabric-scaling: 111 | 112 | IP Fabric Scaling 113 | ----------------- 114 | 115 | The scalability of an IP fabric is largely limited by three things: 116 | 117 | * the acceptable oversubscription ratio 118 | * the number of uplinks available per leaf per pod 119 | * the number of ports per spine per pod 120 | 121 | The acceptable oversubscription ratio can determine both how many 122 | servers you attach to a leaf and how many spines you need to have, both 123 | of which influence and are influenced by your required speeds downstream 124 | toward servers. For example, assume you have a 48x10G switch with 125 | 6x40G uplinks. This gives you an oversubscription ratio of 480G:240G, 126 | or 2:1, if you have six spine switches. However, perhaps it's 127 | unacceptable to have a 2:1 oversubscription ratio. Maybe you require no 128 | oversubscription. In this case, you can either select a leaf switch 129 | with more 40G uplinks (and add more spine swithces), or you can decide 130 | that you will not attach any servers to half of the 10G ports. 131 | 132 | .. note:: 133 | You can get clever and, if your switch supports it, break out all of 134 | the 40G ports to 10G ports. Then use only 10G spines. Split your 135 | total 10G ports in half; this number is the number of spines you 136 | need. For example, given the same leaf port density above and 137 | breaking out the 40G ports, you would have 72x10G interfaces. 138 | Dividing this by two, there are 36 ports downstream toward servers 139 | and 36 ports upstream toward spines. This means that you need either 140 | 36 spines *or* multiple ports stacked on spines, perhaps on a 141 | chassis-based spine such as an MX240. The end result is that you are 142 | "wasting" 12x10G ports compared to the 2:1 oversubscription model, 143 | and you likely need more or larger spines. In reality, 36 server 144 | ports in a 48U rack is probably the most (or close to the most) 145 | you'll get anyway. All of this said, though, for the purposes of 146 | this exam, it's likely best to stick with the number of "downstream" 147 | and "upstream" ports as noted by the difference in port speeds 148 | (i.e., 10G vs. 40G or 40G vs 100G). 149 | 150 | .. _best-practices: 151 | 152 | IP Fabric Best Practices 153 | ------------------------ 154 | 155 | There is one critical consideration to make when selecting links between 156 | spines and leafs: bandwdith. If you go the :ref:`ibgp` route (and you 157 | use OSPF or use different metrics for different bandwidths in IS-IS), 158 | your ECMP will be affected if you have mixed uplink bandwidth from your 159 | leafs (such as 10G and 40G). The result is that you will have some 160 | unutilized links (except in failure scenarios). 161 | 162 | However, with eBGP, link bandwidth is not considered for path 163 | calculation. If your design uses different bandwidth links, this might 164 | initially seem like a good thing because it results in all links being 165 | utilized. However, they are not intelligently utilized. You can easily 166 | exceed the utilization of the lower capacity links, resulting in either 167 | service degradation or complete outage conditions (depending on your 168 | SLAs). 169 | 170 | For this reason, in either design, it is critical to ensure that all 171 | paths to a given destination from all possible ingress points have the 172 | same total link bandwidth. This makes managing oversubscription and 173 | scaling much easier. 174 | 175 | All swithces at a given stage (spine, leaf, etc.) should be of the same 176 | model. This isn't strictly required so long as they can all support the 177 | same features, but if you choose to use different switches, you will be 178 | limited by the smallest number of ports available. Another 179 | consideration is that some switches may hash traffic differently than 180 | others, leading to unpredictable load sharing characteristics. In other 181 | words, it's okay if your spines and leafs are different models, but all 182 | of your spines should be the same model, and all of your leafs should be 183 | the same model. 184 | 185 | .. note:: 186 | *Technically* you aren't limited by the number of ports. However, 187 | this section is all about best practices. So, in the spirit of best 188 | practices, don't try to mix and match models in the same pod. 189 | 190 | If you have a use case for different spine switches in different pods, 191 | then you can use different spine switches in different pods. An example 192 | of this might be for "bug diversity." In other words, you don't want 193 | all of your global data centers to be hit by the same platform/OS bug at 194 | the same time, so you might deploy different vendors or platforms in 195 | each fabric pod. However, inside of any given pod, you should still use 196 | the same model switch. 197 | 198 | When connecting leaf switches to spine switches, every leaf should be 199 | connected to every spine. Again, you can get away with not doing this, 200 | but to do so is to invite heartache. If you're thinking of doing it for 201 | scaling reasons, consider implementing a 5-stage IP fabric instead. 202 | This brings some different complexity (not covered here), but it also 203 | brings easier and greater scalability without the risks of 204 | unintentionally oversubscribing or modifying the predictability of some 205 | of your fabric switches but not others. 206 | 207 | Configuration 208 | ------------- 209 | 210 | TODO: Add configuration examples for an IGP with iBGP, eBGP with iBGP, 211 | and straight eBGP. 212 | 213 | .. rubric:: Footnotes 214 | 215 | .. [#f1] `Juniper QFX5100 Series `_ 216 | .. [#f2] `RFC7938: Use of BGP in Large-Scale Data Centers, Section 5.2: EBGP Configuration for Clos Topology `_ 217 | .. [#f3] `BGP in the Data Center, Chapter 2, ASN Numbering Model `_ 218 | -------------------------------------------------------------------------------- /docs/_sources/vxlan-evpn.rst.txt: -------------------------------------------------------------------------------- 1 | .. _vxlan-evpn: 2 | 3 | EVPN VXLAN Signaling 4 | ==================== 5 | 6 | Coming soon! 7 | -------------------------------------------------------------------------------- /docs/contributors.html: -------------------------------------------------------------------------------- 1 | 2 | 4 | 5 | 6 | 7 | 8 | 9 | Contributors — jncip-dc-notes documentation 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 |
30 |
31 |
32 | 33 | 34 |
35 | 36 |
37 |

Contributors

38 |

This page lists any contributors to these notes, whether they are issues 39 | reported, pull requests submitted, or suggestions made. The following 40 | format is used:

41 |
    42 |
  • <Name> (@<twitter_handle>): <contribution_message> 43 | (link to GitHub issue(s) and/or pull request(s))
    • 44 |
45 |

All of this is optional. Anything that is either not relevant or 46 | requested to be left out will not be present in the entry.

47 | 52 |
53 | 54 | 55 |
56 | 57 |
58 |
59 | 114 |
115 |
116 |
117 | ©2019, Tyler Christiansen. 118 | 119 | | 120 | Powered by Sphinx 1.8.5 121 | & Alabaster 0.7.12 122 | 123 | | 124 | Page source 126 |
127 | 128 | 129 | 130 | 131 | 132 | -------------------------------------------------------------------------------- /docs/genindex.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 5 | 6 | 7 | 8 | 9 | 10 | Index — jncip-dc-notes documentation 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 |
30 |
31 |
32 | 33 | 34 |
35 | 36 | 37 |

Index

38 | 39 |
40 | 41 |
42 | 43 | 44 |
45 | 46 |
47 |
48 | 102 |
103 |
104 |
105 | ©2019, Tyler Christiansen. 106 | 107 | | 108 | Powered by Sphinx 1.8.5 109 | & Alabaster 0.7.12 110 | 111 |
112 | 113 | 114 | 115 | 116 | 117 | -------------------------------------------------------------------------------- /docs/jncip-dc-notes.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/supertylerc/jncip-dc-notes/6d6b868bd16e1a901dbc0aef90030b17c5398fc5/docs/jncip-dc-notes.pdf -------------------------------------------------------------------------------- /docs/lab-objectives.html: -------------------------------------------------------------------------------- 1 | 2 | 4 | 5 | 6 | 7 | 8 | 9 | Technology-Oriented Labs — jncip-dc-notes documentation 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 |
31 |
32 |
33 | 34 | 35 |
36 | 37 |
38 |

Technology-Oriented Labs

39 |

TODO: Flesh this out more. A lot more.

40 |

Right now, this page is a sort of scratch pad on things that are likely 41 | to be on the exam. It’s lab-oriented, with some specific implementation 42 | details.

43 |
44 |

Lab 1 (Multicast and CRB with QFX)

45 |

This lab should focus on multicast for BUM replication and VTEP 46 | discovery. It should implement VxLAN routing at the spine layer. The 47 | spines should be QFX10k Series devices.

48 |
49 |
50 |

Lab 2 (Multicast and CRB with MX)

51 |

This lab should focus on multicast for BUM replication and VTEP 52 | discovery. It should implement VxLAN routing at the spine layer. The 53 | spines should be MX Series devices.

54 |
55 |
56 |

Lab 3 (Multicast and ERB)

57 |

This lab should focus on multicast for BUM replication and VTEP 58 | discovery. It should implement VxLAN routing at the leaf layer. Use 59 | either the QFX10k or QFX5110 Series for the leaf layer.

60 |
61 |
62 |

Lab 4 (EVPN and CRB with QFX)

63 |

This lab should focus on BGP EVPN and ingress replication for VTEP 64 | discovery. It should implement VxLAN routing at the spine layer. The 65 | spines should be QFX10k Series devices.

66 |
67 |
68 |

Lab 5 (EVPN and CRB with MX)

69 |

This lab should focus on BGP EVPN and ingress replication for VTEP 70 | discovery. It should implement VxLAN routing at the spine layer. The 71 | spines should be MX Series devices.

72 |
73 |
74 |

Lab 6 (EVPN and ERB)

75 |

This lab should focus on BGP EVPN and ingress replication for VTEP 76 | discovery. It should implement VxLAN routing at the leaf layer. Use 77 | either the QFX10k or QFX5110 Series for the leaf layer.

78 |
79 |
80 |

Lab 7 (EVPN Multihoming with QFX)

81 |

This lab should focus on EVPN using a QFX at the leaf layer. Use any of 82 | labs 3 through 6 as the base topology and add EVPN Multihoming at the 83 | leaf layer with a QFX Series device.

84 |
85 |
86 |

Lab 8 (EVPN Multihoming with MX)

87 |

This lab should focus on EVPN using an MX at the leaf layer. Use any of 88 | labs 3 through 6 as the base topology and add EVPN Multihoming at the 89 | leaf layer with an MX Series device.

90 |
91 |
92 |

Lab 9 (DCI with MX Series EVPN Stitching)

93 |

Implement a DCI solution with lab 7 or 8 as a starting point and MX 94 | Series devices as WAN routers. They should stitch a VxLAN EVPN to an 95 | MPLS EVPN solution.

96 |
97 |
98 |

Lab 10 (DCI with MX Series L3VPN)

99 |

Implement a DCI solution with lab7 or 8 as a starting point and MX 100 | Series devices as WAN routers. The VxLAN EVPN solution should simply 101 | ride over a normal MPLS L3VPN.

102 |
103 |
104 |

Lab 11 (DCI with VxLAN EVPN and MX)

105 |

Implement a DCI solution with lab7 or 8 as a starting point and MX 106 | Series devices as spines. The solution should be implemented using only 107 | VxLAN BGP EVPN.

108 |
109 |
110 |

Lab 12 (DCI with VxLAN EVPN and QFX)

111 |

Implement a DCI solution with lab7 or 8 as a starting point and QFX10k 112 | Series devices as spines. The solution should be implemented using only 113 | VxLAN BGP EVPN.

114 |
115 |
116 | 117 | 118 |
119 | 120 |
121 |
122 | 192 |
193 |
194 |
195 | ©2019, Tyler Christiansen. 196 | 197 | | 198 | Powered by Sphinx 1.8.5 199 | & Alabaster 0.7.12 200 | 201 | | 202 | Page source 204 |
205 | 206 | 207 | 208 | 209 | 210 | -------------------------------------------------------------------------------- /docs/objects.inv: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/supertylerc/jncip-dc-notes/6d6b868bd16e1a901dbc0aef90030b17c5398fc5/docs/objects.inv -------------------------------------------------------------------------------- /docs/search.html: -------------------------------------------------------------------------------- 1 | 2 | 4 | 5 | 6 | 7 | 8 | 9 | Search — jncip-dc-notes documentation 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 |
38 |
39 |
40 | 41 | 42 |
43 | 44 |

Search

45 |
46 | 47 |

48 | Please activate JavaScript to enable the search 49 | functionality. 50 |

51 |
52 |

53 | From here you can search these documents. Enter your search 54 | words into the box below and click "search". Note that the search 55 | function will automatically search for all of the words. Pages 56 | containing fewer words won't appear in the result list. 57 |

58 |
59 | 60 | 61 | 62 |
63 | 64 |
65 | 66 |
67 | 68 |
69 | 70 |
71 |
72 | 114 |
115 |
116 |
117 | ©2019, Tyler Christiansen. 118 | 119 | | 120 | Powered by Sphinx 1.8.5 121 | & Alabaster 0.7.12 122 | 123 |
124 | 125 | 126 | 127 | 128 | 129 | -------------------------------------------------------------------------------- /docs/static/ajax-loader.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/supertylerc/jncip-dc-notes/6d6b868bd16e1a901dbc0aef90030b17c5398fc5/docs/static/ajax-loader.gif -------------------------------------------------------------------------------- /docs/static/alabaster.css: -------------------------------------------------------------------------------- 1 | @import url("basic.css"); 2 | 3 | /* -- page layout ----------------------------------------------------------- */ 4 | 5 | body { 6 | font-family: Georgia, serif; 7 | font-size: 17px; 8 | background-color: #fff; 9 | color: #000; 10 | margin: 0; 11 | padding: 0; 12 | } 13 | 14 | 15 | div.document { 16 | width: 940px; 17 | margin: 30px auto 0 auto; 18 | } 19 | 20 | div.documentwrapper { 21 | float: left; 22 | width: 100%; 23 | } 24 | 25 | div.bodywrapper { 26 | margin: 0 0 0 220px; 27 | } 28 | 29 | div.sphinxsidebar { 30 | width: 220px; 31 | font-size: 14px; 32 | line-height: 1.5; 33 | } 34 | 35 | hr { 36 | border: 1px solid #B1B4B6; 37 | } 38 | 39 | div.body { 40 | background-color: #fff; 41 | color: #3E4349; 42 | padding: 0 30px 0 30px; 43 | } 44 | 45 | div.body > .section { 46 | text-align: left; 47 | } 48 | 49 | div.footer { 50 | width: 940px; 51 | margin: 20px auto 30px auto; 52 | font-size: 14px; 53 | color: #888; 54 | text-align: right; 55 | } 56 | 57 | div.footer a { 58 | color: #888; 59 | } 60 | 61 | p.caption { 62 | font-family: inherit; 63 | font-size: inherit; 64 | } 65 | 66 | 67 | div.relations { 68 | display: none; 69 | } 70 | 71 | 72 | div.sphinxsidebar a { 73 | color: #444; 74 | text-decoration: none; 75 | border-bottom: 1px dotted #999; 76 | } 77 | 78 | div.sphinxsidebar a:hover { 79 | border-bottom: 1px solid #999; 80 | } 81 | 82 | div.sphinxsidebarwrapper { 83 | padding: 18px 10px; 84 | } 85 | 86 | div.sphinxsidebarwrapper p.logo { 87 | padding: 0; 88 | margin: -10px 0 0 0px; 89 | text-align: center; 90 | } 91 | 92 | div.sphinxsidebarwrapper h1.logo { 93 | margin-top: -10px; 94 | text-align: center; 95 | margin-bottom: 5px; 96 | text-align: left; 97 | } 98 | 99 | div.sphinxsidebarwrapper h1.logo-name { 100 | margin-top: 0px; 101 | } 102 | 103 | div.sphinxsidebarwrapper p.blurb { 104 | margin-top: 0; 105 | font-style: normal; 106 | } 107 | 108 | div.sphinxsidebar h3, 109 | div.sphinxsidebar h4 { 110 | font-family: Georgia, serif; 111 | color: #444; 112 | font-size: 24px; 113 | font-weight: normal; 114 | margin: 0 0 5px 0; 115 | padding: 0; 116 | } 117 | 118 | div.sphinxsidebar h4 { 119 | font-size: 20px; 120 | } 121 | 122 | div.sphinxsidebar h3 a { 123 | color: #444; 124 | } 125 | 126 | div.sphinxsidebar p.logo a, 127 | div.sphinxsidebar h3 a, 128 | div.sphinxsidebar p.logo a:hover, 129 | div.sphinxsidebar h3 a:hover { 130 | border: none; 131 | } 132 | 133 | div.sphinxsidebar p { 134 | color: #555; 135 | margin: 10px 0; 136 | } 137 | 138 | div.sphinxsidebar ul { 139 | margin: 10px 0; 140 | padding: 0; 141 | color: #000; 142 | } 143 | 144 | div.sphinxsidebar ul li.toctree-l1 > a { 145 | font-size: 120%; 146 | } 147 | 148 | div.sphinxsidebar ul li.toctree-l2 > a { 149 | font-size: 110%; 150 | } 151 | 152 | div.sphinxsidebar input { 153 | border: 1px solid #CCC; 154 | font-family: Georgia, serif; 155 | font-size: 1em; 156 | } 157 | 158 | div.sphinxsidebar hr { 159 | border: none; 160 | height: 1px; 161 | color: #AAA; 162 | background: #AAA; 163 | 164 | text-align: left; 165 | margin-left: 0; 166 | width: 50%; 167 | } 168 | 169 | div.sphinxsidebar .badge { 170 | border-bottom: none; 171 | } 172 | 173 | div.sphinxsidebar .badge:hover { 174 | border-bottom: none; 175 | } 176 | 177 | /* To address an issue with donation coming after search */ 178 | div.sphinxsidebar h3.donation { 179 | margin-top: 10px; 180 | } 181 | 182 | /* -- body styles ----------------------------------------------------------- */ 183 | 184 | a { 185 | color: #004B6B; 186 | text-decoration: underline; 187 | } 188 | 189 | a:hover { 190 | color: #6D4100; 191 | text-decoration: underline; 192 | } 193 | 194 | div.body h1, 195 | div.body h2, 196 | div.body h3, 197 | div.body h4, 198 | div.body h5, 199 | div.body h6 { 200 | font-family: Georgia, serif; 201 | font-weight: normal; 202 | margin: 30px 0px 10px 0px; 203 | padding: 0; 204 | } 205 | 206 | div.body h1 { margin-top: 0; padding-top: 0; font-size: 240%; } 207 | div.body h2 { font-size: 180%; } 208 | div.body h3 { font-size: 150%; } 209 | div.body h4 { font-size: 130%; } 210 | div.body h5 { font-size: 100%; } 211 | div.body h6 { font-size: 100%; } 212 | 213 | a.headerlink { 214 | color: #DDD; 215 | padding: 0 4px; 216 | text-decoration: none; 217 | } 218 | 219 | a.headerlink:hover { 220 | color: #444; 221 | background: #EAEAEA; 222 | } 223 | 224 | div.body p, div.body dd, div.body li { 225 | line-height: 1.4em; 226 | } 227 | 228 | div.admonition { 229 | margin: 20px 0px; 230 | padding: 10px 30px; 231 | background-color: #EEE; 232 | border: 1px solid #CCC; 233 | } 234 | 235 | div.admonition tt.xref, div.admonition code.xref, div.admonition a tt { 236 | background-color: #FBFBFB; 237 | border-bottom: 1px solid #fafafa; 238 | } 239 | 240 | div.admonition p.admonition-title { 241 | font-family: Georgia, serif; 242 | font-weight: normal; 243 | font-size: 24px; 244 | margin: 0 0 10px 0; 245 | padding: 0; 246 | line-height: 1; 247 | } 248 | 249 | div.admonition p.last { 250 | margin-bottom: 0; 251 | } 252 | 253 | div.highlight { 254 | background-color: #fff; 255 | } 256 | 257 | dt:target, .highlight { 258 | background: #FAF3E8; 259 | } 260 | 261 | div.warning { 262 | background-color: #FCC; 263 | border: 1px solid #FAA; 264 | } 265 | 266 | div.danger { 267 | background-color: #FCC; 268 | border: 1px solid #FAA; 269 | -moz-box-shadow: 2px 2px 4px #D52C2C; 270 | -webkit-box-shadow: 2px 2px 4px #D52C2C; 271 | box-shadow: 2px 2px 4px #D52C2C; 272 | } 273 | 274 | div.error { 275 | background-color: #FCC; 276 | border: 1px solid #FAA; 277 | -moz-box-shadow: 2px 2px 4px #D52C2C; 278 | -webkit-box-shadow: 2px 2px 4px #D52C2C; 279 | box-shadow: 2px 2px 4px #D52C2C; 280 | } 281 | 282 | div.caution { 283 | background-color: #FCC; 284 | border: 1px solid #FAA; 285 | } 286 | 287 | div.attention { 288 | background-color: #FCC; 289 | border: 1px solid #FAA; 290 | } 291 | 292 | div.important { 293 | background-color: #EEE; 294 | border: 1px solid #CCC; 295 | } 296 | 297 | div.note { 298 | background-color: #EEE; 299 | border: 1px solid #CCC; 300 | } 301 | 302 | div.tip { 303 | background-color: #EEE; 304 | border: 1px solid #CCC; 305 | } 306 | 307 | div.hint { 308 | background-color: #EEE; 309 | border: 1px solid #CCC; 310 | } 311 | 312 | div.seealso { 313 | background-color: #EEE; 314 | border: 1px solid #CCC; 315 | } 316 | 317 | div.topic { 318 | background-color: #EEE; 319 | } 320 | 321 | p.admonition-title { 322 | display: inline; 323 | } 324 | 325 | p.admonition-title:after { 326 | content: ":"; 327 | } 328 | 329 | pre, tt, code { 330 | font-family: 'Consolas', 'Menlo', 'DejaVu Sans Mono', 'Bitstream Vera Sans Mono', monospace; 331 | font-size: 0.9em; 332 | } 333 | 334 | .hll { 335 | background-color: #FFC; 336 | margin: 0 -12px; 337 | padding: 0 12px; 338 | display: block; 339 | } 340 | 341 | img.screenshot { 342 | } 343 | 344 | tt.descname, tt.descclassname, code.descname, code.descclassname { 345 | font-size: 0.95em; 346 | } 347 | 348 | tt.descname, code.descname { 349 | padding-right: 0.08em; 350 | } 351 | 352 | img.screenshot { 353 | -moz-box-shadow: 2px 2px 4px #EEE; 354 | -webkit-box-shadow: 2px 2px 4px #EEE; 355 | box-shadow: 2px 2px 4px #EEE; 356 | } 357 | 358 | table.docutils { 359 | border: 1px solid #888; 360 | -moz-box-shadow: 2px 2px 4px #EEE; 361 | -webkit-box-shadow: 2px 2px 4px #EEE; 362 | box-shadow: 2px 2px 4px #EEE; 363 | } 364 | 365 | table.docutils td, table.docutils th { 366 | border: 1px solid #888; 367 | padding: 0.25em 0.7em; 368 | } 369 | 370 | table.field-list, table.footnote { 371 | border: none; 372 | -moz-box-shadow: none; 373 | -webkit-box-shadow: none; 374 | box-shadow: none; 375 | } 376 | 377 | table.footnote { 378 | margin: 15px 0; 379 | width: 100%; 380 | border: 1px solid #EEE; 381 | background: #FDFDFD; 382 | font-size: 0.9em; 383 | } 384 | 385 | table.footnote + table.footnote { 386 | margin-top: -15px; 387 | border-top: none; 388 | } 389 | 390 | table.field-list th { 391 | padding: 0 0.8em 0 0; 392 | } 393 | 394 | table.field-list td { 395 | padding: 0; 396 | } 397 | 398 | table.field-list p { 399 | margin-bottom: 0.8em; 400 | } 401 | 402 | /* Cloned from 403 | * https://github.com/sphinx-doc/sphinx/commit/ef60dbfce09286b20b7385333d63a60321784e68 404 | */ 405 | .field-name { 406 | -moz-hyphens: manual; 407 | -ms-hyphens: manual; 408 | -webkit-hyphens: manual; 409 | hyphens: manual; 410 | } 411 | 412 | table.footnote td.label { 413 | width: .1px; 414 | padding: 0.3em 0 0.3em 0.5em; 415 | } 416 | 417 | table.footnote td { 418 | padding: 0.3em 0.5em; 419 | } 420 | 421 | dl { 422 | margin: 0; 423 | padding: 0; 424 | } 425 | 426 | dl dd { 427 | margin-left: 30px; 428 | } 429 | 430 | blockquote { 431 | margin: 0 0 0 30px; 432 | padding: 0; 433 | } 434 | 435 | ul, ol { 436 | /* Matches the 30px from the narrow-screen "li > ul" selector below */ 437 | margin: 10px 0 10px 30px; 438 | padding: 0; 439 | } 440 | 441 | pre { 442 | background: #EEE; 443 | padding: 7px 30px; 444 | margin: 15px 0px; 445 | line-height: 1.3em; 446 | } 447 | 448 | div.viewcode-block:target { 449 | background: #ffd; 450 | } 451 | 452 | dl pre, blockquote pre, li pre { 453 | margin-left: 0; 454 | padding-left: 30px; 455 | } 456 | 457 | tt, code { 458 | background-color: #ecf0f3; 459 | color: #222; 460 | /* padding: 1px 2px; */ 461 | } 462 | 463 | tt.xref, code.xref, a tt { 464 | background-color: #FBFBFB; 465 | border-bottom: 1px solid #fff; 466 | } 467 | 468 | a.reference { 469 | text-decoration: none; 470 | border-bottom: 1px dotted #004B6B; 471 | } 472 | 473 | /* Don't put an underline on images */ 474 | a.image-reference, a.image-reference:hover { 475 | border-bottom: none; 476 | } 477 | 478 | a.reference:hover { 479 | border-bottom: 1px solid #6D4100; 480 | } 481 | 482 | a.footnote-reference { 483 | text-decoration: none; 484 | font-size: 0.7em; 485 | vertical-align: top; 486 | border-bottom: 1px dotted #004B6B; 487 | } 488 | 489 | a.footnote-reference:hover { 490 | border-bottom: 1px solid #6D4100; 491 | } 492 | 493 | a:hover tt, a:hover code { 494 | background: #EEE; 495 | } 496 | 497 | 498 | @media screen and (max-width: 870px) { 499 | 500 | div.sphinxsidebar { 501 | display: none; 502 | } 503 | 504 | div.document { 505 | width: 100%; 506 | 507 | } 508 | 509 | div.documentwrapper { 510 | margin-left: 0; 511 | margin-top: 0; 512 | margin-right: 0; 513 | margin-bottom: 0; 514 | } 515 | 516 | div.bodywrapper { 517 | margin-top: 0; 518 | margin-right: 0; 519 | margin-bottom: 0; 520 | margin-left: 0; 521 | } 522 | 523 | ul { 524 | margin-left: 0; 525 | } 526 | 527 | li > ul { 528 | /* Matches the 30px from the "ul, ol" selector above */ 529 | margin-left: 30px; 530 | } 531 | 532 | .document { 533 | width: auto; 534 | } 535 | 536 | .footer { 537 | width: auto; 538 | } 539 | 540 | .bodywrapper { 541 | margin: 0; 542 | } 543 | 544 | .footer { 545 | width: auto; 546 | } 547 | 548 | .github { 549 | display: none; 550 | } 551 | 552 | 553 | 554 | } 555 | 556 | 557 | 558 | @media screen and (max-width: 875px) { 559 | 560 | body { 561 | margin: 0; 562 | padding: 20px 30px; 563 | } 564 | 565 | div.documentwrapper { 566 | float: none; 567 | background: #fff; 568 | } 569 | 570 | div.sphinxsidebar { 571 | display: block; 572 | float: none; 573 | width: 102.5%; 574 | margin: 50px -30px -20px -30px; 575 | padding: 10px 20px; 576 | background: #333; 577 | color: #FFF; 578 | } 579 | 580 | div.sphinxsidebar h3, div.sphinxsidebar h4, div.sphinxsidebar p, 581 | div.sphinxsidebar h3 a { 582 | color: #fff; 583 | } 584 | 585 | div.sphinxsidebar a { 586 | color: #AAA; 587 | } 588 | 589 | div.sphinxsidebar p.logo { 590 | display: none; 591 | } 592 | 593 | div.document { 594 | width: 100%; 595 | margin: 0; 596 | } 597 | 598 | div.footer { 599 | display: none; 600 | } 601 | 602 | div.bodywrapper { 603 | margin: 0; 604 | } 605 | 606 | div.body { 607 | min-height: 0; 608 | padding: 0; 609 | } 610 | 611 | .rtd_doc_footer { 612 | display: none; 613 | } 614 | 615 | .document { 616 | width: auto; 617 | } 618 | 619 | .footer { 620 | width: auto; 621 | } 622 | 623 | .footer { 624 | width: auto; 625 | } 626 | 627 | .github { 628 | display: none; 629 | } 630 | } 631 | 632 | 633 | /* misc. */ 634 | 635 | .revsys-inline { 636 | display: none!important; 637 | } 638 | 639 | /* Make nested-list/multi-paragraph items look better in Releases changelog 640 | * pages. Without this, docutils' magical list fuckery causes inconsistent 641 | * formatting between different release sub-lists. 642 | */ 643 | div#changelog > div.section > ul > li > p:only-child { 644 | margin-bottom: 0; 645 | } 646 | 647 | /* Hide fugly table cell borders in ..bibliography:: directive output */ 648 | table.docutils.citation, table.docutils.citation td, table.docutils.citation th { 649 | border: none; 650 | /* Below needed in some edge cases; if not applied, bottom shadows appear */ 651 | -moz-box-shadow: none; 652 | -webkit-box-shadow: none; 653 | box-shadow: none; 654 | } 655 | 656 | 657 | /* relbar */ 658 | 659 | .related { 660 | line-height: 30px; 661 | width: 100%; 662 | font-size: 0.9rem; 663 | } 664 | 665 | .related.top { 666 | border-bottom: 1px solid #EEE; 667 | margin-bottom: 20px; 668 | } 669 | 670 | .related.bottom { 671 | border-top: 1px solid #EEE; 672 | } 673 | 674 | .related ul { 675 | padding: 0; 676 | margin: 0; 677 | list-style: none; 678 | } 679 | 680 | .related li { 681 | display: inline; 682 | } 683 | 684 | nav#rellinks { 685 | float: right; 686 | } 687 | 688 | nav#rellinks li+li:before { 689 | content: "|"; 690 | } 691 | 692 | nav#breadcrumbs li+li:before { 693 | content: "\00BB"; 694 | } 695 | 696 | /* Hide certain items when printing */ 697 | @media print { 698 | div.related { 699 | display: none; 700 | } 701 | } -------------------------------------------------------------------------------- /docs/static/basic.css: -------------------------------------------------------------------------------- 1 | /* 2 | * basic.css 3 | * ~~~~~~~~~ 4 | * 5 | * Sphinx stylesheet -- basic theme. 6 | * 7 | * :copyright: Copyright 2007-2019 by the Sphinx team, see AUTHORS. 8 | * :license: BSD, see LICENSE for details. 9 | * 10 | */ 11 | 12 | /* -- main layout ----------------------------------------------------------- */ 13 | 14 | div.clearer { 15 | clear: both; 16 | } 17 | 18 | /* -- relbar ---------------------------------------------------------------- */ 19 | 20 | div.related { 21 | width: 100%; 22 | font-size: 90%; 23 | } 24 | 25 | div.related h3 { 26 | display: none; 27 | } 28 | 29 | div.related ul { 30 | margin: 0; 31 | padding: 0 0 0 10px; 32 | list-style: none; 33 | } 34 | 35 | div.related li { 36 | display: inline; 37 | } 38 | 39 | div.related li.right { 40 | float: right; 41 | margin-right: 5px; 42 | } 43 | 44 | /* -- sidebar --------------------------------------------------------------- */ 45 | 46 | div.sphinxsidebarwrapper { 47 | padding: 10px 5px 0 10px; 48 | } 49 | 50 | div.sphinxsidebar { 51 | float: left; 52 | width: 230px; 53 | margin-left: -100%; 54 | font-size: 90%; 55 | word-wrap: break-word; 56 | overflow-wrap : break-word; 57 | } 58 | 59 | div.sphinxsidebar ul { 60 | list-style: none; 61 | } 62 | 63 | div.sphinxsidebar ul ul, 64 | div.sphinxsidebar ul.want-points { 65 | margin-left: 20px; 66 | list-style: square; 67 | } 68 | 69 | div.sphinxsidebar ul ul { 70 | margin-top: 0; 71 | margin-bottom: 0; 72 | } 73 | 74 | div.sphinxsidebar form { 75 | margin-top: 10px; 76 | } 77 | 78 | div.sphinxsidebar input { 79 | border: 1px solid #98dbcc; 80 | font-family: sans-serif; 81 | font-size: 1em; 82 | } 83 | 84 | div.sphinxsidebar #searchbox form.search { 85 | overflow: hidden; 86 | } 87 | 88 | div.sphinxsidebar #searchbox input[type="text"] { 89 | float: left; 90 | width: 80%; 91 | padding: 0.25em; 92 | box-sizing: border-box; 93 | } 94 | 95 | div.sphinxsidebar #searchbox input[type="submit"] { 96 | float: left; 97 | width: 20%; 98 | border-left: none; 99 | padding: 0.25em; 100 | box-sizing: border-box; 101 | } 102 | 103 | 104 | img { 105 | border: 0; 106 | max-width: 100%; 107 | } 108 | 109 | /* -- search page ----------------------------------------------------------- */ 110 | 111 | ul.search { 112 | margin: 10px 0 0 20px; 113 | padding: 0; 114 | } 115 | 116 | ul.search li { 117 | padding: 5px 0 5px 20px; 118 | background-image: url(file.png); 119 | background-repeat: no-repeat; 120 | background-position: 0 7px; 121 | } 122 | 123 | ul.search li a { 124 | font-weight: bold; 125 | } 126 | 127 | ul.search li div.context { 128 | color: #888; 129 | margin: 2px 0 0 30px; 130 | text-align: left; 131 | } 132 | 133 | ul.keywordmatches li.goodmatch a { 134 | font-weight: bold; 135 | } 136 | 137 | /* -- index page ------------------------------------------------------------ */ 138 | 139 | table.contentstable { 140 | width: 90%; 141 | margin-left: auto; 142 | margin-right: auto; 143 | } 144 | 145 | table.contentstable p.biglink { 146 | line-height: 150%; 147 | } 148 | 149 | a.biglink { 150 | font-size: 1.3em; 151 | } 152 | 153 | span.linkdescr { 154 | font-style: italic; 155 | padding-top: 5px; 156 | font-size: 90%; 157 | } 158 | 159 | /* -- general index --------------------------------------------------------- */ 160 | 161 | table.indextable { 162 | width: 100%; 163 | } 164 | 165 | table.indextable td { 166 | text-align: left; 167 | vertical-align: top; 168 | } 169 | 170 | table.indextable ul { 171 | margin-top: 0; 172 | margin-bottom: 0; 173 | list-style-type: none; 174 | } 175 | 176 | table.indextable > tbody > tr > td > ul { 177 | padding-left: 0em; 178 | } 179 | 180 | table.indextable tr.pcap { 181 | height: 10px; 182 | } 183 | 184 | table.indextable tr.cap { 185 | margin-top: 10px; 186 | background-color: #f2f2f2; 187 | } 188 | 189 | img.toggler { 190 | margin-right: 3px; 191 | margin-top: 3px; 192 | cursor: pointer; 193 | } 194 | 195 | div.modindex-jumpbox { 196 | border-top: 1px solid #ddd; 197 | border-bottom: 1px solid #ddd; 198 | margin: 1em 0 1em 0; 199 | padding: 0.4em; 200 | } 201 | 202 | div.genindex-jumpbox { 203 | border-top: 1px solid #ddd; 204 | border-bottom: 1px solid #ddd; 205 | margin: 1em 0 1em 0; 206 | padding: 0.4em; 207 | } 208 | 209 | /* -- domain module index --------------------------------------------------- */ 210 | 211 | table.modindextable td { 212 | padding: 2px; 213 | border-collapse: collapse; 214 | } 215 | 216 | /* -- general body styles --------------------------------------------------- */ 217 | 218 | div.body { 219 | min-width: 450px; 220 | max-width: 800px; 221 | } 222 | 223 | div.body p, div.body dd, div.body li, div.body blockquote { 224 | -moz-hyphens: auto; 225 | -ms-hyphens: auto; 226 | -webkit-hyphens: auto; 227 | hyphens: auto; 228 | } 229 | 230 | a.headerlink { 231 | visibility: hidden; 232 | } 233 | 234 | h1:hover > a.headerlink, 235 | h2:hover > a.headerlink, 236 | h3:hover > a.headerlink, 237 | h4:hover > a.headerlink, 238 | h5:hover > a.headerlink, 239 | h6:hover > a.headerlink, 240 | dt:hover > a.headerlink, 241 | caption:hover > a.headerlink, 242 | p.caption:hover > a.headerlink, 243 | div.code-block-caption:hover > a.headerlink { 244 | visibility: visible; 245 | } 246 | 247 | div.body p.caption { 248 | text-align: inherit; 249 | } 250 | 251 | div.body td { 252 | text-align: left; 253 | } 254 | 255 | .first { 256 | margin-top: 0 !important; 257 | } 258 | 259 | p.rubric { 260 | margin-top: 30px; 261 | font-weight: bold; 262 | } 263 | 264 | img.align-left, .figure.align-left, object.align-left { 265 | clear: left; 266 | float: left; 267 | margin-right: 1em; 268 | } 269 | 270 | img.align-right, .figure.align-right, object.align-right { 271 | clear: right; 272 | float: right; 273 | margin-left: 1em; 274 | } 275 | 276 | img.align-center, .figure.align-center, object.align-center { 277 | display: block; 278 | margin-left: auto; 279 | margin-right: auto; 280 | } 281 | 282 | .align-left { 283 | text-align: left; 284 | } 285 | 286 | .align-center { 287 | text-align: center; 288 | } 289 | 290 | .align-right { 291 | text-align: right; 292 | } 293 | 294 | /* -- sidebars -------------------------------------------------------------- */ 295 | 296 | div.sidebar { 297 | margin: 0 0 0.5em 1em; 298 | border: 1px solid #ddb; 299 | padding: 7px 7px 0 7px; 300 | background-color: #ffe; 301 | width: 40%; 302 | float: right; 303 | } 304 | 305 | p.sidebar-title { 306 | font-weight: bold; 307 | } 308 | 309 | /* -- topics ---------------------------------------------------------------- */ 310 | 311 | div.topic { 312 | border: 1px solid #ccc; 313 | padding: 7px 7px 0 7px; 314 | margin: 10px 0 10px 0; 315 | } 316 | 317 | p.topic-title { 318 | font-size: 1.1em; 319 | font-weight: bold; 320 | margin-top: 10px; 321 | } 322 | 323 | /* -- admonitions ----------------------------------------------------------- */ 324 | 325 | div.admonition { 326 | margin-top: 10px; 327 | margin-bottom: 10px; 328 | padding: 7px; 329 | } 330 | 331 | div.admonition dt { 332 | font-weight: bold; 333 | } 334 | 335 | div.admonition dl { 336 | margin-bottom: 0; 337 | } 338 | 339 | p.admonition-title { 340 | margin: 0px 10px 5px 0px; 341 | font-weight: bold; 342 | } 343 | 344 | div.body p.centered { 345 | text-align: center; 346 | margin-top: 25px; 347 | } 348 | 349 | /* -- tables ---------------------------------------------------------------- */ 350 | 351 | table.docutils { 352 | border: 0; 353 | border-collapse: collapse; 354 | } 355 | 356 | table.align-center { 357 | margin-left: auto; 358 | margin-right: auto; 359 | } 360 | 361 | table caption span.caption-number { 362 | font-style: italic; 363 | } 364 | 365 | table caption span.caption-text { 366 | } 367 | 368 | table.docutils td, table.docutils th { 369 | padding: 1px 8px 1px 5px; 370 | border-top: 0; 371 | border-left: 0; 372 | border-right: 0; 373 | border-bottom: 1px solid #aaa; 374 | } 375 | 376 | table.footnote td, table.footnote th { 377 | border: 0 !important; 378 | } 379 | 380 | th { 381 | text-align: left; 382 | padding-right: 5px; 383 | } 384 | 385 | table.citation { 386 | border-left: solid 1px gray; 387 | margin-left: 1px; 388 | } 389 | 390 | table.citation td { 391 | border-bottom: none; 392 | } 393 | 394 | /* -- figures --------------------------------------------------------------- */ 395 | 396 | div.figure { 397 | margin: 0.5em; 398 | padding: 0.5em; 399 | } 400 | 401 | div.figure p.caption { 402 | padding: 0.3em; 403 | } 404 | 405 | div.figure p.caption span.caption-number { 406 | font-style: italic; 407 | } 408 | 409 | div.figure p.caption span.caption-text { 410 | } 411 | 412 | /* -- field list styles ----------------------------------------------------- */ 413 | 414 | table.field-list td, table.field-list th { 415 | border: 0 !important; 416 | } 417 | 418 | .field-list ul { 419 | margin: 0; 420 | padding-left: 1em; 421 | } 422 | 423 | .field-list p { 424 | margin: 0; 425 | } 426 | 427 | .field-name { 428 | -moz-hyphens: manual; 429 | -ms-hyphens: manual; 430 | -webkit-hyphens: manual; 431 | hyphens: manual; 432 | } 433 | 434 | /* -- hlist styles ---------------------------------------------------------- */ 435 | 436 | table.hlist td { 437 | vertical-align: top; 438 | } 439 | 440 | 441 | /* -- other body styles ----------------------------------------------------- */ 442 | 443 | ol.arabic { 444 | list-style: decimal; 445 | } 446 | 447 | ol.loweralpha { 448 | list-style: lower-alpha; 449 | } 450 | 451 | ol.upperalpha { 452 | list-style: upper-alpha; 453 | } 454 | 455 | ol.lowerroman { 456 | list-style: lower-roman; 457 | } 458 | 459 | ol.upperroman { 460 | list-style: upper-roman; 461 | } 462 | 463 | dl { 464 | margin-bottom: 15px; 465 | } 466 | 467 | dd p { 468 | margin-top: 0px; 469 | } 470 | 471 | dd ul, dd table { 472 | margin-bottom: 10px; 473 | } 474 | 475 | dd { 476 | margin-top: 3px; 477 | margin-bottom: 10px; 478 | margin-left: 30px; 479 | } 480 | 481 | dt:target, span.highlighted { 482 | background-color: #fbe54e; 483 | } 484 | 485 | rect.highlighted { 486 | fill: #fbe54e; 487 | } 488 | 489 | dl.glossary dt { 490 | font-weight: bold; 491 | font-size: 1.1em; 492 | } 493 | 494 | .optional { 495 | font-size: 1.3em; 496 | } 497 | 498 | .sig-paren { 499 | font-size: larger; 500 | } 501 | 502 | .versionmodified { 503 | font-style: italic; 504 | } 505 | 506 | .system-message { 507 | background-color: #fda; 508 | padding: 5px; 509 | border: 3px solid red; 510 | } 511 | 512 | .footnote:target { 513 | background-color: #ffa; 514 | } 515 | 516 | .line-block { 517 | display: block; 518 | margin-top: 1em; 519 | margin-bottom: 1em; 520 | } 521 | 522 | .line-block .line-block { 523 | margin-top: 0; 524 | margin-bottom: 0; 525 | margin-left: 1.5em; 526 | } 527 | 528 | .guilabel, .menuselection { 529 | font-family: sans-serif; 530 | } 531 | 532 | .accelerator { 533 | text-decoration: underline; 534 | } 535 | 536 | .classifier { 537 | font-style: oblique; 538 | } 539 | 540 | abbr, acronym { 541 | border-bottom: dotted 1px; 542 | cursor: help; 543 | } 544 | 545 | /* -- code displays --------------------------------------------------------- */ 546 | 547 | pre { 548 | overflow: auto; 549 | overflow-y: hidden; /* fixes display issues on Chrome browsers */ 550 | } 551 | 552 | span.pre { 553 | -moz-hyphens: none; 554 | -ms-hyphens: none; 555 | -webkit-hyphens: none; 556 | hyphens: none; 557 | } 558 | 559 | td.linenos pre { 560 | padding: 5px 0px; 561 | border: 0; 562 | background-color: transparent; 563 | color: #aaa; 564 | } 565 | 566 | table.highlighttable { 567 | margin-left: 0.5em; 568 | } 569 | 570 | table.highlighttable td { 571 | padding: 0 0.5em 0 0.5em; 572 | } 573 | 574 | div.code-block-caption { 575 | padding: 2px 5px; 576 | font-size: small; 577 | } 578 | 579 | div.code-block-caption code { 580 | background-color: transparent; 581 | } 582 | 583 | div.code-block-caption + div > div.highlight > pre { 584 | margin-top: 0; 585 | } 586 | 587 | div.code-block-caption span.caption-number { 588 | padding: 0.1em 0.3em; 589 | font-style: italic; 590 | } 591 | 592 | div.code-block-caption span.caption-text { 593 | } 594 | 595 | div.literal-block-wrapper { 596 | padding: 1em 1em 0; 597 | } 598 | 599 | div.literal-block-wrapper div.highlight { 600 | margin: 0; 601 | } 602 | 603 | code.descname { 604 | background-color: transparent; 605 | font-weight: bold; 606 | font-size: 1.2em; 607 | } 608 | 609 | code.descclassname { 610 | background-color: transparent; 611 | } 612 | 613 | code.xref, a code { 614 | background-color: transparent; 615 | font-weight: bold; 616 | } 617 | 618 | h1 code, h2 code, h3 code, h4 code, h5 code, h6 code { 619 | background-color: transparent; 620 | } 621 | 622 | .viewcode-link { 623 | float: right; 624 | } 625 | 626 | .viewcode-back { 627 | float: right; 628 | font-family: sans-serif; 629 | } 630 | 631 | div.viewcode-block:target { 632 | margin: -1px -10px; 633 | padding: 0 10px; 634 | } 635 | 636 | /* -- math display ---------------------------------------------------------- */ 637 | 638 | img.math { 639 | vertical-align: middle; 640 | } 641 | 642 | div.body div.math p { 643 | text-align: center; 644 | } 645 | 646 | span.eqno { 647 | float: right; 648 | } 649 | 650 | span.eqno a.headerlink { 651 | position: relative; 652 | left: 0px; 653 | z-index: 1; 654 | } 655 | 656 | div.math:hover a.headerlink { 657 | visibility: visible; 658 | } 659 | 660 | /* -- printout stylesheet --------------------------------------------------- */ 661 | 662 | @media print { 663 | div.document, 664 | div.documentwrapper, 665 | div.bodywrapper { 666 | margin: 0 !important; 667 | width: 100%; 668 | } 669 | 670 | div.sphinxsidebar, 671 | div.related, 672 | div.footer, 673 | #top-link { 674 | display: none; 675 | } 676 | } -------------------------------------------------------------------------------- /docs/static/comment-bright.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/supertylerc/jncip-dc-notes/6d6b868bd16e1a901dbc0aef90030b17c5398fc5/docs/static/comment-bright.png -------------------------------------------------------------------------------- /docs/static/comment-close.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/supertylerc/jncip-dc-notes/6d6b868bd16e1a901dbc0aef90030b17c5398fc5/docs/static/comment-close.png -------------------------------------------------------------------------------- /docs/static/comment.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/supertylerc/jncip-dc-notes/6d6b868bd16e1a901dbc0aef90030b17c5398fc5/docs/static/comment.png -------------------------------------------------------------------------------- /docs/static/custom.css: -------------------------------------------------------------------------------- 1 | /* This file intentionally left blank. */ 2 | -------------------------------------------------------------------------------- /docs/static/doctools.js: -------------------------------------------------------------------------------- 1 | /* 2 | * doctools.js 3 | * ~~~~~~~~~~~ 4 | * 5 | * Sphinx JavaScript utilities for all documentation. 6 | * 7 | * :copyright: Copyright 2007-2019 by the Sphinx team, see AUTHORS. 8 | * :license: BSD, see LICENSE for details. 9 | * 10 | */ 11 | 12 | /** 13 | * select a different prefix for underscore 14 | */ 15 | $u = _.noConflict(); 16 | 17 | /** 18 | * make the code below compatible with browsers without 19 | * an installed firebug like debugger 20 | if (!window.console || !console.firebug) { 21 | var names = ["log", "debug", "info", "warn", "error", "assert", "dir", 22 | "dirxml", "group", "groupEnd", "time", "timeEnd", "count", "trace", 23 | "profile", "profileEnd"]; 24 | window.console = {}; 25 | for (var i = 0; i < names.length; ++i) 26 | window.console[names[i]] = function() {}; 27 | } 28 | */ 29 | 30 | /** 31 | * small helper function to urldecode strings 32 | */ 33 | jQuery.urldecode = function(x) { 34 | return decodeURIComponent(x).replace(/\+/g, ' '); 35 | }; 36 | 37 | /** 38 | * small helper function to urlencode strings 39 | */ 40 | jQuery.urlencode = encodeURIComponent; 41 | 42 | /** 43 | * This function returns the parsed url parameters of the 44 | * current request. Multiple values per key are supported, 45 | * it will always return arrays of strings for the value parts. 46 | */ 47 | jQuery.getQueryParameters = function(s) { 48 | if (typeof s === 'undefined') 49 | s = document.location.search; 50 | var parts = s.substr(s.indexOf('?') + 1).split('&'); 51 | var result = {}; 52 | for (var i = 0; i < parts.length; i++) { 53 | var tmp = parts[i].split('=', 2); 54 | var key = jQuery.urldecode(tmp[0]); 55 | var value = jQuery.urldecode(tmp[1]); 56 | if (key in result) 57 | result[key].push(value); 58 | else 59 | result[key] = [value]; 60 | } 61 | return result; 62 | }; 63 | 64 | /** 65 | * highlight a given string on a jquery object by wrapping it in 66 | * span elements with the given class name. 67 | */ 68 | jQuery.fn.highlightText = function(text, className) { 69 | function highlight(node, addItems) { 70 | if (node.nodeType === 3) { 71 | var val = node.nodeValue; 72 | var pos = val.toLowerCase().indexOf(text); 73 | if (pos >= 0 && 74 | !jQuery(node.parentNode).hasClass(className) && 75 | !jQuery(node.parentNode).hasClass("nohighlight")) { 76 | var span; 77 | var isInSVG = jQuery(node).closest("body, svg, foreignObject").is("svg"); 78 | if (isInSVG) { 79 | span = document.createElementNS("http://www.w3.org/2000/svg", "tspan"); 80 | } else { 81 | span = document.createElement("span"); 82 | span.className = className; 83 | } 84 | span.appendChild(document.createTextNode(val.substr(pos, text.length))); 85 | node.parentNode.insertBefore(span, node.parentNode.insertBefore( 86 | document.createTextNode(val.substr(pos + text.length)), 87 | node.nextSibling)); 88 | node.nodeValue = val.substr(0, pos); 89 | if (isInSVG) { 90 | var bbox = span.getBBox(); 91 | var rect = document.createElementNS("http://www.w3.org/2000/svg", "rect"); 92 | rect.x.baseVal.value = bbox.x; 93 | rect.y.baseVal.value = bbox.y; 94 | rect.width.baseVal.value = bbox.width; 95 | rect.height.baseVal.value = bbox.height; 96 | rect.setAttribute('class', className); 97 | var parentOfText = node.parentNode.parentNode; 98 | addItems.push({ 99 | "parent": node.parentNode, 100 | "target": rect}); 101 | } 102 | } 103 | } 104 | else if (!jQuery(node).is("button, select, textarea")) { 105 | jQuery.each(node.childNodes, function() { 106 | highlight(this, addItems); 107 | }); 108 | } 109 | } 110 | var addItems = []; 111 | var result = this.each(function() { 112 | highlight(this, addItems); 113 | }); 114 | for (var i = 0; i < addItems.length; ++i) { 115 | jQuery(addItems[i].parent).before(addItems[i].target); 116 | } 117 | return result; 118 | }; 119 | 120 | /* 121 | * backward compatibility for jQuery.browser 122 | * This will be supported until firefox bug is fixed. 123 | */ 124 | if (!jQuery.browser) { 125 | jQuery.uaMatch = function(ua) { 126 | ua = ua.toLowerCase(); 127 | 128 | var match = /(chrome)[ \/]([\w.]+)/.exec(ua) || 129 | /(webkit)[ \/]([\w.]+)/.exec(ua) || 130 | /(opera)(?:.*version|)[ \/]([\w.]+)/.exec(ua) || 131 | /(msie) ([\w.]+)/.exec(ua) || 132 | ua.indexOf("compatible") < 0 && /(mozilla)(?:.*? rv:([\w.]+)|)/.exec(ua) || 133 | []; 134 | 135 | return { 136 | browser: match[ 1 ] || "", 137 | version: match[ 2 ] || "0" 138 | }; 139 | }; 140 | jQuery.browser = {}; 141 | jQuery.browser[jQuery.uaMatch(navigator.userAgent).browser] = true; 142 | } 143 | 144 | /** 145 | * Small JavaScript module for the documentation. 146 | */ 147 | var Documentation = { 148 | 149 | init : function() { 150 | this.fixFirefoxAnchorBug(); 151 | this.highlightSearchWords(); 152 | this.initIndexTable(); 153 | if (DOCUMENTATION_OPTIONS.NAVIGATION_WITH_KEYS) { 154 | this.initOnKeyListeners(); 155 | } 156 | }, 157 | 158 | /** 159 | * i18n support 160 | */ 161 | TRANSLATIONS : {}, 162 | PLURAL_EXPR : function(n) { return n === 1 ? 0 : 1; }, 163 | LOCALE : 'unknown', 164 | 165 | // gettext and ngettext don't access this so that the functions 166 | // can safely bound to a different name (_ = Documentation.gettext) 167 | gettext : function(string) { 168 | var translated = Documentation.TRANSLATIONS[string]; 169 | if (typeof translated === 'undefined') 170 | return string; 171 | return (typeof translated === 'string') ? translated : translated[0]; 172 | }, 173 | 174 | ngettext : function(singular, plural, n) { 175 | var translated = Documentation.TRANSLATIONS[singular]; 176 | if (typeof translated === 'undefined') 177 | return (n == 1) ? singular : plural; 178 | return translated[Documentation.PLURALEXPR(n)]; 179 | }, 180 | 181 | addTranslations : function(catalog) { 182 | for (var key in catalog.messages) 183 | this.TRANSLATIONS[key] = catalog.messages[key]; 184 | this.PLURAL_EXPR = new Function('n', 'return +(' + catalog.plural_expr + ')'); 185 | this.LOCALE = catalog.locale; 186 | }, 187 | 188 | /** 189 | * add context elements like header anchor links 190 | */ 191 | addContextElements : function() { 192 | $('div[id] > :header:first').each(function() { 193 | $('\u00B6'). 194 | attr('href', '#' + this.id). 195 | attr('title', _('Permalink to this headline')). 196 | appendTo(this); 197 | }); 198 | $('dt[id]').each(function() { 199 | $('\u00B6'). 200 | attr('href', '#' + this.id). 201 | attr('title', _('Permalink to this definition')). 202 | appendTo(this); 203 | }); 204 | }, 205 | 206 | /** 207 | * workaround a firefox stupidity 208 | * see: https://bugzilla.mozilla.org/show_bug.cgi?id=645075 209 | */ 210 | fixFirefoxAnchorBug : function() { 211 | if (document.location.hash && $.browser.mozilla) 212 | window.setTimeout(function() { 213 | document.location.href += ''; 214 | }, 10); 215 | }, 216 | 217 | /** 218 | * highlight the search words provided in the url in the text 219 | */ 220 | highlightSearchWords : function() { 221 | var params = $.getQueryParameters(); 222 | var terms = (params.highlight) ? params.highlight[0].split(/\s+/) : []; 223 | if (terms.length) { 224 | var body = $('div.body'); 225 | if (!body.length) { 226 | body = $('body'); 227 | } 228 | window.setTimeout(function() { 229 | $.each(terms, function() { 230 | body.highlightText(this.toLowerCase(), 'highlighted'); 231 | }); 232 | }, 10); 233 | $('

' + _('Hide Search Matches') + '

') 235 | .appendTo($('#searchbox')); 236 | } 237 | }, 238 | 239 | /** 240 | * init the domain index toggle buttons 241 | */ 242 | initIndexTable : function() { 243 | var togglers = $('img.toggler').click(function() { 244 | var src = $(this).attr('src'); 245 | var idnum = $(this).attr('id').substr(7); 246 | $('tr.cg-' + idnum).toggle(); 247 | if (src.substr(-9) === 'minus.png') 248 | $(this).attr('src', src.substr(0, src.length-9) + 'plus.png'); 249 | else 250 | $(this).attr('src', src.substr(0, src.length-8) + 'minus.png'); 251 | }).css('display', ''); 252 | if (DOCUMENTATION_OPTIONS.COLLAPSE_INDEX) { 253 | togglers.click(); 254 | } 255 | }, 256 | 257 | /** 258 | * helper function to hide the search marks again 259 | */ 260 | hideSearchWords : function() { 261 | $('#searchbox .highlight-link').fadeOut(300); 262 | $('span.highlighted').removeClass('highlighted'); 263 | }, 264 | 265 | /** 266 | * make the url absolute 267 | */ 268 | makeURL : function(relativeURL) { 269 | return DOCUMENTATION_OPTIONS.URL_ROOT + '/' + relativeURL; 270 | }, 271 | 272 | /** 273 | * get the current relative url 274 | */ 275 | getCurrentURL : function() { 276 | var path = document.location.pathname; 277 | var parts = path.split(/\//); 278 | $.each(DOCUMENTATION_OPTIONS.URL_ROOT.split(/\//), function() { 279 | if (this === '..') 280 | parts.pop(); 281 | }); 282 | var url = parts.join('/'); 283 | return path.substring(url.lastIndexOf('/') + 1, path.length - 1); 284 | }, 285 | 286 | initOnKeyListeners: function() { 287 | $(document).keyup(function(event) { 288 | var activeElementType = document.activeElement.tagName; 289 | // don't navigate when in search box or textarea 290 | if (activeElementType !== 'TEXTAREA' && activeElementType !== 'INPUT' && activeElementType !== 'SELECT') { 291 | switch (event.keyCode) { 292 | case 37: // left 293 | var prevHref = $('link[rel="prev"]').prop('href'); 294 | if (prevHref) { 295 | window.location.href = prevHref; 296 | return false; 297 | } 298 | case 39: // right 299 | var nextHref = $('link[rel="next"]').prop('href'); 300 | if (nextHref) { 301 | window.location.href = nextHref; 302 | return false; 303 | } 304 | } 305 | } 306 | }); 307 | } 308 | }; 309 | 310 | // quick alias for translations 311 | _ = Documentation.gettext; 312 | 313 | $(document).ready(function() { 314 | Documentation.init(); 315 | }); 316 | -------------------------------------------------------------------------------- /docs/static/documentation_options.js: -------------------------------------------------------------------------------- 1 | var DOCUMENTATION_OPTIONS = { 2 | URL_ROOT: document.getElementById("documentation_options").getAttribute('data-url_root'), 3 | VERSION: '', 4 | LANGUAGE: 'None', 5 | COLLAPSE_INDEX: false, 6 | FILE_SUFFIX: '.html', 7 | HAS_SOURCE: true, 8 | SOURCELINK_SUFFIX: '.txt', 9 | NAVIGATION_WITH_KEYS: false, 10 | }; -------------------------------------------------------------------------------- /docs/static/down-pressed.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/supertylerc/jncip-dc-notes/6d6b868bd16e1a901dbc0aef90030b17c5398fc5/docs/static/down-pressed.png -------------------------------------------------------------------------------- /docs/static/down.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/supertylerc/jncip-dc-notes/6d6b868bd16e1a901dbc0aef90030b17c5398fc5/docs/static/down.png -------------------------------------------------------------------------------- /docs/static/file.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/supertylerc/jncip-dc-notes/6d6b868bd16e1a901dbc0aef90030b17c5398fc5/docs/static/file.png -------------------------------------------------------------------------------- /docs/static/language_data.js: -------------------------------------------------------------------------------- 1 | /* 2 | * language_data.js 3 | * ~~~~~~~~~~~~~~~~ 4 | * 5 | * This script contains the language-specific data used by searchtools.js, 6 | * namely the list of stopwords, stemmer, scorer and splitter. 7 | * 8 | * :copyright: Copyright 2007-2019 by the Sphinx team, see AUTHORS. 9 | * :license: BSD, see LICENSE for details. 10 | * 11 | */ 12 | 13 | var stopwords = ["a","and","are","as","at","be","but","by","for","if","in","into","is","it","near","no","not","of","on","or","such","that","the","their","then","there","these","they","this","to","was","will","with"]; 14 | 15 | 16 | /* Non-minified version JS is _stemmer.js if file is provided */ 17 | /** 18 | * Porter Stemmer 19 | */ 20 | var Stemmer = function() { 21 | 22 | var step2list = { 23 | ational: 'ate', 24 | tional: 'tion', 25 | enci: 'ence', 26 | anci: 'ance', 27 | izer: 'ize', 28 | bli: 'ble', 29 | alli: 'al', 30 | entli: 'ent', 31 | eli: 'e', 32 | ousli: 'ous', 33 | ization: 'ize', 34 | ation: 'ate', 35 | ator: 'ate', 36 | alism: 'al', 37 | iveness: 'ive', 38 | fulness: 'ful', 39 | ousness: 'ous', 40 | aliti: 'al', 41 | iviti: 'ive', 42 | biliti: 'ble', 43 | logi: 'log' 44 | }; 45 | 46 | var step3list = { 47 | icate: 'ic', 48 | ative: '', 49 | alize: 'al', 50 | iciti: 'ic', 51 | ical: 'ic', 52 | ful: '', 53 | ness: '' 54 | }; 55 | 56 | var c = "[^aeiou]"; // consonant 57 | var v = "[aeiouy]"; // vowel 58 | var C = c + "[^aeiouy]*"; // consonant sequence 59 | var V = v + "[aeiou]*"; // vowel sequence 60 | 61 | var mgr0 = "^(" + C + ")?" + V + C; // [C]VC... is m>0 62 | var meq1 = "^(" + C + ")?" + V + C + "(" + V + ")?$"; // [C]VC[V] is m=1 63 | var mgr1 = "^(" + C + ")?" + V + C + V + C; // [C]VCVC... is m>1 64 | var s_v = "^(" + C + ")?" + v; // vowel in stem 65 | 66 | this.stemWord = function (w) { 67 | var stem; 68 | var suffix; 69 | var firstch; 70 | var origword = w; 71 | 72 | if (w.length < 3) 73 | return w; 74 | 75 | var re; 76 | var re2; 77 | var re3; 78 | var re4; 79 | 80 | firstch = w.substr(0,1); 81 | if (firstch == "y") 82 | w = firstch.toUpperCase() + w.substr(1); 83 | 84 | // Step 1a 85 | re = /^(.+?)(ss|i)es$/; 86 | re2 = /^(.+?)([^s])s$/; 87 | 88 | if (re.test(w)) 89 | w = w.replace(re,"$1$2"); 90 | else if (re2.test(w)) 91 | w = w.replace(re2,"$1$2"); 92 | 93 | // Step 1b 94 | re = /^(.+?)eed$/; 95 | re2 = /^(.+?)(ed|ing)$/; 96 | if (re.test(w)) { 97 | var fp = re.exec(w); 98 | re = new RegExp(mgr0); 99 | if (re.test(fp[1])) { 100 | re = /.$/; 101 | w = w.replace(re,""); 102 | } 103 | } 104 | else if (re2.test(w)) { 105 | var fp = re2.exec(w); 106 | stem = fp[1]; 107 | re2 = new RegExp(s_v); 108 | if (re2.test(stem)) { 109 | w = stem; 110 | re2 = /(at|bl|iz)$/; 111 | re3 = new RegExp("([^aeiouylsz])\\1$"); 112 | re4 = new RegExp("^" + C + v + "[^aeiouwxy]$"); 113 | if (re2.test(w)) 114 | w = w + "e"; 115 | else if (re3.test(w)) { 116 | re = /.$/; 117 | w = w.replace(re,""); 118 | } 119 | else if (re4.test(w)) 120 | w = w + "e"; 121 | } 122 | } 123 | 124 | // Step 1c 125 | re = /^(.+?)y$/; 126 | if (re.test(w)) { 127 | var fp = re.exec(w); 128 | stem = fp[1]; 129 | re = new RegExp(s_v); 130 | if (re.test(stem)) 131 | w = stem + "i"; 132 | } 133 | 134 | // Step 2 135 | re = /^(.+?)(ational|tional|enci|anci|izer|bli|alli|entli|eli|ousli|ization|ation|ator|alism|iveness|fulness|ousness|aliti|iviti|biliti|logi)$/; 136 | if (re.test(w)) { 137 | var fp = re.exec(w); 138 | stem = fp[1]; 139 | suffix = fp[2]; 140 | re = new RegExp(mgr0); 141 | if (re.test(stem)) 142 | w = stem + step2list[suffix]; 143 | } 144 | 145 | // Step 3 146 | re = /^(.+?)(icate|ative|alize|iciti|ical|ful|ness)$/; 147 | if (re.test(w)) { 148 | var fp = re.exec(w); 149 | stem = fp[1]; 150 | suffix = fp[2]; 151 | re = new RegExp(mgr0); 152 | if (re.test(stem)) 153 | w = stem + step3list[suffix]; 154 | } 155 | 156 | // Step 4 157 | re = /^(.+?)(al|ance|ence|er|ic|able|ible|ant|ement|ment|ent|ou|ism|ate|iti|ous|ive|ize)$/; 158 | re2 = /^(.+?)(s|t)(ion)$/; 159 | if (re.test(w)) { 160 | var fp = re.exec(w); 161 | stem = fp[1]; 162 | re = new RegExp(mgr1); 163 | if (re.test(stem)) 164 | w = stem; 165 | } 166 | else if (re2.test(w)) { 167 | var fp = re2.exec(w); 168 | stem = fp[1] + fp[2]; 169 | re2 = new RegExp(mgr1); 170 | if (re2.test(stem)) 171 | w = stem; 172 | } 173 | 174 | // Step 5 175 | re = /^(.+?)e$/; 176 | if (re.test(w)) { 177 | var fp = re.exec(w); 178 | stem = fp[1]; 179 | re = new RegExp(mgr1); 180 | re2 = new RegExp(meq1); 181 | re3 = new RegExp("^" + C + v + "[^aeiouwxy]$"); 182 | if (re.test(stem) || (re2.test(stem) && !(re3.test(stem)))) 183 | w = stem; 184 | } 185 | re = /ll$/; 186 | re2 = new RegExp(mgr1); 187 | if (re.test(w) && re2.test(w)) { 188 | re = /.$/; 189 | w = w.replace(re,""); 190 | } 191 | 192 | // and turn initial Y back to y 193 | if (firstch == "y") 194 | w = firstch.toLowerCase() + w.substr(1); 195 | return w; 196 | } 197 | } 198 | 199 | 200 | 201 | 202 | 203 | var splitChars = (function() { 204 | var result = {}; 205 | var singles = [96, 180, 187, 191, 215, 247, 749, 885, 903, 907, 909, 930, 1014, 1648, 206 | 1748, 1809, 2416, 2473, 2481, 2526, 2601, 2609, 2612, 2615, 2653, 2702, 207 | 2706, 2729, 2737, 2740, 2857, 2865, 2868, 2910, 2928, 2948, 2961, 2971, 208 | 2973, 3085, 3089, 3113, 3124, 3213, 3217, 3241, 3252, 3295, 3341, 3345, 209 | 3369, 3506, 3516, 3633, 3715, 3721, 3736, 3744, 3748, 3750, 3756, 3761, 210 | 3781, 3912, 4239, 4347, 4681, 4695, 4697, 4745, 4785, 4799, 4801, 4823, 211 | 4881, 5760, 5901, 5997, 6313, 7405, 8024, 8026, 8028, 8030, 8117, 8125, 212 | 8133, 8181, 8468, 8485, 8487, 8489, 8494, 8527, 11311, 11359, 11687, 11695, 213 | 11703, 11711, 11719, 11727, 11735, 12448, 12539, 43010, 43014, 43019, 43587, 214 | 43696, 43713, 64286, 64297, 64311, 64317, 64319, 64322, 64325, 65141]; 215 | var i, j, start, end; 216 | for (i = 0; i < singles.length; i++) { 217 | result[singles[i]] = true; 218 | } 219 | var ranges = [[0, 47], [58, 64], [91, 94], [123, 169], [171, 177], [182, 184], [706, 709], 220 | [722, 735], [741, 747], [751, 879], [888, 889], [894, 901], [1154, 1161], 221 | [1318, 1328], [1367, 1368], [1370, 1376], [1416, 1487], [1515, 1519], [1523, 1568], 222 | [1611, 1631], [1642, 1645], [1750, 1764], [1767, 1773], [1789, 1790], [1792, 1807], 223 | [1840, 1868], [1958, 1968], [1970, 1983], [2027, 2035], [2038, 2041], [2043, 2047], 224 | [2070, 2073], [2075, 2083], [2085, 2087], [2089, 2307], [2362, 2364], [2366, 2383], 225 | [2385, 2391], [2402, 2405], [2419, 2424], [2432, 2436], [2445, 2446], [2449, 2450], 226 | [2483, 2485], [2490, 2492], [2494, 2509], [2511, 2523], [2530, 2533], [2546, 2547], 227 | [2554, 2564], [2571, 2574], [2577, 2578], [2618, 2648], [2655, 2661], [2672, 2673], 228 | [2677, 2692], [2746, 2748], [2750, 2767], [2769, 2783], [2786, 2789], [2800, 2820], 229 | [2829, 2830], [2833, 2834], [2874, 2876], [2878, 2907], [2914, 2917], [2930, 2946], 230 | [2955, 2957], [2966, 2968], [2976, 2978], [2981, 2983], [2987, 2989], [3002, 3023], 231 | [3025, 3045], [3059, 3076], [3130, 3132], [3134, 3159], [3162, 3167], [3170, 3173], 232 | [3184, 3191], [3199, 3204], [3258, 3260], [3262, 3293], [3298, 3301], [3312, 3332], 233 | [3386, 3388], [3390, 3423], [3426, 3429], [3446, 3449], [3456, 3460], [3479, 3481], 234 | [3518, 3519], [3527, 3584], [3636, 3647], [3655, 3663], [3674, 3712], [3717, 3718], 235 | [3723, 3724], [3726, 3731], [3752, 3753], [3764, 3772], [3774, 3775], [3783, 3791], 236 | [3802, 3803], [3806, 3839], [3841, 3871], [3892, 3903], [3949, 3975], [3980, 4095], 237 | [4139, 4158], [4170, 4175], [4182, 4185], [4190, 4192], [4194, 4196], [4199, 4205], 238 | [4209, 4212], [4226, 4237], [4250, 4255], [4294, 4303], [4349, 4351], [4686, 4687], 239 | [4702, 4703], [4750, 4751], [4790, 4791], [4806, 4807], [4886, 4887], [4955, 4968], 240 | [4989, 4991], [5008, 5023], [5109, 5120], [5741, 5742], [5787, 5791], [5867, 5869], 241 | [5873, 5887], [5906, 5919], [5938, 5951], [5970, 5983], [6001, 6015], [6068, 6102], 242 | [6104, 6107], [6109, 6111], [6122, 6127], [6138, 6159], [6170, 6175], [6264, 6271], 243 | [6315, 6319], [6390, 6399], [6429, 6469], [6510, 6511], [6517, 6527], [6572, 6592], 244 | [6600, 6607], [6619, 6655], [6679, 6687], [6741, 6783], [6794, 6799], [6810, 6822], 245 | [6824, 6916], [6964, 6980], [6988, 6991], [7002, 7042], [7073, 7085], [7098, 7167], 246 | [7204, 7231], [7242, 7244], [7294, 7400], [7410, 7423], [7616, 7679], [7958, 7959], 247 | [7966, 7967], [8006, 8007], [8014, 8015], [8062, 8063], [8127, 8129], [8141, 8143], 248 | [8148, 8149], [8156, 8159], [8173, 8177], [8189, 8303], [8306, 8307], [8314, 8318], 249 | [8330, 8335], [8341, 8449], [8451, 8454], [8456, 8457], [8470, 8472], [8478, 8483], 250 | [8506, 8507], [8512, 8516], [8522, 8525], [8586, 9311], [9372, 9449], [9472, 10101], 251 | [10132, 11263], [11493, 11498], [11503, 11516], [11518, 11519], [11558, 11567], 252 | [11622, 11630], [11632, 11647], [11671, 11679], [11743, 11822], [11824, 12292], 253 | [12296, 12320], [12330, 12336], [12342, 12343], [12349, 12352], [12439, 12444], 254 | [12544, 12548], [12590, 12592], [12687, 12689], [12694, 12703], [12728, 12783], 255 | [12800, 12831], [12842, 12880], [12896, 12927], [12938, 12976], [12992, 13311], 256 | [19894, 19967], [40908, 40959], [42125, 42191], [42238, 42239], [42509, 42511], 257 | [42540, 42559], [42592, 42593], [42607, 42622], [42648, 42655], [42736, 42774], 258 | [42784, 42785], [42889, 42890], [42893, 43002], [43043, 43055], [43062, 43071], 259 | [43124, 43137], [43188, 43215], [43226, 43249], [43256, 43258], [43260, 43263], 260 | [43302, 43311], [43335, 43359], [43389, 43395], [43443, 43470], [43482, 43519], 261 | [43561, 43583], [43596, 43599], [43610, 43615], [43639, 43641], [43643, 43647], 262 | [43698, 43700], [43703, 43704], [43710, 43711], [43715, 43738], [43742, 43967], 263 | [44003, 44015], [44026, 44031], [55204, 55215], [55239, 55242], [55292, 55295], 264 | [57344, 63743], [64046, 64047], [64110, 64111], [64218, 64255], [64263, 64274], 265 | [64280, 64284], [64434, 64466], [64830, 64847], [64912, 64913], [64968, 65007], 266 | [65020, 65135], [65277, 65295], [65306, 65312], [65339, 65344], [65371, 65381], 267 | [65471, 65473], [65480, 65481], [65488, 65489], [65496, 65497]]; 268 | for (i = 0; i < ranges.length; i++) { 269 | start = ranges[i][0]; 270 | end = ranges[i][1]; 271 | for (j = start; j <= end; j++) { 272 | result[j] = true; 273 | } 274 | } 275 | return result; 276 | })(); 277 | 278 | function splitQuery(query) { 279 | var result = []; 280 | var start = -1; 281 | for (var i = 0; i < query.length; i++) { 282 | if (splitChars[query.charCodeAt(i)]) { 283 | if (start !== -1) { 284 | result.push(query.slice(start, i)); 285 | start = -1; 286 | } 287 | } else if (start === -1) { 288 | start = i; 289 | } 290 | } 291 | if (start !== -1) { 292 | result.push(query.slice(start)); 293 | } 294 | return result; 295 | } 296 | 297 | 298 | -------------------------------------------------------------------------------- /docs/static/minus.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/supertylerc/jncip-dc-notes/6d6b868bd16e1a901dbc0aef90030b17c5398fc5/docs/static/minus.png -------------------------------------------------------------------------------- /docs/static/plus.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/supertylerc/jncip-dc-notes/6d6b868bd16e1a901dbc0aef90030b17c5398fc5/docs/static/plus.png -------------------------------------------------------------------------------- /docs/static/pygments.css: -------------------------------------------------------------------------------- 1 | .highlight .hll { background-color: #ffffcc } 2 | .highlight { background: #f8f8f8; } 3 | .highlight .c { color: #8f5902; font-style: italic } /* Comment */ 4 | .highlight .err { color: #a40000; border: 1px solid #ef2929 } /* Error */ 5 | .highlight .g { color: #000000 } /* Generic */ 6 | .highlight .k { color: #004461; font-weight: bold } /* Keyword */ 7 | .highlight .l { color: #000000 } /* Literal */ 8 | .highlight .n { color: #000000 } /* Name */ 9 | .highlight .o { color: #582800 } /* Operator */ 10 | .highlight .x { color: #000000 } /* Other */ 11 | .highlight .p { color: #000000; font-weight: bold } /* Punctuation */ 12 | .highlight .ch { color: #8f5902; font-style: italic } /* Comment.Hashbang */ 13 | .highlight .cm { color: #8f5902; font-style: italic } /* Comment.Multiline */ 14 | .highlight .cp { color: #8f5902 } /* Comment.Preproc */ 15 | .highlight .cpf { color: #8f5902; font-style: italic } /* Comment.PreprocFile */ 16 | .highlight .c1 { color: #8f5902; font-style: italic } /* Comment.Single */ 17 | .highlight .cs { color: #8f5902; font-style: italic } /* Comment.Special */ 18 | .highlight .gd { color: #a40000 } /* Generic.Deleted */ 19 | .highlight .ge { color: #000000; font-style: italic } /* Generic.Emph */ 20 | .highlight .gr { color: #ef2929 } /* Generic.Error */ 21 | .highlight .gh { color: #000080; font-weight: bold } /* Generic.Heading */ 22 | .highlight .gi { color: #00A000 } /* Generic.Inserted */ 23 | .highlight .go { color: #888888 } /* Generic.Output */ 24 | .highlight .gp { color: #745334 } /* Generic.Prompt */ 25 | .highlight .gs { color: #000000; font-weight: bold } /* Generic.Strong */ 26 | .highlight .gu { color: #800080; font-weight: bold } /* Generic.Subheading */ 27 | .highlight .gt { color: #a40000; font-weight: bold } /* Generic.Traceback */ 28 | .highlight .kc { color: #004461; font-weight: bold } /* Keyword.Constant */ 29 | .highlight .kd { color: #004461; font-weight: bold } /* Keyword.Declaration */ 30 | .highlight .kn { color: #004461; font-weight: bold } /* Keyword.Namespace */ 31 | .highlight .kp { color: #004461; font-weight: bold } /* Keyword.Pseudo */ 32 | .highlight .kr { color: #004461; font-weight: bold } /* Keyword.Reserved */ 33 | .highlight .kt { color: #004461; font-weight: bold } /* Keyword.Type */ 34 | .highlight .ld { color: #000000 } /* Literal.Date */ 35 | .highlight .m { color: #990000 } /* Literal.Number */ 36 | .highlight .s { color: #4e9a06 } /* Literal.String */ 37 | .highlight .na { color: #c4a000 } /* Name.Attribute */ 38 | .highlight .nb { color: #004461 } /* Name.Builtin */ 39 | .highlight .nc { color: #000000 } /* Name.Class */ 40 | .highlight .no { color: #000000 } /* Name.Constant */ 41 | .highlight .nd { color: #888888 } /* Name.Decorator */ 42 | .highlight .ni { color: #ce5c00 } /* Name.Entity */ 43 | .highlight .ne { color: #cc0000; font-weight: bold } /* Name.Exception */ 44 | .highlight .nf { color: #000000 } /* Name.Function */ 45 | .highlight .nl { color: #f57900 } /* Name.Label */ 46 | .highlight .nn { color: #000000 } /* Name.Namespace */ 47 | .highlight .nx { color: #000000 } /* Name.Other */ 48 | .highlight .py { color: #000000 } /* Name.Property */ 49 | .highlight .nt { color: #004461; font-weight: bold } /* Name.Tag */ 50 | .highlight .nv { color: #000000 } /* Name.Variable */ 51 | .highlight .ow { color: #004461; font-weight: bold } /* Operator.Word */ 52 | .highlight .w { color: #f8f8f8; text-decoration: underline } /* Text.Whitespace */ 53 | .highlight .mb { color: #990000 } /* Literal.Number.Bin */ 54 | .highlight .mf { color: #990000 } /* Literal.Number.Float */ 55 | .highlight .mh { color: #990000 } /* Literal.Number.Hex */ 56 | .highlight .mi { color: #990000 } /* Literal.Number.Integer */ 57 | .highlight .mo { color: #990000 } /* Literal.Number.Oct */ 58 | .highlight .sa { color: #4e9a06 } /* Literal.String.Affix */ 59 | .highlight .sb { color: #4e9a06 } /* Literal.String.Backtick */ 60 | .highlight .sc { color: #4e9a06 } /* Literal.String.Char */ 61 | .highlight .dl { color: #4e9a06 } /* Literal.String.Delimiter */ 62 | .highlight .sd { color: #8f5902; font-style: italic } /* Literal.String.Doc */ 63 | .highlight .s2 { color: #4e9a06 } /* Literal.String.Double */ 64 | .highlight .se { color: #4e9a06 } /* Literal.String.Escape */ 65 | .highlight .sh { color: #4e9a06 } /* Literal.String.Heredoc */ 66 | .highlight .si { color: #4e9a06 } /* Literal.String.Interpol */ 67 | .highlight .sx { color: #4e9a06 } /* Literal.String.Other */ 68 | .highlight .sr { color: #4e9a06 } /* Literal.String.Regex */ 69 | .highlight .s1 { color: #4e9a06 } /* Literal.String.Single */ 70 | .highlight .ss { color: #4e9a06 } /* Literal.String.Symbol */ 71 | .highlight .bp { color: #3465a4 } /* Name.Builtin.Pseudo */ 72 | .highlight .fm { color: #000000 } /* Name.Function.Magic */ 73 | .highlight .vc { color: #000000 } /* Name.Variable.Class */ 74 | .highlight .vg { color: #000000 } /* Name.Variable.Global */ 75 | .highlight .vi { color: #000000 } /* Name.Variable.Instance */ 76 | .highlight .vm { color: #000000 } /* Name.Variable.Magic */ 77 | .highlight .il { color: #990000 } /* Literal.Number.Integer.Long */ -------------------------------------------------------------------------------- /docs/static/underscore.js: -------------------------------------------------------------------------------- 1 | // Underscore.js 1.3.1 2 | // (c) 2009-2012 Jeremy Ashkenas, DocumentCloud Inc. 3 | // Underscore is freely distributable under the MIT license. 4 | // Portions of Underscore are inspired or borrowed from Prototype, 5 | // Oliver Steele's Functional, and John Resig's Micro-Templating. 6 | // For all details and documentation: 7 | // http://documentcloud.github.com/underscore 8 | (function(){function q(a,c,d){if(a===c)return a!==0||1/a==1/c;if(a==null||c==null)return a===c;if(a._chain)a=a._wrapped;if(c._chain)c=c._wrapped;if(a.isEqual&&b.isFunction(a.isEqual))return a.isEqual(c);if(c.isEqual&&b.isFunction(c.isEqual))return c.isEqual(a);var e=l.call(a);if(e!=l.call(c))return false;switch(e){case "[object String]":return a==String(c);case "[object Number]":return a!=+a?c!=+c:a==0?1/a==1/c:a==+c;case "[object Date]":case "[object Boolean]":return+a==+c;case "[object RegExp]":return a.source== 9 | c.source&&a.global==c.global&&a.multiline==c.multiline&&a.ignoreCase==c.ignoreCase}if(typeof a!="object"||typeof c!="object")return false;for(var f=d.length;f--;)if(d[f]==a)return true;d.push(a);var f=0,g=true;if(e=="[object Array]"){if(f=a.length,g=f==c.length)for(;f--;)if(!(g=f in a==f in c&&q(a[f],c[f],d)))break}else{if("constructor"in a!="constructor"in c||a.constructor!=c.constructor)return false;for(var h in a)if(b.has(a,h)&&(f++,!(g=b.has(c,h)&&q(a[h],c[h],d))))break;if(g){for(h in c)if(b.has(c, 10 | h)&&!f--)break;g=!f}}d.pop();return g}var r=this,G=r._,n={},k=Array.prototype,o=Object.prototype,i=k.slice,H=k.unshift,l=o.toString,I=o.hasOwnProperty,w=k.forEach,x=k.map,y=k.reduce,z=k.reduceRight,A=k.filter,B=k.every,C=k.some,p=k.indexOf,D=k.lastIndexOf,o=Array.isArray,J=Object.keys,s=Function.prototype.bind,b=function(a){return new m(a)};if(typeof exports!=="undefined"){if(typeof module!=="undefined"&&module.exports)exports=module.exports=b;exports._=b}else r._=b;b.VERSION="1.3.1";var j=b.each= 11 | b.forEach=function(a,c,d){if(a!=null)if(w&&a.forEach===w)a.forEach(c,d);else if(a.length===+a.length)for(var e=0,f=a.length;e2;a== 12 | null&&(a=[]);if(y&&a.reduce===y)return e&&(c=b.bind(c,e)),f?a.reduce(c,d):a.reduce(c);j(a,function(a,b,i){f?d=c.call(e,d,a,b,i):(d=a,f=true)});if(!f)throw new TypeError("Reduce of empty array with no initial value");return d};b.reduceRight=b.foldr=function(a,c,d,e){var f=arguments.length>2;a==null&&(a=[]);if(z&&a.reduceRight===z)return e&&(c=b.bind(c,e)),f?a.reduceRight(c,d):a.reduceRight(c);var g=b.toArray(a).reverse();e&&!f&&(c=b.bind(c,e));return f?b.reduce(g,c,d,e):b.reduce(g,c)};b.find=b.detect= 13 | function(a,c,b){var e;E(a,function(a,g,h){if(c.call(b,a,g,h))return e=a,true});return e};b.filter=b.select=function(a,c,b){var e=[];if(a==null)return e;if(A&&a.filter===A)return a.filter(c,b);j(a,function(a,g,h){c.call(b,a,g,h)&&(e[e.length]=a)});return e};b.reject=function(a,c,b){var e=[];if(a==null)return e;j(a,function(a,g,h){c.call(b,a,g,h)||(e[e.length]=a)});return e};b.every=b.all=function(a,c,b){var e=true;if(a==null)return e;if(B&&a.every===B)return a.every(c,b);j(a,function(a,g,h){if(!(e= 14 | e&&c.call(b,a,g,h)))return n});return e};var E=b.some=b.any=function(a,c,d){c||(c=b.identity);var e=false;if(a==null)return e;if(C&&a.some===C)return a.some(c,d);j(a,function(a,b,h){if(e||(e=c.call(d,a,b,h)))return n});return!!e};b.include=b.contains=function(a,c){var b=false;if(a==null)return b;return p&&a.indexOf===p?a.indexOf(c)!=-1:b=E(a,function(a){return a===c})};b.invoke=function(a,c){var d=i.call(arguments,2);return b.map(a,function(a){return(b.isFunction(c)?c||a:a[c]).apply(a,d)})};b.pluck= 15 | function(a,c){return b.map(a,function(a){return a[c]})};b.max=function(a,c,d){if(!c&&b.isArray(a))return Math.max.apply(Math,a);if(!c&&b.isEmpty(a))return-Infinity;var e={computed:-Infinity};j(a,function(a,b,h){b=c?c.call(d,a,b,h):a;b>=e.computed&&(e={value:a,computed:b})});return e.value};b.min=function(a,c,d){if(!c&&b.isArray(a))return Math.min.apply(Math,a);if(!c&&b.isEmpty(a))return Infinity;var e={computed:Infinity};j(a,function(a,b,h){b=c?c.call(d,a,b,h):a;bd?1:0}),"value")};b.groupBy=function(a,c){var d={},e=b.isFunction(c)?c:function(a){return a[c]};j(a,function(a,b){var c=e(a,b);(d[c]||(d[c]=[])).push(a)});return d};b.sortedIndex=function(a, 17 | c,d){d||(d=b.identity);for(var e=0,f=a.length;e>1;d(a[g])=0})})};b.difference=function(a){var c=b.flatten(i.call(arguments,1));return b.filter(a,function(a){return!b.include(c,a)})};b.zip=function(){for(var a=i.call(arguments),c=b.max(b.pluck(a,"length")),d=Array(c),e=0;e=0;d--)b=[a[d].apply(this,b)];return b[0]}}; 24 | b.after=function(a,b){return a<=0?b():function(){if(--a<1)return b.apply(this,arguments)}};b.keys=J||function(a){if(a!==Object(a))throw new TypeError("Invalid object");var c=[],d;for(d in a)b.has(a,d)&&(c[c.length]=d);return c};b.values=function(a){return b.map(a,b.identity)};b.functions=b.methods=function(a){var c=[],d;for(d in a)b.isFunction(a[d])&&c.push(d);return c.sort()};b.extend=function(a){j(i.call(arguments,1),function(b){for(var d in b)a[d]=b[d]});return a};b.defaults=function(a){j(i.call(arguments, 25 | 1),function(b){for(var d in b)a[d]==null&&(a[d]=b[d])});return a};b.clone=function(a){return!b.isObject(a)?a:b.isArray(a)?a.slice():b.extend({},a)};b.tap=function(a,b){b(a);return a};b.isEqual=function(a,b){return q(a,b,[])};b.isEmpty=function(a){if(b.isArray(a)||b.isString(a))return a.length===0;for(var c in a)if(b.has(a,c))return false;return true};b.isElement=function(a){return!!(a&&a.nodeType==1)};b.isArray=o||function(a){return l.call(a)=="[object Array]"};b.isObject=function(a){return a===Object(a)}; 26 | b.isArguments=function(a){return l.call(a)=="[object Arguments]"};if(!b.isArguments(arguments))b.isArguments=function(a){return!(!a||!b.has(a,"callee"))};b.isFunction=function(a){return l.call(a)=="[object Function]"};b.isString=function(a){return l.call(a)=="[object String]"};b.isNumber=function(a){return l.call(a)=="[object Number]"};b.isNaN=function(a){return a!==a};b.isBoolean=function(a){return a===true||a===false||l.call(a)=="[object Boolean]"};b.isDate=function(a){return l.call(a)=="[object Date]"}; 27 | b.isRegExp=function(a){return l.call(a)=="[object RegExp]"};b.isNull=function(a){return a===null};b.isUndefined=function(a){return a===void 0};b.has=function(a,b){return I.call(a,b)};b.noConflict=function(){r._=G;return this};b.identity=function(a){return a};b.times=function(a,b,d){for(var e=0;e/g,">").replace(/"/g,""").replace(/'/g,"'").replace(/\//g,"/")};b.mixin=function(a){j(b.functions(a), 28 | function(c){K(c,b[c]=a[c])})};var L=0;b.uniqueId=function(a){var b=L++;return a?a+b:b};b.templateSettings={evaluate:/<%([\s\S]+?)%>/g,interpolate:/<%=([\s\S]+?)%>/g,escape:/<%-([\s\S]+?)%>/g};var t=/.^/,u=function(a){return a.replace(/\\\\/g,"\\").replace(/\\'/g,"'")};b.template=function(a,c){var d=b.templateSettings,d="var __p=[],print=function(){__p.push.apply(__p,arguments);};with(obj||{}){__p.push('"+a.replace(/\\/g,"\\\\").replace(/'/g,"\\'").replace(d.escape||t,function(a,b){return"',_.escape("+ 29 | u(b)+"),'"}).replace(d.interpolate||t,function(a,b){return"',"+u(b)+",'"}).replace(d.evaluate||t,function(a,b){return"');"+u(b).replace(/[\r\n\t]/g," ")+";__p.push('"}).replace(/\r/g,"\\r").replace(/\n/g,"\\n").replace(/\t/g,"\\t")+"');}return __p.join('');",e=new Function("obj","_",d);return c?e(c,b):function(a){return e.call(this,a,b)}};b.chain=function(a){return b(a).chain()};var m=function(a){this._wrapped=a};b.prototype=m.prototype;var v=function(a,c){return c?b(a).chain():a},K=function(a,c){m.prototype[a]= 30 | function(){var a=i.call(arguments);H.call(a,this._wrapped);return v(c.apply(b,a),this._chain)}};b.mixin(b);j("pop,push,reverse,shift,sort,splice,unshift".split(","),function(a){var b=k[a];m.prototype[a]=function(){var d=this._wrapped;b.apply(d,arguments);var e=d.length;(a=="shift"||a=="splice")&&e===0&&delete d[0];return v(d,this._chain)}});j(["concat","join","slice"],function(a){var b=k[a];m.prototype[a]=function(){return v(b.apply(this._wrapped,arguments),this._chain)}});m.prototype.chain=function(){this._chain= 31 | true;return this};m.prototype.value=function(){return this._wrapped}}).call(this); 32 | -------------------------------------------------------------------------------- /docs/static/up-pressed.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/supertylerc/jncip-dc-notes/6d6b868bd16e1a901dbc0aef90030b17c5398fc5/docs/static/up-pressed.png -------------------------------------------------------------------------------- /docs/static/up.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/supertylerc/jncip-dc-notes/6d6b868bd16e1a901dbc0aef90030b17c5398fc5/docs/static/up.png -------------------------------------------------------------------------------- /docs/vxlan-evpn.html: -------------------------------------------------------------------------------- 1 | 2 | 4 | 5 | 6 | 7 | 8 | 9 | EVPN VXLAN Signaling — jncip-dc-notes documentation 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 |
31 |
32 |
33 | 34 | 35 |
36 | 37 |
38 |

EVPN VXLAN Signaling

39 |

Coming soon!

40 |
41 | 42 | 43 |
44 | 45 |
46 |
47 | 103 |
104 |
105 |
106 | ©2019, Tyler Christiansen. 107 | 108 | | 109 | Powered by Sphinx 1.8.5 110 | & Alabaster 0.7.12 111 | 112 | | 113 | Page source 115 |
116 | 117 | 118 | 119 | 120 | 121 | -------------------------------------------------------------------------------- /index.rst: -------------------------------------------------------------------------------- 1 | .. jncip-dc-notes documentation master file, created by 2 | sphinx-quickstart on Thu May 16 17:05:25 2019. 3 | You can adapt this file completely to your liking, but it should at least 4 | contain the root `toctree` directive. 5 | 6 | JNCIP-DC Study Notes 7 | ==================== 8 | 9 | Welcome to `Tyler Christiansen `_'s 10 | notes for the 11 | `JNCIP-DC `_ 12 | exam. These notes are open source. I would love to see additional 13 | collaboration and contribution from others who are either pursuing the 14 | exam or who are far more knowledgeable than myself. If you're 15 | interested in contributing, please see the :ref:`contributing` section 16 | below. 17 | 18 | These notes have been taken and organized in the order of the listed 19 | `JNCIP-DC `_ 20 | exam objectives. The primary reference has been the 21 | `QFX5100 Series `_ 22 | book, but other references such as the 23 | `MX Series `_ 24 | book and official Juniper documentation have been used. I've tried to 25 | remember to credit any sources I've had while taking notes, but I'm sure 26 | I've left sources off. If you're aware of a particular source for 27 | something, please let me know so that I can attribute credit. 28 | 29 | .. note:: 30 | Links to Amazon may be present. They are *not* affiliate links. I 31 | do not make any money if you follow them. I do not make any money 32 | for any link you follow on this site. There is no monetization 33 | whatsoever here. I'm only interested in publishing my JNCIP-DC notes 34 | as open source. 35 | 36 | These are my personal notes -- they're not guaranteed to be accurate or 37 | representative of the exam in any way, shape, or form. If you find 38 | something that is incorrect, please let me know via e-mail or GitHub. 39 | You can even submit a pull request to correct the error! 40 | 41 | .. _contributing: 42 | 43 | Contributing 44 | ------------ 45 | 46 | I'll take contributions however I can get them, but here are a few areas 47 | in which I'm particularly interested: 48 | 49 | * Diagrams: I'm really terrible at making diagrams. I actually tried to 50 | to make a few for this project, but I became far too frustrated with 51 | the tools available to me (I don't have Visio). If you can contribute 52 | diagrams, it would be incredibly helpful. 53 | * Technical Corrections: These are my notes for an exam; I'm not an 54 | authority on the technologies, and I could definitely be wrong. I 55 | don't have a technical reviewer. If you find technical errors, please 56 | let me know either via e-mail, a GitHub issue, or a pull request to 57 | correct the issue. All I ask is that for any technical correction, a 58 | source to the correct information be provided. 59 | * Grammatical Correction: This may seem odd, but if there's a grammar 60 | issue, I'd appreciate a correction. 61 | * Labs and Configurations: More labs and configuration examples are 62 | always better! I'm trying to provide examples, but it's sometimes 63 | difficult to capture. In some cases, I can't provide any labs or 64 | configuration snippets because it requires physical gear (such as 65 | Virtual Chassis) and I only have access to vQFX10k. So if you can 66 | contribute labs or configuration snippets, they would be greatly 67 | appreciated! 68 | 69 | If you have any other contribution to make, it's 100% welcome. The best 70 | place to contribute and collaborate is the 71 | `GitHub repository `_. 72 | Issues can be reported, and if you're familiar with GitHub and/or 73 | ReStructured Text (the markup language in which these notes are 74 | written), you can submit pull requests to contribute. 75 | 76 | All contributions will be added to the :ref:`contributors` page unless 77 | the contributor requests otherwise. 78 | 79 | .. toctree:: 80 | :maxdepth: 5 81 | :caption: Contents: 82 | 83 | dc-deployment-and-management 84 | mc-lag 85 | layer-2-fabrics 86 | layer-3-fabrics 87 | vxlan 88 | vxlan-evpn 89 | lab-objectives 90 | additional-resources 91 | contributors 92 | 93 | * :ref:`search` 94 | -------------------------------------------------------------------------------- /lab-objectives.rst: -------------------------------------------------------------------------------- 1 | Technology-Oriented Labs 2 | ======================== 3 | 4 | TODO: Flesh this out more. A lot more. 5 | 6 | Right now, this page is a sort of scratch pad on things that are likely 7 | to be on the exam. It's lab-oriented, with some specific implementation 8 | details. 9 | 10 | Lab 1 (Multicast and CRB with QFX) 11 | ---------------------------------- 12 | 13 | This lab should focus on multicast for BUM replication and VTEP 14 | discovery. It should implement VxLAN routing at the spine layer. The 15 | spines should be QFX10k Series devices. 16 | 17 | Lab 2 (Multicast and CRB with MX) 18 | --------------------------------- 19 | 20 | This lab should focus on multicast for BUM replication and VTEP 21 | discovery. It should implement VxLAN routing at the spine layer. The 22 | spines should be MX Series devices. 23 | 24 | Lab 3 (Multicast and ERB) 25 | ------------------------- 26 | 27 | This lab should focus on multicast for BUM replication and VTEP 28 | discovery. It should implement VxLAN routing at the leaf layer. Use 29 | either the QFX10k or QFX5110 Series for the leaf layer. 30 | 31 | Lab 4 (EVPN and CRB with QFX) 32 | ----------------------------- 33 | 34 | This lab should focus on BGP EVPN and ingress replication for VTEP 35 | discovery. It should implement VxLAN routing at the spine layer. The 36 | spines should be QFX10k Series devices. 37 | 38 | Lab 5 (EVPN and CRB with MX) 39 | ---------------------------- 40 | 41 | This lab should focus on BGP EVPN and ingress replication for VTEP 42 | discovery. It should implement VxLAN routing at the spine layer. The 43 | spines should be MX Series devices. 44 | 45 | Lab 6 (EVPN and ERB) 46 | -------------------- 47 | 48 | This lab should focus on BGP EVPN and ingress replication for VTEP 49 | discovery. It should implement VxLAN routing at the leaf layer. Use 50 | either the QFX10k or QFX5110 Series for the leaf layer. 51 | 52 | Lab 7 (EVPN Multihoming with QFX) 53 | --------------------------------- 54 | 55 | This lab should focus on EVPN using a QFX at the leaf layer. Use any of 56 | labs 3 through 6 as the base topology and add EVPN Multihoming at the 57 | leaf layer with a QFX Series device. 58 | 59 | Lab 8 (EVPN Multihoming with MX) 60 | --------------------------------- 61 | 62 | This lab should focus on EVPN using an MX at the leaf layer. Use any of 63 | labs 3 through 6 as the base topology and add EVPN Multihoming at the 64 | leaf layer with an MX Series device. 65 | 66 | Lab 9 (DCI with MX Series EVPN Stitching) 67 | ----------------------------------------- 68 | 69 | Implement a DCI solution with lab 7 or 8 as a starting point and MX 70 | Series devices as WAN routers. They should stitch a VxLAN EVPN to an 71 | MPLS EVPN solution. 72 | 73 | Lab 10 (DCI with MX Series L3VPN) 74 | --------------------------------- 75 | 76 | Implement a DCI solution with lab7 or 8 as a starting point and MX 77 | Series devices as WAN routers. The VxLAN EVPN solution should simply 78 | ride over a normal MPLS L3VPN. 79 | 80 | Lab 11 (DCI with VxLAN EVPN and MX) 81 | ----------------------------------- 82 | 83 | Implement a DCI solution with lab7 or 8 as a starting point and MX 84 | Series devices as spines. The solution should be implemented using only 85 | VxLAN BGP EVPN. 86 | 87 | Lab 12 (DCI with VxLAN EVPN and QFX) 88 | ------------------------------------ 89 | 90 | Implement a DCI solution with lab7 or 8 as a starting point and QFX10k 91 | Series devices as spines. The solution should be implemented using only 92 | VxLAN BGP EVPN. 93 | -------------------------------------------------------------------------------- /layer-2-fabrics.rst: -------------------------------------------------------------------------------- 1 | Layer 2 Fabrics 2 | =============== 3 | 4 | This blueprint item primarily covers the following topics: 5 | 6 | * :ref:`vc` 7 | * :ref:`vcf` 8 | 9 | .. note:: 10 | Both :ref:`vc` and :ref:`vcf` are hardware-based architectures. 11 | Unfortunately, I do not have access to real hardware; all of my 12 | labbing is based on the vQFX0000. This means that although there 13 | may be configurations presented, I don't currently have a way of 14 | validating. If you have access to physical gear and can validate 15 | the configurations (or present more interesting 16 | topologies/configurations), I would love to see them contributed! 17 | 18 | 19 | .. _vc: 20 | 21 | Virtual Chassis 22 | --------------- 23 | 24 | The EX4300, QFX3500, QFX3600, and QFX5100 can form a mixed mode Virtual 25 | Chassis. If you are familiar with mixed mode Virtual Chassis from the 26 | Enterprise track (EX4200/EX4500/EX4550), the concept is very similar. 27 | Up to 10 switches are supported in a stack, although some switches, such 28 | as the QFX5100-96S, may not be supported. 29 | 30 | The first step in creating a mixed mode Virtual Chassis is to tell each 31 | individual switch that it will be participating in a mixed mode VC with 32 | the ``request virtual-chassis mode mixed reboot`` command. However, 33 | when building a new stack, the 34 | ``request virtual-chassis mode mixed all-members reboot`` command can be 35 | used to set all members in the stack to mixed mode at the same time. 36 | 37 | .. note:: 38 | When operating in a mixed mode Virtual Chassis, the scaling numbers 39 | are reduced to the lowest common denominator. This severely limits 40 | the scalability of a deployment. The lowest common denominator is 41 | the lowest scaling factor of the smallest possible PFE. This means 42 | that if you have a mixed Virtual Chassis of QFX3500 and QFX5100, even 43 | if there is no EX4300, each device will still be limited to the 44 | maximum scale of an EX4300. 45 | 46 | The benefits of a mixed mode Virtual Chassis are the same as those of a 47 | regular Virtual Chassis: 48 | 49 | * Redundant Routing Engines 50 | * NSR and NSB 51 | * One control plane for multiple data planes 52 | * Potential elimination of xSTP 53 | 54 | By default, the 40G QSFP+ ports on an EX4300 are enabled for Virtual 55 | Chassis; however, on the QFX5100, these ports are disabled for Virtual 56 | Chassis. When a mixed mode VC contains QFX5100 switches, only the 57 | QFX5100 can become an RE. As with many protocols consisting of primary 58 | and secondary nodes, the VC mastership process follows an election 59 | process. The first tie-breaker is priority, which is 128 by default. 60 | Higher is better. If the priority values are the same, the next factor 61 | to consider is which node was the master prior to a reboot. Next, the 62 | member with the highest uptime; however, the difference in uptime must 63 | be more than 60 seconds. Finally, all else being equal (and difference 64 | in uptime being less than 60 seconds), the member with the *lowest* MAC 65 | address will be elected as the master. The backup is elected according 66 | to the same criteria. 67 | 68 | When implementing Virtual Chassis, you can use the 69 | ``virtual-chassis auto-sw-upgrade`` configuration to automatically 70 | upgrade members with the ``LC (Line Card)`` state when their software 71 | version does not match that of the Master RE. Additionally, Split 72 | Detection can be disabled with the 73 | ``virtual-chassis no-split-detection`` configurtation. However, this 74 | should only be done when there are only two members in the Virtual 75 | Chassis. 76 | 77 | On a QFX5100, you will need to set ports as Virtual Chassis Ports with 78 | the ``request virtual-chassis vc-port set pic-slot 0 port 48`` 79 | operational command. 80 | 81 | Virtual Chassis supports a special deviation of ISSU called NSSU: 82 | Non-Stop Software Upgrade. For NSSU to work, the physical topology must 83 | be a ring -- it cannot be a braid. The master and backup must be 84 | adjacent; this means that the roles of each switch must be 85 | deterministic. For this reason, only pre-provisioned Virtual Chassis is 86 | supported. Additionally, both NSR and GRES must be configured; NSB is 87 | optional. To initiate an NSSU, issue the 88 | ``request system software nonstop-upgrade [ ]`` 89 | command. 90 | 91 | .. _vcf: 92 | 93 | Virtual Chassis Fabric 94 | ---------------------- 95 | 96 | Virtual Chassis Fabric is an extension of Virtual Chassis. It works 97 | with QFX3500, QFX3600, QFX5100, and EX4300 series switches. 98 | New switches added to a VCF are automatically discovered and brought 99 | online. 100 | 101 | .. note:: 102 | The node limit is unclear. In Chapter 5 of the O'Reilly QFX5100 103 | Series book [#f1]_, a passage indicates that the maximum number of 104 | switches is 32; however, recent Juniper documentation publications 105 | [#f2]_ indicate that the limit is 20. Because the documentation is 106 | more recent than the published book, even though there is no 107 | confirmed and published errata [#f3]_, readers should assume a limit 108 | of 20 nodes. 109 | 110 | Like :ref:`vc`, VCF uses IS-IS between switches. The links between 111 | switches, however, come up as "Smart Trunks." This is part of what 112 | enables VCF to perform unequal cost multipath load balancing in certain 113 | designs and failure scenarios. The other technology that enables 114 | unueqal cost multipath is Adaptive Load Balancing. ALB hashes TCP 115 | flowlets to different links. 116 | 117 | These flowlets are tracked in a hash bucket table. This table can hold 118 | hundreds of thousands of entries -- enough to prevent "elephant flows" 119 | from overloading a given link. When the flowlet egresses the switch, 120 | the hash table is updated with a timestamp and the link via which it 121 | egressed. When a new packet for the same flowlet egresses, it is 122 | checked against an expiration or inactivity timer. If the time since 123 | the last packet was seen is greater than the inactivity timer, then the 124 | flowlet is hashed to a new uplink. The egress link selection is also 125 | based on a moving average of the load and queue depth on each interface. 126 | 127 | ALB is disabled by default; to enable it in a VCF, use the 128 | ``set fabric-load-balance flowlet`` configuration command. 129 | 130 | Not all switches can be spine switches, but all switches can be leaf 131 | switches. A general rule of thumb is that a fiber-based QFX5100 can be 132 | a leaf switch or a spine switch; any other switch can only be a leaf 133 | switch. 134 | 135 | Provisioning Options 136 | ^^^^^^^^^^^^^^^^^^^^ 137 | 138 | When configuring a VCF, you have three options: auto-provisioned, 139 | pre-provisioned, and non-provisioned. Each has its own benefits and 140 | drawbacks; auto-provisioned is less secure, while the non-provisioned 141 | mode is more configuration-intensive and less predictable. 142 | 143 | With an auto-provisioned VCF, you must specify the role and serial 144 | number for each spine switch; the leaf switches are automatically added. 145 | The Virtual Chassis Ports are automatically discovered and added. 146 | 147 | With a pre-provisioned VCF, you specify each spine *and* leaf member. 148 | Virtual Chassis Ports are also automatically discovered and added. 149 | Configuring a VCF in this mode is the same as configuring a :ref:`vc` 150 | in pre-provisioned mode. 151 | 152 | .. note:: 153 | If you do not want links between switches to be converted to VCPs 154 | automatically, delete the LLDP configuration before powering on 155 | additional switches. 156 | 157 | .. note:: 158 | If you're using a mixed mode :ref:`vcf`, you need to disable the 159 | VCPs on any EX4300 switch in order for the VCPs to autonegotiate 160 | successfully. Converting VCPs to network interfaces is covered 161 | in the :ref:`data-plane` section. 162 | 163 | The non-provisioned mode is similar to the pre-provisioned mode, except 164 | that the Virtual Chassis Ports are not automatically discovered and 165 | added, and the roles are not automatically defined; instead, a 166 | priority-based election process occurs. 167 | 168 | To create a VCF, you need to set the master RE switch into the VCF mode 169 | with ``request virtual-chassis mode fabric reboot``. At least one leaf 170 | switch needs to be installed next, and it should be cabled to the second 171 | spine switch before bringing up the second spine switch. 172 | 173 | .. note:: 174 | If you need a Mixed Mode :ref:`vcf`, such as when building a fabric 175 | with the QFX5100 and EX4300, you need to use the 176 | ``request virtual-chassis mode fabric mixed reboot`` operational 177 | command. When operating a mixed mode :ref:`vcf`, you can set the 178 | master's mode to ``mixed``, then add all members, and then set all 179 | switches to ``mixed`` mode at the same time with the operational 180 | ``request virtual-chassis mode fabric mixed all-members reboot`` 181 | command. 182 | 183 | Mastership Election 184 | ^^^^^^^^^^^^^^^^^^^ 185 | 186 | In auto-provisioned and pre-provisioned, modes, the QFX5100 that has the 187 | highest uptime is elected the master. The QFX5100 with the 188 | second-highest uptime is elected the backup. Any other QFX5100s in the 189 | spine role are line cards. If one of the masters fails, then one of the 190 | QFX5100 spines operating as a line card will be elected the new backup 191 | following the same uptime rules. 192 | 193 | For a non-provisioned VCF, the following rules dictate master selection: 194 | 195 | 1: Highest priority (default is 128) 196 | 2: QFX5100 operating as master prior to reboot 197 | 3: QFX5100 with longest uptime (greater than one minute) 198 | 4: QFX5100 with lowest MAC address 199 | 200 | For the backup RE, the process is repeated. 201 | 202 | .. note:: 203 | You might notice that this the same mastership election process as 204 | for :ref:`vc`. 205 | 206 | Control Plane 207 | ^^^^^^^^^^^^^ 208 | 209 | ``vccpd`` runs on all nodes and is based on IS-IS. It is responsible 210 | for topology discovery. It also distributes any VCCP-specific state 211 | information. For unicast traffic, shortest path first is used; however, 212 | to support BUM traffic, bidirection multicast trees are used. Finally, 213 | for control plane traffic, a unique Class of Service queue is 214 | automatically created and used. All of this operational complexity is 215 | abstracted by :ref:`vcf`. 216 | 217 | When deploying a VCF, GRES, NSR, and NSB are used to keep the master and 218 | backup REs in sync. 219 | 220 | For console access, each switch runs a virtual console server. When you 221 | attach to the console of any member switch, this virtual console server 222 | software automatically redirects your connection to the master RE. Once 223 | you're on the master RE, you can access a specific node with the 224 | ``request session member `` command. 225 | 226 | As with :ref:`vc`, the OOB management interface becomes a ``vme`` 227 | interface. 228 | 229 | When a switch is removed, its member ID does not get released 230 | automatically. If you want to release the member ID to be used by the 231 | next switch attached, you can use the 232 | ``request virtual-chassis recycle member-id `` operational cmmand. 233 | 234 | When adding a new switch, the software versions must be compatible. You 235 | can either upgrade the devices manually, or you can use the 236 | ``auto-sw-upgrade`` configuration. When using this, you must have the 237 | images for each series (EX4300, QFX3500, QFX5100) in your fabric on the 238 | master RE or a remote URL. Use the 239 | ``set virtual-chassis auto-sw-upgrade ex-4300 `` configuration 240 | command to set the path for an EX4300. Replace ``ex-4300`` with 241 | ``qfx-3`` or ``qfx-5`` for the QFX3500 or QFX5100, respectively. 242 | 243 | When performing a software upgrade, the Non-Stop Software Upgrade (NSSU) 244 | feature can be used if using the ``preprovisioned`` mode. Additionally, 245 | ``no-split-detection`` (covered in the :ref:`fabric-partition` section) 246 | must be configured. 247 | 248 | .. _data-plane: 249 | 250 | Data Plane 251 | ^^^^^^^^^^ 252 | 253 | :ref:`vcf` has a concept of "Smart Trunks." When two or more links 254 | between two devices are connected, they will automatically form a LAG. 255 | Each path is weighted based on the bandwidth ratio. Traffic is 256 | distributed across multiple unequal paths, taking into account the 257 | minimum possible bandwidth on any links in the path. 258 | 259 | A 16 byte Fabric Header is added to each packet received or sent by an 260 | ingress or egress device, similar to MPLS. It contains the incoming 261 | member ID, incoming port ID, destination member ID, and destination port 262 | ID, among other fields. 263 | 264 | For load balancing hashing, the following fields are used: 265 | 266 | Layer 2+Fabric Header: 267 | 268 | * Source MAC 269 | * Destination MAC 270 | * Ethertype 271 | * VLAN ID 272 | * Incoming Port ID 273 | * Incoming Member ID 274 | 275 | Layer 3+4: 276 | 277 | * Source IP 278 | * Destination IP 279 | * Source Port 280 | * Destination Port 281 | * Protocol 282 | * Incoming Port ID 283 | * Incoming Member ID 284 | * Next Header (IPv6 Only) 285 | 286 | If you need to convert an interface to a VCP, the 287 | ``request virtual-chassis vc-port set pic-slot port member `` 288 | command can be used. The ``member `` corresponds to the FPC number 289 | in the interface's representation. To do the opposite, replace ``set`` 290 | with ``delete``. For example, 291 | ``request virtual-chassis vc-port delete pic-slot 0 port 1 member 7``. 292 | 293 | Finally, MAC learning is similar to a :ref:`vc`: when a member learns a 294 | new MAC address, it notifies the master of the MAC address. The master 295 | then programs all other members with the MAC-to-interface entry. 296 | 297 | BUM Traffic 298 | ^^^^^^^^^^^ 299 | 300 | BUM traffic is distributed according to a Multicast Distribution Tree 301 | (MDT). There are multiple trees in a :ref:`vcf`, each rooted at each 302 | switch. Therefore, there are ``N`` MDTs, where ``N`` is the number of 303 | switches in the :ref:`vcf`. Each switch can load balance across all of 304 | the available MDTs for sending BUM traffic. This traffic is hashed 305 | based on the VLAN ID. 306 | 307 | .. note:: 308 | In a :ref:`vcf`, all members receive a copy of all BUM traffic. 309 | 310 | .. _fabric-partition: 311 | 312 | Fabric Partition 313 | ^^^^^^^^^^^^^^^^ 314 | 315 | Sometimes, a fabric may become partitioned or "split." This occurs when 316 | one or more switches become isolated from one or more other switches in 317 | the fabric. When this happens, one of the new fabrics will remain 318 | active, and the others will be deactivated. 319 | 320 | .. note:: 321 | "Isolated" refers to communications via the Virtual Chassis Ports. 322 | Even if IP connectivity would otherwise exist, the fabric is 323 | considered partitioned if it cannot communicate over the VCPs. 324 | 325 | To determine which fabric will remain active, the following rules are 326 | evaluated, in order: 327 | 328 | 1: The fabric contains both the master and the backup RE from the 329 | previous fabric 330 | 2: The fabric contains the original master RE and at least half of the 331 | members from the previous fabric 332 | 2: The fabric contains the backup master RE and at least half of the 333 | members from the previous fabric 334 | 335 | If your design can function when a partition happens, you can disable 336 | the default behavior with the ``set virtual-chassis no-split-detection`` 337 | configuration command. This disables the deactivation of partitioned 338 | fabrics described above. 339 | 340 | .. rubric:: Footnotes 341 | 342 | .. [#f1] `Juniper QFX5100 Series `_ 343 | .. [#f2] `Planning a Virtual Chassis Fabric Deployment `_ 344 | .. [#f3] `Errata for Juniper QFX5100 Series `_ 345 | -------------------------------------------------------------------------------- /layer-3-fabrics.rst: -------------------------------------------------------------------------------- 1 | .. _layer-3-fabrics: 2 | 3 | Layer 3 Fabrics 4 | =============== 5 | 6 | This blueprint item primarily covers the following topics: 7 | 8 | * :ref:`clos` 9 | * :ref:`ip-fabric-routing` 10 | * :ref:`ip-fabric-scaling` 11 | * :ref:`best-practices` 12 | 13 | .. _clos: 14 | 15 | 3-Stage Clos Architecture 16 | ------------------------- 17 | 18 | A Clos network was originally a circuit switching architecture for the 19 | PSTN. It provided for connecting one input to one output with no 20 | blocking. In other words, connectivity was always possible. This was 21 | because of the intermediate switches that connected ingress and egress 22 | switches. 23 | 24 | In IP networking, this concept has been applied in the "spine-leaf" 25 | architecture. In this design, a number of interconnecting transport 26 | switches (spines) connect to ingress and egress switches (leafs). They 27 | provide multiple paths for communications and can be designed in a way 28 | that is "non-blocking" if zero oversubscription is desired. These 29 | fabrics make better use of their links. They are classified as 30 | ``n-stage``, where ``n`` is (more or less) the number of network devices 31 | a packet will traverse when ingressing and egressing from any point in 32 | the fabric to any point in the fabric. A 3-stage architecture consists 33 | of three network devices from point A to point Z: the ingress leaf, a 34 | spine, and an egress leaf. This means that you can have predictable 35 | network characteristics such as hop count and latency. For example, for 36 | intra-fabric communications, any destination is exactly two hops from 37 | its source (excluding advanced services such as overlay networking, 38 | firewalls, load balancers, etc.). 39 | 40 | .. _ip-fabric-routing: 41 | 42 | IP Fabric Routing 43 | ----------------- 44 | 45 | When designing an IP fabric, there are two primary designs, though both 46 | leverage BGP. 47 | 48 | .. _ibgp: 49 | 50 | iBGP 51 | ^^^^ 52 | 53 | In an iBGP design, an IGP such as OSPF or IS-IS is used to provide 54 | multipathing. iBGP peerings are formed over loopback interfaces, and 55 | route reflectors can be used to increase the scale of the solution. 56 | Route reflection, however, introduces its own issues. 57 | 58 | When the same prefix is received from multiple leafs by a route 59 | reflector spine, it will (by default) only advertise the best path to 60 | the non-route-reflector spines. This results in suboptimal traffic 61 | forwarding, and in congested scenarios may result in avoidable 62 | congestion and degradation of service. To resolve this issue, BGP 63 | ADD-PATH can be used. BGP ADD-PATH causes the router to prefix a unique 64 | path identifier to a prefix advertisement; because of this, all routers 65 | at the spine level must support and be configured for BGP ADD-PATH. 66 | 67 | .. _ebgp: 68 | 69 | eBGP 70 | ^^^^ 71 | 72 | With eBGP, there is no IGP -- BGP acts in a similar role as an IGP. In 73 | this design, each leaf node is given a unique ASN and all spines either 74 | share the same ASN or have unique ASNs per node. 75 | 76 | .. note:: 77 | The QFX5100 Series book [#f1]_, particularly Chapter 7: IP Fabrics 78 | (Clos), seems to suggest that the spine switches should each have a 79 | unique ASN. However, multiple other sources such as RFC7938 [#f2]_ 80 | and BGP in the Data Center [#f3]_ suggest giving the spines the same 81 | ASN while allowing the leafs to have unique ASNs. This is likely to 82 | avoid the nead for ``multipath multiple-as`` on every leaf and to 83 | simplify spine configuration. However, even following this numbering 84 | scheme, the spines will ultimately require ``multipath multiple-as``. 85 | 86 | You might notice that because of this design, you will still need extra 87 | configuration to handle the scenario where a prefix is received from 88 | multiple switches. To work around this, use the 89 | ``set protocols bgp group multipath multiple-as`` BGP 90 | configuration. The biggest difference between this an the requirement 91 | for ADD-PATH in an :ref:`ibgp` is that ADD-PATH is a feature negotiated 92 | between peers, whereas ``multipath multiple-as`` is not. This results 93 | in less complexity and fewer places for things to go wrong. It also 94 | increases vendor and platform interoperability since ADD-PATH is not 95 | guaranteed to be supported on a given platform or vendor, but even 96 | without ``multipath multiple-as``, the fabric will still function 97 | (suboptimally). Additionally, if the spine switches are given the same 98 | ASN instead of a unique ASN per spine switch, the number of places that 99 | require ``multipath multiple-as`` might be reduced depending on your 100 | design and requirements. 101 | 102 | .. note:: 103 | ``multipath multiple-as`` is recommended on all nodes. You *can* get 104 | away with only deploying it in certain places, but that doesn't mean 105 | you should. One of the benefits of deploying an IP fabric is 106 | reproducibility, and when you start tailoring to such a degree, it 107 | increases the cognitive load on engineers supporting the fabric 108 | because they can no longer assume similar behavior amongst nodes. 109 | 110 | .. _ip-fabric-scaling: 111 | 112 | IP Fabric Scaling 113 | ----------------- 114 | 115 | The scalability of an IP fabric is largely limited by three things: 116 | 117 | * the acceptable oversubscription ratio 118 | * the number of uplinks available per leaf per pod 119 | * the number of ports per spine per pod 120 | 121 | The acceptable oversubscription ratio can determine both how many 122 | servers you attach to a leaf and how many spines you need to have, both 123 | of which influence and are influenced by your required speeds downstream 124 | toward servers. For example, assume you have a 48x10G switch with 125 | 6x40G uplinks. This gives you an oversubscription ratio of 480G:240G, 126 | or 2:1, if you have six spine switches. However, perhaps it's 127 | unacceptable to have a 2:1 oversubscription ratio. Maybe you require no 128 | oversubscription. In this case, you can either select a leaf switch 129 | with more 40G uplinks (and add more spine swithces), or you can decide 130 | that you will not attach any servers to half of the 10G ports. 131 | 132 | .. note:: 133 | You can get clever and, if your switch supports it, break out all of 134 | the 40G ports to 10G ports. Then use only 10G spines. Split your 135 | total 10G ports in half; this number is the number of spines you 136 | need. For example, given the same leaf port density above and 137 | breaking out the 40G ports, you would have 72x10G interfaces. 138 | Dividing this by two, there are 36 ports downstream toward servers 139 | and 36 ports upstream toward spines. This means that you need either 140 | 36 spines *or* multiple ports stacked on spines, perhaps on a 141 | chassis-based spine such as an MX240. The end result is that you are 142 | "wasting" 12x10G ports compared to the 2:1 oversubscription model, 143 | and you likely need more or larger spines. In reality, 36 server 144 | ports in a 48U rack is probably the most (or close to the most) 145 | you'll get anyway. All of this said, though, for the purposes of 146 | this exam, it's likely best to stick with the number of "downstream" 147 | and "upstream" ports as noted by the difference in port speeds 148 | (i.e., 10G vs. 40G or 40G vs 100G). 149 | 150 | .. _best-practices: 151 | 152 | IP Fabric Best Practices 153 | ------------------------ 154 | 155 | There is one critical consideration to make when selecting links between 156 | spines and leafs: bandwdith. If you go the :ref:`ibgp` route (and you 157 | use OSPF or use different metrics for different bandwidths in IS-IS), 158 | your ECMP will be affected if you have mixed uplink bandwidth from your 159 | leafs (such as 10G and 40G). The result is that you will have some 160 | unutilized links (except in failure scenarios). 161 | 162 | However, with eBGP, link bandwidth is not considered for path 163 | calculation. If your design uses different bandwidth links, this might 164 | initially seem like a good thing because it results in all links being 165 | utilized. However, they are not intelligently utilized. You can easily 166 | exceed the utilization of the lower capacity links, resulting in either 167 | service degradation or complete outage conditions (depending on your 168 | SLAs). 169 | 170 | For this reason, in either design, it is critical to ensure that all 171 | paths to a given destination from all possible ingress points have the 172 | same total link bandwidth. This makes managing oversubscription and 173 | scaling much easier. 174 | 175 | All swithces at a given stage (spine, leaf, etc.) should be of the same 176 | model. This isn't strictly required so long as they can all support the 177 | same features, but if you choose to use different switches, you will be 178 | limited by the smallest number of ports available. Another 179 | consideration is that some switches may hash traffic differently than 180 | others, leading to unpredictable load sharing characteristics. In other 181 | words, it's okay if your spines and leafs are different models, but all 182 | of your spines should be the same model, and all of your leafs should be 183 | the same model. 184 | 185 | .. note:: 186 | *Technically* you aren't limited by the number of ports. However, 187 | this section is all about best practices. So, in the spirit of best 188 | practices, don't try to mix and match models in the same pod. 189 | 190 | If you have a use case for different spine switches in different pods, 191 | then you can use different spine switches in different pods. An example 192 | of this might be for "bug diversity." In other words, you don't want 193 | all of your global data centers to be hit by the same platform/OS bug at 194 | the same time, so you might deploy different vendors or platforms in 195 | each fabric pod. However, inside of any given pod, you should still use 196 | the same model switch. 197 | 198 | When connecting leaf switches to spine switches, every leaf should be 199 | connected to every spine. Again, you can get away with not doing this, 200 | but to do so is to invite heartache. If you're thinking of doing it for 201 | scaling reasons, consider implementing a 5-stage IP fabric instead. 202 | This brings some different complexity (not covered here), but it also 203 | brings easier and greater scalability without the risks of 204 | unintentionally oversubscribing or modifying the predictability of some 205 | of your fabric switches but not others. 206 | 207 | Configuration 208 | ------------- 209 | 210 | TODO: Add configuration examples for an IGP with iBGP, eBGP with iBGP, 211 | and straight eBGP. 212 | 213 | .. rubric:: Footnotes 214 | 215 | .. [#f1] `Juniper QFX5100 Series `_ 216 | .. [#f2] `RFC7938: Use of BGP in Large-Scale Data Centers, Section 5.2: EBGP Configuration for Clos Topology `_ 217 | .. [#f3] `BGP in the Data Center, Chapter 2, ASN Numbering Model `_ 218 | -------------------------------------------------------------------------------- /requirements.txt: -------------------------------------------------------------------------------- 1 | sphinx<2 2 | rinohtype 3 | -------------------------------------------------------------------------------- /vxlan-evpn.rst: -------------------------------------------------------------------------------- 1 | .. _vxlan-evpn: 2 | 3 | EVPN VXLAN Signaling 4 | ==================== 5 | 6 | Coming soon! 7 | --------------------------------------------------------------------------------