Underlay

Fred Baker joins Network Collective for a second episode, this time sharing the story about how the IETF came to an official policy regarding systemic Internet surveillance and wiretapping in data networking.

Show Notes

* IETF Policy on Wiretapping – RFC 2804

* IAB and IESG Statement on Cryptographic

Fred Baker joins Network Collective for a second episode, this time sharing the story about how the IETF came to an official policy regarding systemic Internet surveillance and wiretapping in data networking.

Show Notes

• IETF Policy on Wiretapping – RFC 2804
• IAB and IESG Statement on Cryptographic Technology and the Internet – RFC 1984

Fred Baker Guest Russ White Host Donald Sharp Host Jordan Martin Host Eyvonne Sharp Host

Outro Music:
Danger Storm Kevin MacLeod (incompetech.com)
Licensed under Creative Commons: By Attribution 3.0 License
http://creativecommons.org/licenses/by/3.0/

The post History Of Networking – Fred Baker – RAVEN and Internet Surveillance appeared first on Network Collective.

In episode 15, Pete Welcher and Chris Kane join us to talk about what exactly characterizes a well run network. Is it great documentation? Is it consistent application of best practices? Maybe it’s process and procedure? Join our guests, and the decades of experience they bring, as they sit around the virtual roundtable to share their thoughts on the topic.

 

Show Notes

Design

* Keep it simple. Just because you can, doesn’t mean you should

* Complexity is not just a networking attribute, it’s an overall system attribute

* Proper design leads to simplicity (most of the time)

* What technologies are simple? How do you recognize complexity? Is vendor lock-in one indicator? Network management software / API lock-in another growing one?

* There are some pretty simple campus/user, datacenter, Internet Edge, and WAN approaches Big organizations can handle and may need a bit more complexity — or not

* Modularity- too many moving parts that have to work together = complex

Operations

* Transparent Network. It just works

* Able to easily implement changes

* Agnostic to both today’s needs and flexible to absorb tomorrow’s needs

* Up-to-date diagrams and documentation matter

* Organized around OSI layers

* Documented naming conventions with fixed fields

* MTTR e.g. from NetMRI and some other tools

* Up-to-date code

* Common code across any given router or switch model Measurement

* There is no way to tell how the network is performing currently as compared to previous performance unless data is collected at regular intervals

* Ideally is done via more sophisticated tooling that not only gathers the data but also performs benchmarks and reports on anomalies

* Network awareness among engineers

* Interpersonal communication and team collaboration

Lab Testing

* Used to be sacrificed as a CAPEX or OPEX that was cost prohibitive because of the vast resources needed to provide test points outside, on the edges, of the network

* All network designers and operators should expect/select OEMs that provide a virtual edition of their hardware

* These software-only solutions should be used to re-create at least a subset if not all of the infrastructure. Then this virtual environment can be used to rehearse upcoming changes and their possible effects/outcomes.

* This should also be used to verify that backups are not only occurring but are actually useful. Much like an application or database backup should be regularly tested, so should the network backups.

Change Management

* Wear a black concert T-shirt during all Maintenance Windows

* Listen to Grunge music as IP truly came of money-making age during that era and the music soothes the network.

* If in a datacenter, noise-cancelling headphones and conf call helps. Sep call/webex with 30 minute updates for execs (prevents constant second-guessing and distraction), and liaison on both the tech and exec call, jotting notes for periodic exec update

* Have an Implementation Plan

* Tabs in XLS, including contact info, pre-change configs, configlets to blow in, test plan, backout configlets. All SSH connections opened prior to change window.

* Peer Review and Sign Off of Implementation Plan

* Take Pre-Change Snapshots/Health Checks

* Take Post-Change Snapshots/Health Checks

* Insist upon user/app owner User Acceptance Testing to occur prior to and after completion of the change.

* Use lab network

* When selecting between OEM solutions you absolutely must conduct a Proof-of-Concept as reading of data sheets and white papers does not a sound decision make.

* Regularly train the Ops team

