ASR9000/XR: How is CDP handled in L2 and L3 scenarios

[xthuijs]

Introduction

This document provides for a couple of examples as to how untagged L2 protocols like CDP, BPDU's, VTP, LACP etc are treated in

L2 or L3 scenarios on the ASR9000.

Core Issue

Because the ASR9000 follows the EVC model for L2 connections, the handling of L2 adjacency related traffic works a bit different then what one might be used to from the 7600 or IOS based platforms. In XR/ASR9000 some changes to this behavior have been made on a per protocol basis, which will

be discussed in this document.

Resolution

Topology used for this example and verification:

When “7200” is sending cdp to the ASR9000 and ... :

Scenarios:

1) the 9k "BOT" has cdp enabled on its main interface then you’ll establish a cdp relation between “7200” and “9k-BOT”. No untagged EFP defined on the respective interfaces.

2) the 9k BOT does not have cdp enabled on its main interface AND you have an untagged EFP defined on the 9k which is put in a xconnect for instance connecting g0/1/0/14 to te 0/4/0/1 on ASR9K-BOT, THEN “7200” will establish a cdp relationship with “ASR9K-TOP”: the CDP packets are transported over the XCON.

3) the 9k BOT has cdp enabled on its main interface AND you have an untagged EFP defined but this EFP is not put in a BD or XCON, then the 7200 sees BOT as its neighbor, and:

    a) If your XR version is 4.2.0 or before then:

     9K-BOT doesn’t see any neighbor (received cdp packets are transported or consumed by the EFP) and

     9K-TOP doesn’t see anyone as there is no xconnect to transport the CDP Packets over, yet EFP is defined.

    b) If your XR version 4.2.1, 4.2.3, 4.3.0 or newer then:

    Eventhough there is an untagged EFP present, the CDP packets in the presence of a local cdp configuration are peeled out of the untagged EFP

    and will not be subject to the EFP service definition..

4) and the 9k has cdp enabled on its main interface AND you have an untagged EFP defined, with has an xconnect to TOP then

    a) If your XR version is 4.2.0 or before then:

    the 7200 sees BOT AND TOP as its neighbor, 9K-BOT doesn’t see any neighbor (received cdppackets are transported or consumed by the EFP),

    and TOP sees 7200.

    b) If your XR version 4.2.1, 4.2.3, 4.3.0 or newer then:

    7200 sees BOT and TOP as neighbors (xconnect present and no CDP configured on TE0/4/0/1 on BOT), BOT sees 7200 and TOP sees no one.

    TOP doesn't see anyone because there is no cdp configured on te 0/4/0/1 on BOT, and the cdp packets from 7200 are consumed locally.

In these cases 3 and 4 are inconsistent configurations of course.

The behavioral difference between releases prior to XR 4.2.1 and after is defined by CSCtg04453. This DDTS changes the handling of CDP

traffic only in relation to untagged EFP.

Associated Configurations

ASR9K-BOT configuration:

EFP to transport the untagged packets to the ASR9K-TOP

interface TenGigE0/4/0/1.1 l2transport
encapsulation untagged
!

To capture the CDP packets on to an EFP define this:

interface GigabitEthernet0/1/0/14.1 l2transport
encapsulation untagged
!

Main interface configuration facing the 7200. The "cdp" keyword here is present depending on the test cases above.

interface GigabitEthernet0/1/0/14
cdp
load-interval 30
!

Cross connect configuration

l2vpn

xconnect group cdp
  p2p cdp
   interface TenGigE0/4/0/1.1
   interface GigabitEthernet0/1/0/14.1
  !
!

ASR9K-TOP configuration:

interface TenGigE0/4/0/1
cdp
!

Debug and verification

Seen from ASR9K-TOP

LC/0/4/CPU0:Mar 22 17:42:58.746 : cdp[131]: Packet received from fp7200-6 (0003.a0fd.28a8) on interface TenGigE0/4/0/1
LC/0/4/CPU0:Mar 22 17:42:58.746 : cdp[131]: **Entry  found in cache**
LC/0/4/CPU0:Mar 22 17:42:58.746 : cdp[131]:   Received Port ID GigabitEthernet6/0

For CASE-4, whcih is the most interesting one, the output from 7200:

fp7200-6#sh cdp ne
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
                  S - Switch, H - Host, I - IGMP, r - Repeater

Device ID        Local Intrfce     Holdtme    Capability  Platform        Port ID
A9K-BOTTOM       Gig 6/0            139          R        ASR9K Seri   Gig 0/1/0/14
A9K-TOP.cisco.com
                            Gig 6/0            169          R        ASR9K Seri   TenGigE0/4/0/1

A9K-BOT doesn't see anyone as expected in case-4

RP/0/RSP1/CPU0:A9K-BOTTOM#sh cdp ne
Tue Mar 22 12:47:05.939 EST
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
                  S - Switch, H - Host, I - IGMP, r - Repeater

