IP Deployment Strategies - F2 Tech€¦ · Title: Enterprise - Universal Cloud Network Architecture...

Confidential. Copyright © Arista 2019. All rights reserved.Confidential. Copyright © Arista 2019. All rights reserved.

IP Deployment StrategiesRyan Morris – System Engineer

[email protected]

1

Confidential. Copyright © Arista 2019. All rights reserved.

What Will Be Covered

• Types of Traffic

• PTP Approaches

• Multicast and Architectural Considerations

• Bandwidth Management

• Conclusions

2


What Will Be Covered

• Types of Traffic

• PTP Approaches

• Multicast and Architectural Considerations

• Bandwidth Management

• Conclusions

3


Keeping Quality Programming Online

4


Types of Traffic

Arista Networks

5


Multicast – The Context

• Broadcast

- one to all within the subnet

• Unicast

- one to one, routable. Destination defined by sender

• Multicast

- one to one, one or many, routable. Destination defined by receiver!

6


Multicast – The Context

• Multicast is a good fit for live uncompressed media

- Typically there is a one to many fan out

- Many signals on one cable

- The sender don’t know who needs to consume their output

- Multicast traditionally used in Media and Finance Market. Understanding it and working

with traditional IT teams is paramount

7


PTP Approaches

Arista Networks

8


PTP – What Is It and How Does It Work?

• Timing for all SMPTE-2110 devices – Generally SMPTE 2059-2

• Generally, one Domain is used per network, unless different profiles are used

• PTP is vital for a SMPTE 2110 Network

• PTP is multicast – 224.0.1.129

• Do regular multicast rules apply to PTP as they would for other multicast

signals on your network? Yes – but with caveats.

9


PTP – What Is It and How Does It Work?

10

• Announce messages sent by the master

- Received by all slaves (and potential masters)

- Typically 1 per second

- Used in the BMCA process to elect a GM

• Syncs sent periodically by the master

- Received by all slaves


- Not dissimilar to NTP!

• Delay Requests sent by slaves


• Delay Response back from master to the slaves


PTP – Quite A Few Messages

11

Message Type

Slave messages

received per sec

Slave messages

transmitted per sec

Announce 1 0

Sync 8 0

Followup 8 0

Delay-req 0 8

Delay-resp 8 0

Total Messages per slave 25 8

Total Messages for 300

slaves 7500 2400

SO MANY MESSAGES GOING TO EVERY SINGLE DEVICE… EVERY SECOND…

CAN CAUSE ADDED JITTER, OVERLOADING DEVICES – INCLUDING THE GM ITSELF… HOW CAN WE MITIGATE THIS?


PTP Clock Types

• Boundary Clock

- Eliminates switch delay (== jitter)

- Switch acts as both Slave and Master

- Run host ports at the rate you need

- Switch will free-run based on previous GM lock in the

absence of a real GM

• Transparent Clock

- Eliminates switch delay (== jitter)

- Messages forwarded through switch

- Slaves use correction field to improve accuracy

- Use in conjunction with Hybrid Mode – take advantage of

unicast

12

BC

TC TC

PTP

Slaves

PTP

Slaves

GM


Back to the BMCA – Best Master Clock Algorithm

• Attributes used to select the BEST Grandmaster are in the Announce Message

- Priority 1 (Lowest Number Wins)

- Clock Class (GPS = 6 ; Free Run = 248)

- Clock Accuracy (to UTC)

- Clock Variance (Jitter and Wander)

- Priority 2 (Lowest Number Wins)

- GMID (Mac address)

• P1 and P2 are configurable on the GM and on the switch when in Boundary

Clock mode

13


PTP – Controlling WHO is your GM

14

GM1

P1 = 1

Class = 6

P2 = 2

GM2

P1 = 1

Class = 6

P2 = 3

SW1

P1 = 10

Class = 248

P2 = 20

SW2

P1 = 10

Class = 248

P2 = 30

P1’s and Clock Class on GMs are equal

P2 of GM1 has precedence over P2 of GM2,

therefore GM1 wins



15

GM1

P1 = 1

Class = 248

P2 = 2

GM2

P1 = 1

Class = 6

P2 = 3

SW1

P1 = 10

Class = 248

P2 = 20

SW2

P1 = 10

Class = 248

P2 = 30Lost GPS!

P1’s are equal

Clock class of GM2 is GPS locked, therefore GM2 wins



16

GM1

P1 = 1

Class = 6

P2 = 2

GM2

P1 = 1

Class = 6

P2 = 3

SW1

P1 = 10

Class = 248

P2 = 20

SW2

P1 = 10

Class = 248

P2 = 30

No GM in this system

SW1 and SW2 have equal P1s and are both free-run

P2 on SW1 is a lower value than P2 on SW2, therefore

SW1 wins



17

GM1

P1 = 1

Class = 248

P2 = 2

GM2

P1 = 1

Class = 6

P2 = 3

SW1

P1 = 10

Class = 248

P2 = 20

SW2

P1 = 10

Class = 248

P2 = 30

Link loss between the switches

GM1 and GM2 are GMs for their individual networks

AND GM1 lost its GPS lock – GM1 and GM2 are no longer

in sync

Lost GPS!


PTP – What Can The Distribution Look Like?

18


PTP – One Final Note

19

• Invest in PTP Monitoring

• Many solutions out there – including Arista CVP


Multicast and Architectural

Considerations

Arista Networks

20


Design and Implementation Considerations… cont’d

• Know your endpoints

- Do they all support Source Specific Multicast? Will

they all?

≫ If not, use a rendez-vous point, which knows how the sources of

multicast groups

• Know your PTP distribution network

- Will Boundary Clock or Transparent Clock be

implemented?

- Avoid non-ptp aware switches… please – pretty please