In episode 15, Pete Welcher and Chris Kane join us to talk about what exactly characterizes a well run network. Is it great documentation? Is it consistent application of best practices? Maybe it’s process and procedure? Join our guests, and the decades of experience they bring, as they sit around the virtual roundtable to share their thoughts on the topic.

 

Show Notes

Design

• Keep it simple. Just because you can, doesn’t mean you should
• Complexity is not just a networking attribute, it’s an overall system attribute
• Proper design leads to simplicity (most of the time)
• What technologies are simple? How do you recognize complexity? Is vendor lock-in one indicator? Network management software / API lock-in another growing one?
• There are some pretty simple campus/user, datacenter, Internet Edge, and WAN approaches Big organizations can handle and may need a bit more complexity — or not
• Modularity- too many moving parts that have to work together = complex

Operations

• Transparent Network. It just works
• Able to easily implement changes
• Agnostic to both today’s needs and flexible to absorb tomorrow’s needs
• Up-to-date diagrams and documentation matter
  • Organized around OSI layers
  • Documented naming conventions with fixed fields
  • MTTR e.g. from NetMRI and some other tools
• Up-to-date code
• Common code across any given router or switch model Measurement
• There is no way to tell how the network is performing currently as compared to previous performance unless data is collected at regular intervals
• Ideally is done via more sophisticated tooling that not only gathers the data but also performs benchmarks and reports on anomalies
• Network awareness among engineers
• Interpersonal communication and team collaboration

Lab Testing

• Used to be sacrificed as a CAPEX or OPEX that was cost prohibitive because of the vast resources needed to provide test points outside, on the edges, of the network
• All network designers and operators should expect/select OEMs that provide a virtual edition of their hardware
• These software-only solutions should be used to re-create at least a subset if not all of the infrastructure. Then this virtual environment can be used to rehearse upcoming changes and their possible effects/outcomes.
• This should also be used to verify that backups are not only occurring but are actually useful. Much like an application or database backup should be regularly tested, so should the network backups.

Change Management

• Wear a black concert T-shirt during all Maintenance Windows
• Listen to Grunge music as IP truly came of money-making age during that era and the music soothes the network.
  • If in a datacenter, noise-cancelling headphones and conf call helps. Sep call/webex with 30 minute updates for execs (prevents constant second-guessing and distraction), and liaison on both the tech and exec call, jotting notes for periodic exec update
• Have an Implementation Plan
  • Tabs in XLS, including contact info, pre-change configs, configlets to blow in, test plan, backout configlets. All SSH connections opened prior to change window.
• Peer Review and Sign Off of Implementation Plan
• Take Pre-Change Snapshots/Health Checks
• Take Post-Change Snapshots/Health Checks
• Insist upon user/app owner User Acceptance Testing to occur prior to and after completion of the change.
• Use lab network
• When selecting between OEM solutions you absolutely must conduct a Proof-of-Concept as reading of data sheets

Donnie Savage joins Network Collective to talk about his role in the history of EIGRP. From its early implementations to moving this formerly fully proprietary protocol through the IETF, Donnie has played a significant role in guiding EIGRP to where it is today.

Outro Music:

Danger Storm Kevin MacLeod (incompetech.com)

Licensed under Creative Commons: By Attribution 3.0 License

http://creativecommons.org/licenses/by/3.0/

Donnie Savage joins Network Collective to talk about his role in the history of EIGRP. From its early implementations to moving this formerly fully proprietary protocol through the IETF, Donnie has played a significant role in guiding EIGRP to where it is today.

Donnie Savage Guest Jordan Martin Host Donald Sharp Host Russ White Host

Outro Music:
Danger Storm Kevin MacLeod (incompetech.com)
Licensed under Creative Commons: By Attribution 3.0 License
http://creativecommons.org/licenses/by/3.0/

The post History Of Networking – Donnie Savage – EIGRP appeared first on Network Collective.

In a return to our routing protocol series, Russ White and Nick Russo join Network Collective to talk about some of the intricacies of the IS-IS routing protocol. While not usually found in enterprises, Service Providers have used IS-IS as the underlay to their MPLS networks and it is starting to make an appearance as the underlay to several newer enterprise technologies. If you’ve been curious about how it works, and how it is different than what you use today, this show is for you.

 

