Underlay

Paul Mockapetris, co-inventor of the Domain Name System, joins Network Collective to talk about how DNS grew from an undesirable computer science experiment to one of the critical services that makes the Internet what 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/

Paul Mockapetris, co-inventor of the Domain Name System, joins Network Collective to talk about how DNS grew from an undesirable computer science experiment to one of the critical services that makes the Internet what it is today.

Paul Mockapetris Guest Russ White Host Donald Sharp Host Jordan Martin 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 – Paul Mockapetris – Origins of DNS appeared first on Network Collective.

In this Community Roundtable episode, returning guests Russ White and Nick Russo continue our three part deep dive into the Border Gateway Protocol, or BGP, with a look at the mechanisms within the protocol to perform traffic engineering.

Show Notes

Influence Ingress

• Classic bestpath options to influence ingress
• AS-path prepend outbound to influence inbound traffic
  • Why AS Path prepend doesn’t always work
    • In many areas, ISPs are in a full or almost full mesh and connected to common backbones making AS Path prepend largely irrelevant
    • Providers normally use their own local preference for outbound traffic back to a customer
  • MED
    • MED is a hint, it’s often stripped or ignored
    • MED only works if the AS Path is the same on all routes
    • MED is non-transitive and doesn’t mean anything beyond the next hop
  • • Longest Match
      • Be careful about this, as it pollutes the DFZ
        • DFZ = default free zone
          • A router belongs to the DFZ if it doesn’t need a 0.0.0.0 route to reach everything on the internet
      • Tragedy of the commons here
        • An enterprise can force inbound traffic to be load-balanced better but it pushes the processing of that traffic engineering onto the internet
      • This is the “big hammer”
    • Using RFC 1998 communities for influence ingress traffic
      • This is a way to signal your provider to take some sort of BGP action
      • You need to find the specific communities used by each provider
      • Make certain the provider accepts communities on their eBGP edge

Influence egress

• Local Pref
  • Overrides pretty much everything other than weight
  • Used to implement hot/cold potato routing
    • hot potato routing is when a provider chooses to get the traffic out of its network as quickly as possible at the closest egress point
    • cold potato routing is when a provider chooses to control some traffic as long as possible for some reason
•  Weight
  • Local to a device
• Other handy stuff:
  • Cost community: IGP and pre-bestpath POI
  • Accumulated IGP (AIGP)
  • iBGP tie breakers

• Using RFC 1998 communities for influence ingress traffic
  • This is a way to signal your provider to take some sort of BGP action
  • You need to find the specific communities used by each provider
  • Make certain the provider accepts communities on their eBGP edge
• BGP deterministic MED

 

Russ White Guest

In this Community Roundtable episode, returning guests Russ White and Nick Russo continue our three part deep dive into the Border Gateway Protocol, or BGP, with a look at the mechanisms within the protocol to perform traffic engineering.

Show Notes

Influence Ingress

* Classic bestpath options to influence ingress

* AS-path prepend outbound to influence inbound traffic

* Why AS Path prepend doesn’t always work

* In many areas, ISPs are in a full or almost full mesh and connected to common backbones making AS Path prepend largely irrelevant

* Providers normally use their own local preference for outbound traffic back to a customer

* MED

* MED is a hint, it’s often stripped or ignored

* MED only works if the AS Path is the same on all routes

* MED is non-transitive and doesn’t mean anything beyond the next hop

* Longest Match

* Be careful about this, as it pollutes the DFZ

* DFZ = default free zone

* A router belongs to the DFZ if it doesn’t need a 0.0.0.0 route to reach everything on the internet

* Tragedy of the commons here

* An enterprise can force inbound traffic to be load-balanced better but it pushes the processing of that traffic engineering onto the internet

* This is the “big hammer”

* Using RFC 1998 communities for influence ingress traffic

* This is a way to signal your provider to take some sort of BGP action

* You need to find the specific communities used by each provider

* Make certain the provider accepts communities on their eBGP edge

Influence egress

* Local Pref

* Overrides pretty much everything other than weight

* Used to implement hot/cold potato routing

* hot potato routing is when a provider chooses to get the traffic out of its network as quickly as possible at the closest egress point

* cold potato routing is when a provider chooses to control some traffic as long as possible for some reason