• Know your switch platforms

- What interface rates? 10G? 25G? 40G? 100G? Or

even 400G…

- Feature sets – Deep Buffers, PTP Clock Modes, FEC

21


Architectural Overview – L2

• Layer 2 Multicast networks can function with ST-2110

deployments, but there are points to consider

- Multicast is forwarded to the IGMP Querier (What is A Querier???)

- Expansion can be tricky – because of the Querier!

- Cascading Layer 2 Multicast switches won’t benefit anyone

Querier

This forwarding, in and L2 network, can’t be stopped.

With no querier, what happens when the link between the

switches is no longer present? Nothing good.

Flooding multicast on the vlan.

22


Architectural Overview – L2 – A Pitfall

• L2 aliasing

- For each valid destination multicast

MAC address, there exist 32 valid

multicast group addresses.

≫ 224.0.1.2 = 224.128.1.2 = 225.0.1.2….=

239.128.1.2239.1.1.1:1000

238.1.1.1:2000

237.1.1.1:3000

IGMP Join:

239.1.1.1:1000

Receives ALL

streams

23


Architectural Overview – L3 (The Answer)

• Revisit the previous system, but

with a small change.

• Layer 3 connections between the

switches.

• Hosts in each switch belong to

different subnets.

PIMPIM

• Why is this advantageous?

- No Flooding the querier between

switches!

- More scalable and more flexible

- Reduced blast radius

- Take advantage of Broadcast

Controllers

24


Architectural Options – Things to Think About

• How Do We Decide:

- How resilient will the network be?

- What will the topology be? Monolithic or IP Fabric?

- If we will be using Layer 2 or Layer 3?

- If the networks will be red/blue or purple?

- If we want to use a broadcast controller – or rely on IGMP?

25


Architectural Options – Monolithic or IP Fabric?

• Monolithic Approach

- Relying on IGMP is acceptable, broadcast controller for bandwidth management is not required

- ST-2022-7 redundancy available

- Simpler configuration

≫ No routing protocols required

≫ Redundancy with backup supervisors and swappable linecards

≫ Can configure all devices, if they fit, in a single vlan – or reduce size of blast radius by segregating traffic. No routing protocol required

BUT

- Scalability must be well thought-out

- May eventually require SDN, depending on expansion

PTP Only

26



PTP Only

• Air-gapped Spine-Leaf Approach

(Red&Blue)

- ST-2022-7 Redundancy is still available

- Air-gap provides extra security

- Scalable for future expansion

- PTP distribution is scalable and robust

BUT

- Added network configuration is required to

facilitate routing (unicast and multicast)

- SDN could be required to statically map

multicast groups – hashing can be dangerous

27



• Hybrid Air-gapped Spine-Leaf Approach

(Red&Blue, with Purple)

- Very similar to fully airgapped solution

- Add in Purple Switch for single-homed devices –

all switches could be Purple

BUT

- Added network configuration is required to

facilitate routing (unicast and multicast)

- SDN could be required to statically map

multicast groups – hashing can be dangerous

- More single points of failure, because of single-

homed devices

PTP Only

28


Bandwidth Management

Arista Networks

29


Arista MCS- Why Do We Need This?

• Existing limitations- PIM/IGMP/LAG are not bandwidth aware

- Assumption of a *,G forwarding model doesn’t fit media applications

- Need a faster, parallel, and more deterministic way to program media streams

- No standardized way to enforce stream state and bandwidth

- Telemetry is lacking

• Goals- Remove the requirement for PIM and IGMP for multicast provisioning

- Fast and parallel programming of stream entries

- Provide mechanisms for policing bandwidth and eliminate flooding

- Present a simple API and a single point of integration for multiple devices

- Provide real time telemetry and insight

30


MCS Is Not A Media Controller

31


Who Needs MCS?

Large, distributed, multi switch oversubscribed media networks

-More source bandwidth than any switch to switch interface can transport

-Cannot use existing protocols and configurations to define network forwarding

-Implementing a BC that can talk to multi-vendor API’s (network and endpoint)

≫This is KEY for 2110 deployments!!!

Non-blocking network designs

-Enough bandwidth for required flows to be distributed over available links with no risk of

oversubscription

-Examples: audio breakouts, lower bitrate file/compressed, defined I/O paths

Single switch, non-blocking deployments

-Bandwidth control not required

-IGMP for subscribers

-Current chassis scale to 500+ 100G ports or 2000+ 25G ports

✔

X

32


What is OpenConfig?

• Vendor-neutral, model-driven network management

designed by users

- Declarative configuration

- Streaming Telemetry

- Common data model for management and operations

33


Who is using and driving OpenConfig?

http://www.openconfig.net/about/participants

34

http://www.openconfig.net/about/participants


How Does This Apply To Media Networks?

• Standardized models and RPC’s for any network device- Easy for any media or broadcast controller to talk to any network vendor’s

device

- No single vendor lock-in

• High performance read/write capabilities for fast programming

of new flows- Direct and speedy control of L2 and L3 table state for input/output stream

programming

- Leverage traditional forwarding tables and models, not require expensive and

limited TCAM resources like OpenFlow

• Real-time updates of key metrics- Topology

- Counters

- Tables

35


Conclusions

• Many considerations when designing a network for ST-2110

• Must not just take into account the present, but also the future

• Expansion is paramount when designing these networks

• IP has EXTREME flexibility… take advantage of it!

• If you have any questions – find me after!

36


THANK YOU!!!!

37

IP Deployment Strategies - F2 Tech€¦ · Title: Enterprise - Universal Cloud Network Architecture...

Documents

Transcript of IP Deployment Strategies - F2 Tech€¦ · Title: Enterprise - Universal Cloud Network Architecture...