Device ID       Local Intrfce    Holdtme Capability Platform  Port ID
RP/0/RSP1/CPU0:A9K-BOTTOM#

Related Information

Are CDP, VTP and BPDU crossing an xconnect or bridge-domain (BD) ?

Yes they did, originally. Depending on release (lovely I know). The original behavior prior to XR 4.2.1 was that untagged traffic

regardless of local configuration was consumed by the untagged EFP. This is at times undesirable for especially STP and CDP also as seen above.

After XR 4.2.1 we made 2 changes to the logic for notably CDP and (M)STP BPDU's. If there is an untagged EFP present but the protocl is not configured locally, transport it as part of the untagged EFP service definition.

If the service is configured locally, as seen in the example above for cdp, then consume the packet locally and not transport it.

The ddts that changed the behavior for STP is CSCtx28089.

You can use:“ethernet filter dot1q” to drop the BPDUs from each side and keep them isolated from each other.

If not configured, the BPDUs will cross over and interfere with each other.

You can also use MAC based ACLs to prevent BPDUs/ CDPpackets from crossing over.

This example will filter PVST and MSTP packets on an L2 interface for specifically VLAN 100.

(note that PVST is vlan tagged BPDU's and MSTP are untagged BPDU's, so to filter MSTP packets

this ACL is to be applied to an interface with the "encapsulation untagged" keyword)

ethernet-services access-list L2ACL

5 remark Access-list for blocking PVST/MSTP BPDU's

10 deny any host 0100.0ccc.cccd

20 deny any host 0180.c200.0000

30 permit any any

!

interface TenGigE0/4/0/1.100 l2transport

encapsulation dot1q 100

ethernet-services access-group L2ACL ingress

!

Xander Thuijs, CCIE #6775

Principal Engineer ASR9000

[chatasos]

Hi Xander

What happens with CDP on l2transport interfaces? Why isn't that supported?

Especially now with the IRB functionality, l2transport interfaces look like simple l2 interfaces (no ACs there).

Regards,

Tassos

[xthuijs]

Hey Tassos!

CDP can't be used on a main interface that is marked as l2transport. That is because it is contradicting as to what should happen then with the cdp packets. E.g should we be l2transparent, consume them or inject our own.

In the scenario where we have cdp on a main interface that is not l2transparent, and a (set of) subinterfaces that is l2transparent, including an untagged interface we end up in 1 of the scenarios mentioned above (3 or 4).

Perhaps for your specific scenario LLDP might be something to consider?

regards

xander

[chatasos]

Unfortunately LLDP is not supported by all our other hardware. And it's not clear why LLDP should work, while CDP shouldn't. Aren't they both L2 discovery protocols? Why use different implementations?

This is probably another case where i see different handling of L2CPs between cisco devices.

ME-3400E supports it under the physical, ME-3800X needs an efp and l2protocol peer, 7600 supports it under the physical, ASR9k doesn't support it at all.

[Rajat Chauhan]

Hi Xander,

A very useful doc as always.

Can you please advise if its possible to tunnel LLDP across L2VPN on ASR using this as well ?

[yansenyansen]

thank You very much

[pavel.stefanov]

Hi Xander,

How does the "l2protocol cpsv tunnel" affect the tunnelling of CDP and STP and in the newer versions? Is the command required on an interface for these protocols to be tunnelled?

Thanks,

Pavel

[xthuijs]

if you have an untagged EFP then the CDP and bpdu's will follow the service associated with that EFP.

relative recent sw changes in 42 made it a bit more intelligent whereby if there is a local config for (M)STP, and eventhough there is an untagged EFP, the bpdu's will be peeled out and locally terminated.

so you dont need the cpsv config to transport control traffic.

an EFP that carries that control will transport this control traffic.

If this is undesirable (generally that is the case), you need either an L2ACL blocking that dMAC or use a local config

for STP to consume and terminate these bpdu's.

regards

xander

[Mark Pace Balzan]

Hi,

on asr9k with 5.2.4 I see the behavior above with cdp, ie if enabled locally on the interface then it is consumed and peered with the attached device even if an untagged efp is configured

what I also see and seems unexpected is that cdp enabled locally on the interface also overrides l2acl or ethernet filter dot1q.  Is this expected behaviour ?

It's getting a little bit confusing to me. Would appreciate any feedback

thanks

mark

[xthuijs]

In the going releases when a service is configured, the packet will get peeled out of the EFP.

that means that if you have cdp configured locally, we'll consume the CDP/STP. If you have an untagged EFP, then still they will get consumed, but if you unconfigure the local service THEN the these service packets (CDP/STP) will get forwarded as per EFP direction (vpls/vpws).

l2acl should be effective for EFP also.

xander

[ปลาวาฬทราย RMUTT CPE IX]

The CDP or LLDP packets are not transported over the XCON if use sub-interfaces with encapsulation dot1q, right?

Thank you very much.