ipspace / netlab

Making virtual networking labs suck less
https://netlab.tools
Other
439 stars 66 forks source link

Modeling pure VXLAN topologies #400

Closed jbemmel closed 2 years ago

jbemmel commented 2 years ago

I'm trying to build a topology with VXLAN to the hosts (FRR)

My current approach:

vrfs:
  red:
    evpn.transit_vni: true # enable symmetric irb
  blue:

vlans:
  red:
    mode: irb # 'route' looses vlan.access (name of vlan) to lookup VXLAN-related parameters
    vrf: red
  blue:
    mode: bridge
    vrf: blue

vxlan.vlans: [ red, blue ]
...

links:
- h1:
  leaf1:
  role: fabric
  vlan.trunk: [ red, blue ] # This pulls in the vlans and vrfs

Relevant interfaces:

interfaces:
- bgp:
    local_as: 65001
  clab:
    name: e1-1
  ifindex: 1
  ifname: ethernet-1/1
  ipv4: true
  ipv6: true
  linkindex: 1
  name: leaf1 -> h1
  neighbors:
  - ifname: eth1
    ipv4: true
    ipv6: true
    node: h1
  role: fabric
  subif_index: 2
  type: p2p
- ifindex: 4
  ifname: ethernet-1/1.1001
  parent_ifindex: 1
  parent_ifname: ethernet-1/1
  type: vlan_member
  virtual_interface: true
  vlan:
    access: blue
    access_id: 1001
- ifindex: 5
  ifname: ethernet-1/1.1000
  parent_ifindex: 1
  parent_ifname: ethernet-1/1
  type: vlan_member
  virtual_interface: true
  vlan:
    access: red
    access_id: 1000
- bgp:
    local_as: 65001
  bridge_group: 1
  ifindex: 6
  ifname: irb0.1001
  name: VLAN blue (1001) -> [h3,h1,h4,leaf2,h2]
  neighbors:
  - ifname: eth1
    ipv4: 172.16.1.6/24
    node: h3
  - ifname: br1001
    node: h1
  - ifname: eth1
    ipv4: 172.16.1.7/24
    node: h4
  - ifname: irb0.1001
    node: leaf2
  - ifname: br1001
    node: h2
  type: svi
  virtual_interface: true
  vlan:
    mode: bridge
  vrf: blue
- bgp:
    local_as: 65001
  bridge_group: 2
  ifindex: 7
  ifname: irb0.1000
  ipv4: 172.16.0.2/24
  name: VLAN red (1000) -> [h1,h2,leaf2]
  neighbors:
  - ifname: br1000
    ipv4: 172.16.0.4/24
    node: h1
  - ifname: br1000
    ipv4: 172.16.0.5/24
    node: h2
  - ifname: irb0.1000
    ipv4: 172.16.0.3/24
    node: leaf2
  type: svi
  virtual_interface: true
  vlan:
    mode: irb
  vrf: red

In this data model, ethernet-1/1.1000 and .1001 are L2 VXLAN interfaces with VNIs; the VLAN access_id is not used.

Is this how we could/should model pure VXLAN setups? Do we need some conditional logic in interface naming, e.g. if vlan is included in vxlan.vlans then create a pure vxlan interface instead of a svi?

ipspace commented 2 years ago

I'm trying to build a topology with VXLAN to the hosts (FRR)

Watch your terminology. "VXLAN to the hosts" means "hosts are VTEPs, switches are just IP routers", which is obviously not the case in your topology.

In this data model, ethernet-1/1.1000 and .1001 are L2 VXLAN interfaces with VNIs; the VLAN access_id is not used.

I'm guessing you're talking about "port-based service", which is not supported by the EVPN module.

Is this how we could/should model pure VXLAN setups? Do we need some conditional logic in interface naming, e.g. if vlan is included in vxlan.vlans then create a pure vxlan interface instead of a svi?

Think about what you're really trying to do for a moment. If two interfaces belong to the same VNI, then they are in the same bridging domain, which makes it totally equivalent to them being in the same VLAN, which makes it perfectly fine to configure those interfaces as VLAN access interfaces. That's also how most ASICs would implement stuff internally.

ipspace commented 2 years ago

Can we close this? I guess it's been resolved now that the FRR implementation is complete.