*  Weight

* Local to a device

* Other handy stuff:

* Cost community: IGP and pre-bestpath POI

* Accumulated IGP (AIGP)

* iBGP tie breakers

* Using RFC 1998 communities for influence ingress traffic

* This is a way to signal your provider to take some sort of BGP action

* You need to find the specific communities used by each provider

* Make certain the provider accepts communities on their eBGP edge

* BGP deterministic MED

 

Outro Music:

Danger Storm Kevin MacLeod (incompetech.com)

Licensed under Creative Commons: By Attribution 3.0 License

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

In this episode of History of Networking, Alistair Woodman joins us again to continue the conversation on the origins of commercial VoIP.

Outro Music:

Danger Storm Kevin MacLeod (incompetech.com)

Licensed under Creative Commons: By Attribution 3.0 License

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

In this episode of History of Networking, Alistair Woodman joins us again to continue the conversation on the origins of commercial VoIP.

Alistair Woodman Guest Russ White Host Donald Sharp Host Jordan Martin 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 – Alistair Woodman – VoIP Continued appeared first on Network Collective.

In Episode 18 of Network Collective, Pete Lumbis of Cumulus Networks and Kevin Myers of IP Architechs join us to talk about the pros and cons of running whitebox or commodity hardware in your network. There’s no denying that the price point on commodity hardware is attractive but we discuss all you should consider when you’re looking to transition away from a major network hardware vendor.

 

Show Notes

What is whitebox networking?

* Has a variety of definitions depending on the person answering

* Associated with ONIE and Oss like Cumulus Linux, BigSwitch, IPI

* Commodity hardware not mainstream vendor with OS that may or may not be from the same vendor

* To some, hardware has more to do with hardware

* Commodity hardware has to do with using chipset, board, or even layout that someone else created

* Component of disaggregation to consider

* Britebox is the larger vendors offering disaggregation options

* Whietbox equipment isn’t about homemade devices soldered together in our garages

 

Why whitebox networking?

* The original impetus for whitebox was often around cost, and sometimes it still is

* Current reasons are to have more options like customized operating systems

* Whitebox utilizes the equipment to move to an x86 model that compute moved to decades ago

 

Are there whitebox performance and capabilities considerations?

* Whitebox uses mostly the same ASICS as most of the large vendors, so the performance is pretty much the same

* Whitebox must be able to deliver the same performance of the largest networking vendors in order to be competitive

* Whitebox vendors are typically able to meet the marketplace where it is and where it’s going because of how flexible they are

* Some chipsets are tailored to certain performance characteristics, so it’s still a consideration when choosing whitebox solutions

 

Why is whitebox such a popular discussion today?

* Webscale companies have requirements for hardware and software that accommodate their size

* Whitebox solutions better accommodate webscale deployments because of cost and customization

* Non-webscale organizations are beginning to take advantage of similar opportunities but the argument is only now starting to become compelling

* Whitebox vendors haven’t necessarily been able to meet the support needs of a typical enterprise (TAC, channel sales, etc)

* This is starting to change which makes whitebox much more relevant to typical enterprise IT

 

Is whitebox networking relevant to typical enterprise IT?

* Whitebox vendors haven’t necessarily been able to meet the support needs of a typical enterprise (TAC, channel sales, etc)

* This is starting to change which makes whitebox much more relevant to typical enterprise IT

* There is fear among mid-level network admins working in smaller enterprise organizations that affect the decision-making process to consider whitebox networking

* Cost is not necessarily the overwhelming motivator to consider or not consider whitebox in the enterprise

* There is a trend to believe that going to whitebox requires a large team of extremely high-level engineers

* this is false but is still a stumbling block for decision-makers

* The large networking vendor partner community is extremely well established making switching to whitebox very difficult even when the whitebox financial component is extremely compelling

* Large networking vendors are also excellent logistic companies that make operational support much easier for enterprise IT engineers

 

In Episode 18 of Network Collective, Pete Lumbis of Cumulus Networks and Kevin Myers of IP Architechs join us to talk about the pros and cons of running whitebox or commodity hardware in your network. There’s no denying that the price point on commodity hardware is attractive but we discuss all you should consider when you’re looking to transition away from a major network hardware vendor.

 

Show Notes

What is whitebox networking?

