cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
223
Views
0
Helpful
2
Replies

static VxLAN tunnel - ingress replication protocol static

hrtendrupUCM
Level 1
Level 1

Hello,

I'm trying to provide some guidance different vxlan overlay options, showing the tradeoffs of simplicity and scalability. I'm tryin to use CML to show that an org COULD use static vxlan tunnels to send traffic around, but the nx9k images don't seem to be sending the traffic. I feel like I'm missing something very basic, but the config itself is pretty basic.

Is anyone aware of limitations with the CML nx9k images where data-plane learning doesn't work?

I've attached the CML yaml file with the configs

topology and relevant configs:

hrtendrupUCM_0-1725978265244.png

hostname S1
!
feature ospf
feature vn-segment-vlan-based
feature nv overlay
!
vlan 10
vn-segment 1000010
!
no spanning-tree vlan 10
vrf context HOSTSIM
address-family ipv4 unicast
vrf context management
!
interface nve1
no shutdown
source-interface loopback0
member vni 1000010
ingress-replication protocol static
peer-ip 10.0.0.4
!
interface Ethernet1/1
no switchport
ip address 10.1.2.1/24
ip ospf network point-to-point
ip router ospf WANCORE area 0.0.0.0
no shutdown
!
interface Ethernet1/2
no switchport
ip address 10.1.3.1/24
ip ospf network point-to-point
ip router ospf WANCORE area 0.0.0.0
no shutdown
!
interface Ethernet1/4
no switchport
vrf member HOSTSIM
ip address 192.168.100.1/24
no shutdown
interface Ethernet1/5
switchport access vlan 10
spanning-tree port type edge
!
interface loopback0
ip address 10.0.0.1/32
ip ospf network point-to-point
ip router ospf WANCORE area 0.0.0.0
router ospf WANCORE
router-id 10.0.0.1


---------------------------


hostname S4
!
feature ospf
feature vn-segment-vlan-based
feature nv overlay
!
vlan 10
vn-segment 1000010
!
vrf context HOSTSIM
address-family ipv4 unicast
vrf context management
interface nve1
no shutdown
source-interface loopback0
member vni 1000010
ingress-replication protocol static
peer-ip 10.0.0.1
!
interface Ethernet1/1
no switchport
ip address 10.3.4.4/24
ip ospf network point-to-point
ip router ospf WANCORE area 0.0.0.0
no shutdown
!
interface Ethernet1/2
no switchport
ip address 10.2.4.4/24
ip ospf network point-to-point
ip router ospf WANCORE area 0.0.0.0
no shutdown
!
interface Ethernet1/4
no switchport
vrf member HOSTSIM
ip address 192.168.100.4/24
no shutdown
!
interface Ethernet1/5
switchport access vlan 10
spanning-tree port type edge
!
interface loopback0
ip address 10.0.0.4/32
ip ospf network point-to-point
ip router ospf WANCORE area 0.0.0.0
icam monitor scale
router ospf WANCORE
router-id 10.0.0.4
log-adjacency-changes

all ospf neighbors up, lo0 to lo0 pingable - vni looks up with `show nve vni`

thoughts?

 

(note: the hosts are simulated by looping eth1/4 to 1/5 through an unmanaged switch / logical hub - one interface is a vlan access one is a L3 interface in a different vrf so not part of global routing table)

2 Replies 2

hrtendrupUCM
Level 1
Level 1

Hello,

Thanks for the feedback; however, I don't think multicast is required (for this implementation). Even the first part of the link you posted discusses setting up static vxlan tunnels with unicast.

So, I reconfigured the CML to use the Alpine-Linux as hosts instead of simulating them with the switch itself and the static tunnels started working. I think it has to do with how the vxlan packets get decapsulated. When the vxlan packet reaches the remote VTEP and decapsulates the payload frame, the dst MAC is owned by the supervisor/ctrl plane so the forwarding gets balled up. Thats my theory. Things actually work as I expec them to after switching to proper simulated hosts instead of simulating a host on the same virtual gizmo that is already decapsulating vxlan packets

hrtendrupUCM_0-1725984001175.png

revised topology and attached lab config (node configs contained inside ~yaml.txt)