Tunneling CDP frames

[EtherMAN]

Best solutions out there to tunnel CDP in a mixed Extreme network...

Edge is 150-460 summit running 12.6 to 15.6

Core is 670 or 8900 MSM 128 running 15.4 - 15.6

Some support L2PT and some do not. I think what I need to do is build a counter profile to see where the CDP are failing and then build the tunnel there for the vlans I need to forward cdp

Here is what I am using for this which when applied to specific vlan on edge uni port works or to trunk port on next hop works. Problem is this going to be a big tasks to go through 100 plus vlans one segment at a time to find the blocking points.

entry cdp_pdu {if {
ethernet-destination-address 01:00:0c??cc:cc ;
snap-type 0x2000 ;
} then {
count cdp_ingress ;
}
}

Another question is when did replace-ethernet-destination-add get added to the image and made active. I have not found a version of code that supports this statement yet. I guess it is not needed on switches that support L2PT profiles?

Problem started when we started updating code from 12.6 to 15.xx it seemed CDP started being blocked and not passing through the network.

Thanks ahead of time

[EtherMAN]

Better explaination.. Still have questions. This only works on vmans and not vlans???? Looks like it has to be done edge to edge so I would guess it we would need to have edge switches updated to support l2pt tunnels and you apply the filter to the untagged port at the edge? Will not work if cdp is on a tagged frame where edge is passing frame through a tagged port to a core switch that blocks it due to being 15.4 or newer code? Have verified this with cdp counter acls that our newer core switches are the ones blocking the cdp frames even though they are arriving as a tagged frame.

[Prashanth_KG]

Link updated with the sample configuration,

https://gtacknowledge.extremenetworks.com/articles/Solution/Layer-two-layer-2-protocol-packets-does-...

Please let us know if that helps!

[Prashanth_KG]

Hi Andreas,

I am going to jump into the quick answer below and try to reduce the frustration this is causing already.

For allowing the CDP packets, EXOS has a default filter already created.

conf l2pt profile "allowcdp" add protocol filter

Protocol filter name
"ANY" "appletalk" "cdp" "decnet" "dtp"
"edp" "IP" "IPv6" "ipx" "ipx_8022"
"ipx_snap" "lacp" "lldp" "mpls" "netbios"
"pagp" "stp" "udld" "vtp"

So, there is no need to define an additional filter. By modifying or creating one, EXOS recognises this as a new user defined filter and hence was expecting a destination address.

Following are the sample configuration commands that needs to be configured on the VMAN switches:

- create l2pt profile
- configure l2pt profile add protocol filter cdp action tunnel
- configure vman ports l2pt profile

I am working on editing the article. Will post the updated link.

Hope this helps!

[andreas1]

This is freaking hilarious. I have recently upgrade to 15.6.1.3 Trying the workaround described in https://gtacknowledge.extremenetworks.com/articles/Solution/Layer-two-layer-2-protocol-packets-does-not-pass-though-the-VMAN-tunnel-after-upgrade-of-EXOS Gives me the following error. Slot-1 L460.1 # show configuration | inc cdp create protocol filter "cdp" configure protocol filter "cdp" add snap 0x2000 Slot-1 L460.2 # create l2pt profile Allow-cdp * Slot-1 L460.3 # configure l2pt profile "Allow-cdp" add protocol filter "cdp" action tunnel Error: The protocol filter "cdp" is incompatible with L2PT since the protocol filter entry "Protocol id 0x2000 (SNAP)" does not specify a destination address. So the article needs to be updated. ...... Btw I'm making a case of this cause right now this sucks so hard.

[Prashanth_KG]

Regarding replace-ethernet-destination address attribute, I believe it is related to the hardware and not the software.
We need not use this attribute if the EXOS supports l2tp profile.