In a return to our routing protocol series, Russ White and Nick Russo join Network Collective to talk about some of the intricacies of the IS-IS routing protocol. While not usually found in enterprises, Service Providers have used IS-IS as the underlay to their MPLS networks and it is starting to make an appearance as the underlay to several newer enterprise technologies. If you’ve been curious about how it works, and how it is different than what you use today, this show is for you.

 

Show Links

https://www.iso.org/standard/30932.html

https://tools.ietf.org/html/rfc1142

https://en.wikipedia.org/wiki/Dijkstra%27s_algorithm

 

Show Notes

• IS-IS Characteristics
  • IS-IS is a graph
    • Vertices, edges, link types, cost
    • Uses Dijkstra’s algorithm
    • Based on Type Link Value protocol (TLV) instead of fixed type fields which allows IS-IS to be very extensible
    • Similar to OSPF, but the P-node is called the DIS, not the DR, and behaves a bit differently
    • Originally built for host routing
  • Not an IP protocol
    • direct encapsulation to L2, ethertype 0xFEFE
    • Provides some inherent security benefits (very hard to reach in and attack; OSPF solved this with TTL security)
  • QoS over L2VPNs
    • If the EFP is matching IP DSCP for QoS, ISIS may not be classified correctly. If the carrier Ethernet service is untagged, then there is no mechanism to provide QoS, notwithstanding manual Ethertype matching (not supported on all EFPs).
  • Two level hierarchy (level 1 and level 2)
    • Unlike OSPF, the two levels (areas in OSPF) can overlap
    • IS-IS levels are flooding domains
    • The two IS-IS levels can act independently enough that they can seem like two instances of a routing protocol running on top of each other
• What does IS-IS do well? What does it do poorly?
  • What does it do well?
    • has extensive tools for handling full mesh topologies
    • new routing initiatives are based in part on IS-IS
    • Good best choice for a leaf-spine and non hub-and-spoke topologies
  • What does it do poorly?
    • Hub and Spoke topologies
    • Difficulty with QoS because it is its own protocol and not IP
• Comparison to OSPF
  • Similarities
    • Both are link state, both have a two-tier hierarchical flooding domain
    • relatively inflexible topology/filtering options within a flooding domain
  • Differences
    • IS-IS is easier to extend to support different functions (more extensible)
    • Important: overlapping topologies can solve a lot of issues, like relatively straightforward TE issues without MPLS or fibbing. Just enable L1/L2 in specific parts of the network, assign subnets to L1 or L2, and adjust L1-specific or L2-specific costs accordingly
    • Areas in IS-IS are not like OSPF, and are mostly relevant in L1 topologies
    • The DIS in IS-IS is different from the DR in OSPF
  • Caveats
    • Two intermediate systems must be in the same area to form L1 neighbors
    • It is possible to span an IS-IS area across L1 and L2 topologies, but the AT bit won’t be set in the L1 area, potentially causing reachability issues (Depends on whether this is desirable or not)
    • A general strategy for deploying IS-IS in a network that is seen to grow is to regionalize ISIS areas.
      • For example, each regional POP can be in separate areas while the backbon

Radia Perlman joins Network Collective to talk about the history of the Spanning Tree Protocol. Love it or hate it, it’s been a fundamental part of every Ethernet network for the past 30 years and isn’t likely to fade away any time soon.

Radia Perlman Guest Jordan Martin Host Donald Sharp Host Russ White Host

Outro Music:
Danger Storm Kevin MacLeod (incompetech.com)
Licensed under Creative Commons: By Attribution 3.0 License
http://creativecommons.org/licenses/by/3.0/

The post History Of Networking – Radia Perlman – Spanning Tree appeared first on Network Collective.

In episode 13, the Network Collective hosts go it alone and take an introspective look at the engineering community, warts and all. We dig into topics relating to ego, hero mentality, overconfidence, short memories, and the negative side of the hype cycle.

 

Jordan Martin Co-Host Eyvonne Sharp Co-Host