Comware

Hi guys!

I have a problem with EVI. The thing is, I have configured it succesfully and hosts in the extended VLAN can excahnge traffic between datacenters. The problem is that switches don't learn mac-addresses of their neighbors in extended VLAN. For it to be more clear, the topology is like this:

NetA---SwitchA ---- SwitchB---NetB

The NetA and NetB are the same VLAN network. Hosts in NetA and NetB exchange traffic. But when host from NetB tries to ping or somehow access the VLAN interface on SwitchA it do fails. It could be not a big problem, however, SwitchA and SwitchB also perform OSPF routing, so when SwitchA receives packet destined to host in NetB it can't forward it - or probably can, but return packet is dropped.

If to look to display evi isis local-mac/remote-mac it is seen that both SwitchA and SwitchB learn mac-addresses in their corresponding networks, however they do not add theit own mac-address to EVI ISIS process, which results in the situation described above (at least I think so). I tried enabling the flooding on EVI tunnel interfaces and still no use of it.

Such topology should work, as it is described for example here:

http://h20195.www2.hp.com/V2/getpdf.aspx/4AA5-6737ENW.pdf?ver=2.0 - Deploying Ethernet Virtual Interconnect

Probably, someone can advise me how to enable own mac-address advertisements. If some logs or configurations of mine are needed, please ask.

Thanks in advance!

For me to be probably more clear.

(HostA)NetA---SwitchA ---- SwitchB---NetB(HostB)

So, there are two extended vlans 10 and 20 for example. Both switchA and switchB perfrom as default gateways for both these VLANs using VRRP.

SwitchA:

interface Vlan-interface10
 ip address 192.168.10.2 255.255.255.0
 vrrp vrid 10 virtual-ip 192.168.10.1
#
interface Vlan-interface20
 ip address 192.168.20.2 255.255.255.0
 vrrp vrid 20 virtual-ip 192.168.20.1

interface Tunnel1 mode evi
 evi flooding enable
 evi extend-vlan 10 to 20
 source LoopBack0
 evi network-id 1
 evi neighbor-discovery server enable
 evi neighbor-discovery client enable 1.1.1.1

SwitchB:

interface Vlan-interface10
 ip address 192.168.10.3 255.255.255.0
 vrrp vrid 10 virtual-ip 192.168.10.1
#
interface Vlan-interface20
 ip address 192.168.20.3 255.255.255.0
 vrrp vrid 20 virtual-ip 192.168.20.1

interface Tunnel1 mode evi
 evi flooding enable
 evi extend-vlan 10 to 20
 source LoopBack0
 evi network-id 1
 evi neighbor-discovery server enable
 evi neighbor-discovery client enable 1.1.1.2

HostA resides in vlan10 and hostB resides in vlan20, so default gateway for one of them is switchA and for another - switchB, both having VRRP master addresses on both vlans. When HostA(e.g. 192.168.10.100) tries to reach HostB(192.168.20.200) he fails. So, practically, the situation is, that SwitchA receives a frame that should be routed from directly connected vlan10 to directly connected vlan20, but the reason is that the hostB (vlan20) is located on the other side of the evi tunnel and switchA should forward the frame directly through it, but it fails for some reason.

The same thing works for not directly connected vlans - I've tried to ping some hosts that reside behind switchA (through OSPF, not the part of the EVI) from the hostB and the ping also fails. I've run the tcpdump on that remote host and can see request and response packets, so the communication fails somewhere on switchA/switchB.

P.S. I thought a little bit further and it could be not due to inability to learn the neighbors mac-address, practically it would result only in inability to ping non-vrrp address on the neighbor interface, which is not so critical... I would think that it might be due to reverse-path forwarding but it is globally disabled on the device (at least dis ip urpf show nothing). Plus I don't know how using EVI might affect it.

Hi all!

So, in order to not to leave the Fermat's post, the solution has been found. It was found, that different HPE devices have, let's say, quite a different implemetation of EVI. I have the 7900 switches in my case with FX modules. It is important though, because EVI has problems with other module types - I have found the doc describing it somewhere on HPE site, but now can't.

So, the solution to set up EVI (if you also need routing/VRRP on the same switch) on the 7900 switches is to create a separate MDC for routing and use EVI on the default (Admin) MDC. So you'll get two separate logical devices, one will perform EVI and the other will perform routing and so on. You can find some info here:

http://h20195.www2.hp.com/V2/getpdf.aspx/4AA5-6480ENW.pdf

Another awful thing was the EVI docs for 7900 switches. It really explains nothing - so it is written in a way like "if you want to configure EVI enter this commands". And there are some unobvious things in EVI configuration - and I've found explanation for them in 6602 Routers docs, so I would recommend using it.

The most unobvious thing is enabling evi on the physical interface. In 7900 doc it is stated that you must enable it on the physical interface from which the EVI tunnel is built. Hovewer, in the real world, if you connect to different EVI sites (especially the ones, facing each other through L2 as I have) you must not enable it. Evi enable command on physical interface should be configured when you configure link between two evi devices on the same site. So if you enable it on the different sites facing each other through L1/L2 you'll get the site-id conflict and still the doc for 7900 switch would say that you have to enable it. Ridiculous.

The same thing is regarding "evi designated-vlan" command. It is not even present in the doc for 7900! However, it is in 6602 doc. So, what it does? Practically, the same, that "evi enable" - it designates a vlan, which should be used by two same-site devices to communicate the evi information. So, again if you have two L2-facing sites, you might get wrong and get a site-id conflict again. What is the most funny thing, that this command does have the default value. So, the default value for evi designated vlan is "1". And think what? If you have (you should almost surely have) trunk or hybrid interface between your two sites (if you have L2, as I have already mentioned) and forget or even contiously leave vlan 1 enabled on it (as best-practice guides advise, AFAIK) you'll also get that site-id conflict.

So i've got two L2-facing sites and there will be the third, over L3 in the near future. This is the reason to use EVI (as well as more efficient traffic paths using VRRP) and not just tag the VLANs through L2, if someone asks why did i configure it at all.

Hope this info will be helpful for someone.

P.S. And thanks for HPE guys who pointed me to right docs to undesrstand what is going on and the differences in evi in 7900.