• Has a variety of definitions depending on the person answering
• Associated with ONIE and Oss like Cumulus Linux, BigSwitch, IPI
• Commodity hardware not mainstream vendor with OS that may or may not be from the same vendor
• To some, hardware has more to do with hardware
• Commodity hardware has to do with using chipset, board, or even layout that someone else created
• Component of disaggregation to consider
• Britebox is the larger vendors offering disaggregation options
• Whietbox equipment isn’t about homemade devices soldered together in our garages

 

Why whitebox networking?

• The original impetus for whitebox was often around cost, and sometimes it still is
• Current reasons are to have more options like customized operating systems
• Whitebox utilizes the equipment to move to an x86 model that compute moved to decades ago

 

Are there whitebox performance and capabilities considerations?

• Whitebox uses mostly the same ASICS as most of the large vendors, so the performance is pretty much the same
• Whitebox must be able to deliver the same performance of the largest networking vendors in order to be competitive
• Whitebox vendors are typically able to meet the marketplace where it is and where it’s going because of how flexible they are
• Some chipsets are tailored to certain performance characteristics, so it’s still a consideration when choosing whitebox solutions

 

Why is whitebox such a popular discussion today?

• Webscale companies have requirements for hardware and software that accommodate their size
• Whitebox solutions better accommodate webscale deployments because of cost and customization
• Non-webscale organizations are beginning to take advantage of similar opportunities but the argument is only now starting to become compelling
  • Whitebox vendors haven’t necessarily been able to meet the support needs of a typical enterprise (TAC, channel sales, etc)
    • This is starting to change which makes whitebox much more relevant to typical enterprise IT

 

Is whitebox networking relevant to typical enterprise IT?

• Whitebox vendors haven’t necessarily been able to meet the support needs of a typical enterprise (TAC, channel sales, etc)
  • This is starting to change which makes whitebox much more relevant to typical enterprise IT
• There is fear among mid-level network admins working in smaller enterprise organizations that affect the decision-making process to consider whitebox networking
• Cost is not necessarily the overwhelming motivator to consider or not consider whitebox in the enterprise
  • There is a trend to believe that going to whitebox requires a large team of extremely high-level engineers
    • this is false but is still a stumbling block for decision-makers
• The large networking vendor partner community is extremely well established making switching to whitebox very difficult even when the whitebox financial component is extremely compelling
• Large networking vendors are also excellent logistic companies that make operational support much easier for enterprise IT engineers

 

What are challenges to whitebox networking?

• The support model still

In this episode of History of Networking, Jeff Tantsura (Chair of the IETF Routing Area Working Group and Consulting VP of Network Architecture at Futurewei) joins Network Collective to discuss the origins and history of Segment Routing.

Episode Links:

* http://www.segment-routing.net/

* http://www.segment-routing.org/

* 1st SR alike architecture

* https://tools.ietf.org/html/draft-tian-mpls-lsp-source-route-01

* List of Segment Routing IETF drafts

* http://www.segment-routing.net/ietf/

* NANOG Presentation On Limitations of Maximum SID Depth

* https://pc.nanog.org/static/published/meetings/NANOG71/1424/20171004_Tantsura_The_Critical_Role_v1.pdf

Outro Music:

Danger Storm Kevin MacLeod (incompetech.com)

Licensed under Creative Commons: By Attribution 3.0 License

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

In this episode of History of Networking, Jeff Tantsura (Chair of the IETF Routing Area Working Group and Consulting VP of Network Architecture at Futurewei) joins Network Collective to discuss the origins and history of Segment Routing.

Episode Links:

• http://www.segment-routing.net/
• http://www.segment-routing.org/
• 1st SR alike architecture
  • https://tools.ietf.org/html/draft-tian-mpls-lsp-source-route-01
• List of Segment Routing IETF drafts
  • http://www.segment-routing.net/ietf/
• NANOG Presentation On Limitations of Maximum SID Depth
  • https://pc.nanog.org/static/published/meetings/NANOG71/1424/20171004_Tantsura_The_Critical_Role_v1.pdf

Jeff Tantsura Guest Jordan Martin Host Russ White Host Donald Sharp Host

Outro Music:
Danger Storm Kevin MacLeod (incompetech.com)
Licensed under Cr