[c-nsp] 1. Spantree .1Q packets received on non-trunk port. (Lee Starnes)

Wed Aug 27 04:34:11 EDT 2014

Hi, 

I guess if is an access port you shouldn¹t need incoming BPDUs, so you can
easily turn off spanning tree for that VLAN on that port.

interface fastethernet0/3

no spanning tree vlan 638

BR

Matteo 

On 27.08.14 06:10, "cisco-nsp-request at puck.nether.net"
<cisco-nsp-request at puck.nether.net> wrote:

>Send cisco-nsp mailing list submissions to
>	cisco-nsp at puck.nether.net
>
>To subscribe or unsubscribe via the World Wide Web, visit
>	https://puck.nether.net/mailman/listinfo/cisco-nsp
>or, via email, send a message with subject or body 'help' to
>	cisco-nsp-request at puck.nether.net
>
>You can reach the person managing the list at
>	cisco-nsp-owner at puck.nether.net
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of cisco-nsp digest..."
>
>
>Today's Topics:
>
>   1. Spantree .1Q packets received on non-trunk port. (Lee Starnes)
>   2. Re: ME3600 BFD flapping (Waris Sagheer (waris))
>   3. Re: OMG! ME3600 does not automatically copy DSCP into COS and
>      also does not automatically copy EXP into COS T-T
>      (Waris Sagheer (waris))
>   4. Re: Spantree .1Q packets received on non-trunk port. (Lee Starnes)
>   5. Re: Spantree .1Q packets received on non-trunk port.
>      (Brielle Bruns)
>   6. Re: MPLS to Customer (Option B) / Multiple VRFs on CPEs
>      (Waris Sagheer (waris))
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Tue, 26 Aug 2014 16:32:34 -0700
>From: Lee Starnes <lee.t.starnes at gmail.com>
>To: "cisco-nsp at puck.nether.net" <cisco-nsp at puck.nether.net>
>Subject: [c-nsp] Spantree .1Q packets received on non-trunk port.
>Message-ID:
>	<CAJH8Oby2WZG1QWk=ANuWtjsnja4XvN8tf5h7t1i79SruF7rxSw at mail.gmail.com>
>Content-Type: text/plain; charset=UTF-8
>
>Hello,
>
>Been fighting with a carrier about a problem that we are seeing that I
>have
>not been able to get resolved. They are handing off an Metro-E circuit at
>one of our remote sites and they are providing an "access" port for us.
>This is "un-tagged" traffic at the remote site and tagged at our NNI. I
>can
>plug in a laptop to this port at the remote site and pass traffic all the
>way through our NNI. However, if I connect a cisco switch to it with the
>port on the cisco configured as an access port, I get the error below.
>
>00:06:52: %SPANTREE-7-RECV_1Q_NON_TRUNK: Received 802.1Q BPDU on non trunk
>FastEthernet0/3 VLAN638.
>00:06:52: %SPANTREE-7-BLOCK_PORT_TYPE: Blocking FastEthernet0/3 on
>VLAN0638. Inconsistent port type.
>
>Now this happens on a cisco ME3400, an 2950, and 3750g. Is there something
>that I am doing wrong? The config is as follows on the ME and 2950. Swap
>out the fastethernet for gigabit.
>
>!
>interface fastethernet0/3
>switchport mode access
>switchport access vlan 638
>!
>interface vlan 638
>ip address 10.20.30.40 255.255.255.0
>!
>ip default-gateway 10.20.30.1
>!
>
>-Lee
>
>
>------------------------------
>
>Message: 2
>Date: Wed, 27 Aug 2014 00:08:27 +0000
>From: "Waris Sagheer (waris)" <waris at cisco.com>
>To: jure brkljacic <zblajhani at gmail.com>, Jon Harald Bovre
>	<ccie at bovre.no>
>Cc: "cisco-nsp at puck.nether.net" <cisco-nsp at puck.nether.net>
>Subject: Re: [c-nsp] ME3600 BFD flapping
>Message-ID: <D0226EF5.B5617%waris at cisco.com>
>Content-Type: text/plain; charset="iso-8859-1"
>
>Jure,
>Do you have a class in your policy to classify prec 6 and 7 traffic and
>allocate 5% of bandwidth?
>
>Best Regards,
>
>[http://www.cisco.com/web/europe/images/email/signature/horizontal06.jpg]
>
>Waris Sagheer
>Technical Marketing Manager
>Service Provider Access Group (SPAG)
>waris at cisco.com<mailto:waris at cisco.com>
>Phone: +1 408 853 6682
>Mobile: +1 408 835 1389
>
>CCIE - 19901
>
>
><http://www.cisco.com/>
>
>
>
>This email may contain confidential and privileged material for the sole
>use of the intended recipient. Any review, use, distribution or
>disclosure by others is strictly prohibited. If you are not the intended
>recipient (or authorized to receive for the recipient), please contact
>the sender by reply email and delete all copies of this message.
>
>For corporate legal information go
>to:http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>
>
>
>From: jure brkljacic <zblajhani at gmail.com<mailto:zblajhani at gmail.com>>
>Date: Tuesday, August 26, 2014 at 6:29 AM
>To: Jon Harald Bovre <ccie at bovre.no<mailto:ccie at bovre.no>>
>Cc: "cisco-nsp at puck.nether.net<mailto:cisco-nsp at puck.nether.net>"
><cisco-nsp at puck.nether.net<mailto:cisco-nsp at puck.nether.net>>
>Subject: Re: [c-nsp] ME3600 BFD flapping
>
>Hi,
>
>We have BDF sessions enabled on VLAN (SVI interfaces) and no ip redirects
>command is configured
>
>Br Jure
>
>
>On Tue, Aug 26, 2014 at 3:21 PM, Jon Harald Bovre
><ccie at bovre.no<mailto:ccie at bovre.no>> wrote:
>
>We have seen missing 'no ip redirects' on the interface to cause problems.
>In addition to too agressive timers om radio and serial links.
>
>Jon Harald B?vre
>------------------------------
>Fra: jure brkljacic <zblajhani at gmail.com<mailto:zblajhani at gmail.com>>
>Sendt: 26.08.2014 14:03
>Til: cisco-nsp at puck.nether.net<mailto:cisco-nsp at puck.nether.net>
>Emne: [c-nsp] ME3600 BFD flapping
>
>Hi,
>
>We have a huge problems with BFD flapping on ME3600.It`s random event on
>two 3600 connected to the "same" end system.
>
>a.) First we thought that interface output drops causing BFD flapping.Than
>we configure a
>      a output queue policy to eliminate interface output drops. BFD
>flapping still there :(
>
>Code running:me360x-universalk9-mz.153-3.S3
>Number of BFD sessions: ~35
>timers:150 multiplier 3
>CPU:~10%
>
>Any help will be greatly appreciated.
>_______________________________________________
>cisco-nsp mailing list
>cisco-nsp at puck.nether.net<mailto:cisco-nsp at puck.nether.net>
>https://puck.nether.net/mailman/listinfo/cisco-nsp
>archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>_______________________________________________
>cisco-nsp mailing list
>cisco-nsp at puck.nether.net<mailto:cisco-nsp at puck.nether.net>
>https://puck.nether.net/mailman/listinfo/cisco-nsp
>archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>
>------------------------------
>
>Message: 3
>Date: Wed, 27 Aug 2014 00:25:51 +0000
>From: "Waris Sagheer (waris)" <waris at cisco.com>
>To: PlaWanSai RMUTT CPE IX <pws_admin at thaicpe.com>,
>	"cisco-nsp at puck.nether.net" <cisco-nsp at puck.nether.net>
>Subject: Re: [c-nsp] OMG! ME3600 does not automatically copy DSCP into
>	COS and also does not automatically copy EXP into COS T-T
>Message-ID: <D022731C.B562A%waris at cisco.com>
>Content-Type: text/plain; charset="us-ascii"
>
>This does not seem to be the DSCP/EXP value copy issue. Customer COS
>value should not be touched. Let me get back to you on this.
>
>Best Regards,
>
>[http://www.cisco.com/web/europe/images/email/signature/horizontal06.jpg]
>
>Waris Sagheer
>Technical Marketing Manager
>Service Provider Access Group (SPAG)
>waris at cisco.com<mailto:waris at cisco.com>
>Phone: +1 408 853 6682
>Mobile: +1 408 835 1389
>
>CCIE - 19901
>
>
><http://www.cisco.com/>
>
>
>
>This email may contain confidential and privileged material for the sole
>use of the intended recipient. Any review, use, distribution or
>disclosure by others is strictly prohibited. If you are not the intended
>recipient (or authorized to receive for the recipient), please contact
>the sender by reply email and delete all copies of this message.
>
>For corporate legal information go
>to:http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>
>
>
>From: PlaWanSai RMUTT CPE IX
><pws_admin at thaicpe.com<mailto:pws_admin at thaicpe.com>>
>Date: Sunday, August 24, 2014 at 7:40 PM
>To: "cisco-nsp at puck.nether.net<mailto:cisco-nsp at puck.nether.net>"
><cisco-nsp at puck.nether.net<mailto:cisco-nsp at puck.nether.net>>
>Subject: [c-nsp] OMG! ME3600 does not automatically copy DSCP into COS
>and also does not automatically copy EXP into COS T-T
>
>Hi all,
>
>I found the problem my customer's TOS is rewritten.
>Topology:
>Tester1 (Send CoS=5) -- Gi0/0/1/0 ASR9k 0/0/1/0.3604 -- xconnect --- Gi0/9
>ME-3600X Gi0/24 -- Gi0/14 ME-3400 Gi0/5 -- Tester2 (rx CoS=0)
>
>I open the TAC both ASR and ME Switch Team and this is the answer from ME
>Switch Team:
>
>ME3600 does not automatically copy DSCP into COS and also does not
>automatically copy EXP into COS as described in the following document
>which
>was presented on Cisco Live event (page 44 and 45):
>http://d2zmdbbm9feqrf.cloudfront.net/2012/usa/pdf/BRKSPG-2209.pdf
>
>Solution:
>Please configure policy-map on interfaces to set a proper COS value basing
>on incoming DSCP.
>
>I bought ME-3600 about 100 for use as PE. T-T
>
>Thank you very much.
>
>_______________________________________________
>cisco-nsp mailing list
>cisco-nsp at puck.nether.net<mailto:cisco-nsp at puck.nether.net>
>https://puck.nether.net/mailman/listinfo/cisco-nsp
>archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>
>
>------------------------------
>
>Message: 4
>Date: Tue, 26 Aug 2014 18:34:37 -0700
>From: Lee Starnes <lee.t.starnes at gmail.com>
>To: Mike Hale <eyeronic.design at gmail.com>
>Cc: "cisco-nsp at puck.nether.net" <cisco-nsp at puck.nether.net>
>Subject: Re: [c-nsp] Spantree .1Q packets received on non-trunk port.
>Message-ID:
>	<CAJH8ObyHre-uOR6vHzeSiYV+YHtM2=_2XhnneQhAf_=cJOhoUw at mail.gmail.com>
>Content-Type: text/plain; charset=UTF-8
>
>Thanks Mike.
>
>That took care of the problem, but still not sure why I would have to set
>the port up as a trunk port when the handoff is an access port. When the
>carrier tested the port, they tested it as an access port and then tried
>to
>test it as a trunk port and their test set failed when in trunk mode. Very
>odd.
>
>Anyway, thanks again.
>
>
>On Tue, Aug 26, 2014 at 4:59 PM, Mike Hale <eyeronic.design at gmail.com>
>wrote:
>
>> Have you tried turning it into a trunk port and defining 638 as the
>>native
>> vlan?
>>
>> I know it doesn't solve the underlying problem of them not giving you
>> an access port, but it should bring up the interface and let traffic
>> flow (unless their interface is truly trunked without the native vlan
>> config).
>>
>> On Tue, Aug 26, 2014 at 4:32 PM, Lee Starnes <lee.t.starnes at gmail.com>
>> wrote:
>> > Hello,
>> >
>> > Been fighting with a carrier about a problem that we are seeing that I
>> have
>> > not been able to get resolved. They are handing off an Metro-E
>>circuit at
>> > one of our remote sites and they are providing an "access" port for
>>us.
>> > This is "un-tagged" traffic at the remote site and tagged at our NNI.
>>I
>> can
>> > plug in a laptop to this port at the remote site and pass traffic all
>>the
>> > way through our NNI. However, if I connect a cisco switch to it with
>>the
>> > port on the cisco configured as an access port, I get the error below.
>> >
>> > 00:06:52: %SPANTREE-7-RECV_1Q_NON_TRUNK: Received 802.1Q BPDU on non
>> trunk
>> > FastEthernet0/3 VLAN638.
>> > 00:06:52: %SPANTREE-7-BLOCK_PORT_TYPE: Blocking FastEthernet0/3 on
>> > VLAN0638. Inconsistent port type.
>> >
>> > Now this happens on a cisco ME3400, an 2950, and 3750g. Is there
>> something
>> > that I am doing wrong? The config is as follows on the ME and 2950.
>>Swap
>> > out the fastethernet for gigabit.
>> >
>> > !
>> > interface fastethernet0/3
>> > switchport mode access
>> > switchport access vlan 638
>> > !
>> > interface vlan 638
>> > ip address 10.20.30.40 255.255.255.0
>> > !
>> > ip default-gateway 10.20.30.1
>> > !
>> >
>> > -Lee
>> > _______________________________________________
>> > cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> > https://puck.nether.net/mailman/listinfo/cisco-nsp
>> > archive at http://puck.nether.net/pipermail/cisco-nsp/
>>
>>
>>
>> --
>> 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
>>
>
>
>------------------------------
>
>Message: 5
>Date: Tue, 26 Aug 2014 20:55:19 -0600
>From: Brielle Bruns <bruns at 2mbit.com>
>To: cisco-nsp at puck.nether.net
>Subject: Re: [c-nsp] Spantree .1Q packets received on non-trunk port.
>Message-ID: <53FD4897.3000605 at 2mbit.com>
>Content-Type: text/plain; charset=windows-1252; format=flowed
>
>On 8/26/14 7:34 PM, Lee Starnes wrote:
>> Thanks Mike.
>>
>> That took care of the problem, but still not sure why I would have to
>>set
>> the port up as a trunk port when the handoff is an access port. When the
>> carrier tested the port, they tested it as an access port and then
>>tried to
>> test it as a trunk port and their test set failed when in trunk mode.
>>Very
>> odd.
>>
>> Anyway, thanks again.
>>
>
>
>Aren't BPDU's normally part of STP's chatter?
>
>I get errors like that when my MSTP instance settings are mismatched
>between switches.   Perhaps its a mix of issues.
>
>
>-- 
>Brielle Bruns
>The Summit Open Source Development Group
>http://www.sosdg.org    /     http://www.ahbl.org
>
>
>------------------------------
>
>Message: 6
>Date: Wed, 27 Aug 2014 04:10:43 +0000
>From: "Waris Sagheer (waris)" <waris at cisco.com>
>To: James Bensley <jwbensley at gmail.com>, "cisco-nsp at puck.nether.net"
>	<cisco-nsp at puck.nether.net>
>Subject: Re: [c-nsp] MPLS to Customer (Option B) / Multiple VRFs on
>	CPEs
>Message-ID: <D022A763.B5665%waris at cisco.com>
>Content-Type: text/plain; charset="us-ascii"
>
>James,
>ASR9K has mpls urpf support. We are planning to support the same on
>ASR920 and ASR903 RSP2.
>http://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k_r4-3/m
>pls/configuration/guide/b_mpls_cg43xasr9k/b_mpls_cg43asr9k_chapter_011.htm
>l#task_19C44FE6D33F4F8BADAF64614C1DB339
>
>MPLS uRPF and proper control plane authentication should be able to
>address your concerns. I think Autonomic Networking will also help since
>it builds secure channel  infrastructure.
>
>Best Regards,
>
>[http://www.cisco.com/web/europe/images/email/signature/horizontal06.jpg]
>
>Waris Sagheer
>Technical Marketing Manager
>Service Provider Access Group (SPAG)
>waris at cisco.com<mailto:waris at cisco.com>
>Phone: +1 408 853 6682
>Mobile: +1 408 835 1389
>
>CCIE - 19901
>
>
><http://www.cisco.com/>
>
>
>
>This email may contain confidential and privileged material for the sole
>use of the intended recipient. Any review, use, distribution or
>disclosure by others is strictly prohibited. If you are not the intended
>recipient (or authorized to receive for the recipient), please contact
>the sender by reply email and delete all copies of this message.
>
>For corporate legal information go
>to:http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>
>
>
>From: James Bensley <jwbensley at gmail.com<mailto:jwbensley at gmail.com>>
>Date: Tuesday, August 26, 2014 at 1:56 AM
>To: "cisco-nsp at puck.nether.net<mailto:cisco-nsp at puck.nether.net>"
><cisco-nsp at puck.nether.net<mailto:cisco-nsp at puck.nether.net>>
>Subject: [c-nsp] MPLS to Customer (Option B) / Multiple VRFs on CPEs
>
>Hi All,
>
>I know this has been discussed before (more on the NANOG list) but
>what are people doing regarding MPLS down to the CPE?
>
>Even though we own our CPEs and customers typically don't have access
>to them (or perhaps restricted show commands) it is a security concern
>that customers can send labelled packets back into the network if we
>enable MPLS on the CE facing interface on our PE. There is also the
>concern of route injection but I believe that risk can be removed by
>enabling MD5 on BGP and LDP sessions between CE and PE.
>
>(i) My first idea was uRPF, on the 12000 routers it seems that uRFP
>can inspect MPLS;
>
>>From : 
>>http://www.cisco.com/c/en/us/td/docs/ios/12_0s/feature/guide/srpf_gsr.htm
>>l
>"All Layer 2 encapsulation and transport types are supported,
>including ATM AAL5, ATM cell relay, Ethernet (VLAN and port modes),
>Frame Relay, HDLC, and PPP over MPLS; for more information, refer to
>Any Transport over MPLS."
>...
>"Although the Unicast RPF in Strict Mode feature filters only IPv4
>packets in IP or MPLS traffic, you can configure IOS software features
>that manage other traffic on the same interface, such as IP
>forwarding, MPLS features, Frame Relay switching, ATM switching, and
>Any Transport over ATM (AToM) connections. However, Unicast RPF
>filtering is only applied to incoming traffic on IP routing interfaces
>and not on packets processed by Frame Relay or ATM switching or
>transmitted over AToM pseudowire commendations."
>
>We aren't using 12000 though; At the access layer we're using
>ME3600/ME3800/6500/7600/ASR1K and we're looking at 6880-X to remove
>the smaller access layer 6504/6505/7604/7607 type chassis. I can't
>find any indication that any of those can support MPLS in uRPF so I
>think that idea is useless unless someone else can show me some
>contradictory information?
>
>(ii) My second idea was label value range restrictions
>
>Since the average CPE may have 3-5 VRFs on it with say 10 routes in
>each we could perhaps fiddle with the label allocation rules by
>setting 1000-1999 to be the usable range at PoP A, and 2000-2999 at
>PoP B and so on. We can restrict the routes that enter the LFIB at the
>PEs and which ones get labels allocated to them. Techniques like this
>reduce the surface area of potential attack and make it difficult to
>send in packets with a valid label (or label stack) but they seem more
>like security through obscurity to me.
>
>(iii) Additional options...
>
>I'm all ears! Is anyone running MPLS to the customer rather than
>multiple option A perings to each CPE? When we do large roll outs of
>1000 CPEs with each CPE having a minimum of 3 and maximum of ~10 VRFs
>we end up having thousands of peerings. MPLS to the customer really
>would be a lot simpler for config generation, automation, monitoring
>etc (also when we want PWE3/AToM) between two CPEs at different
>sites).
>
>Cheers,
>James.
>_______________________________________________
>cisco-nsp mailing list
>cisco-nsp at puck.nether.net<mailto:cisco-nsp at puck.nether.net>
>https://puck.nether.net/mailman/listinfo/cisco-nsp
>archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>
>
>------------------------------
>
>Subject: Digest Footer
>
>_______________________________________________
>cisco-nsp mailing list
>cisco-nsp at puck.nether.net
>https://puck.nether.net/mailman/listinfo/cisco-nsp
>
>------------------------------
>
>End of cisco-nsp Digest, Vol 141, Issue 46
>******************************************