This really sounds like it is an encapsulation issue. You can you try the following:
1. Remove "switchport vlan access" from port 24 on Switch 0 2. Remove the encapsulation command from Port-Channel 12 on Switch1 - Since this side is set to auto let the other switch make all the decisions. 3. On switch0 you can either remove the dot1q encapsulation from Port-Channel 12 or add it to ports 21-24. (depends on if you prefer ISL or dot1q) Thanks, Mark -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Thursday, December 13, 2012 9:00 AM To: [email protected] Subject: CCIE_RS Digest, Vol 83, Issue 19 Send CCIE_RS mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit http://onlinestudylist.com/mailman/listinfo/ccie_rs or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specific than "Re: Contents of CCIE_RS digest..." Today's Topics: 1. Re: TrunkLink Over EtherChannel (Christian Schroeder) 2. Re: TrunkLink Over EtherChannel (Sean Cook) 3. Re: Multicast over NBMA makes my brain hurt (Saleh) ---------------------------------------------------------------------- Message: 1 Date: Thu, 13 Dec 2012 08:55:55 +0100 From: Christian Schroeder <[email protected]> To: <[email protected]> Subject: Re: [OSL | CCIE_RS] TrunkLink Over EtherChannel Message-ID: <[email protected]> Content-Type: text/plain; charset=UTF-8; format=flowed Hi, I don`t think the protocols are mismatched. Quoting from the documentation: desirable Unconditionally enable PAgP. Desirable mode places a port into an active negotiating state in which the port starts negotiations with other ports by sending PAgP packets. A channel is formed with another port group in either the desirable or auto mode. When desirable is enabled, silent operation is the default. auto Enable the Port Aggregation Protocol (PAgP) only if a PAgP device is detected. Auto mode places a port into a passive negotiating state in which the port responds to PAgP packets it receives but does not start PAgP packet negotiation. A channel is formed only with another port group in desirable mode. When auto is enabled, silent operation is the default. Both sides use PAgP and the right switch (Switch0) initiates the creation of the channel. Looks perfectly legal for me besides the issue with fa0/24 as Imad pointed out already. Cheers, Christian > Date: Wed, 12 Dec 2012 08:16:44 -0700 > From: Sean Cook <[email protected]> > To: imad Abdallah <[email protected]> > Cc: "[email protected]" <[email protected]>, > waheed Ahmed <[email protected]> > Subject: Re: [OSL | CCIE_RS] TrunkLink Over EtherChannel > > Your protocols are mismatched. The etherchannel on switch 0 will > never come up as its trying to negotiate using PagP. Switch 1 is not > using any protocol. Match both sides and correct fa0/24 on switch 0. > > On 2012-12-12, at 7:41 AM, imad Abdallah <[email protected]> > wrote: > >> Why do you have fa0/24 defined as access port ? >> [...] >> >> On Dec 12, 2012, at 3:29 PM, "waheed Ahmed" <[email protected]> >> wrote: >> >>> Hi Guys, >>> >>> Am facing some problems related to VLAN and EtherChannel . >>> Configurations are mentioned below please guide me what i did wrong >>> with configurations:- >>> 1. Switch0 and attached VLAN is okay working well. >>> 2. EtherChannel on ports is okay and configured with Trunk >>> capabilities. >>> >>> Left Switch configuration(Switch1) [...] >>> interface FastEthernet0/21 >>> channel-group 12 mode auto >>> ! >>> interface FastEthernet0/22 >>> channel-group 12 mode auto >>> ! >>> interface FastEthernet0/23 >>> channel-group 12 mode auto >>> ! >>> interface FastEthernet0/24 >>> channel-group 12 mode auto [...] >>> Right Switch configuration(Switch0) [...] >>> interface FastEthernet0/21 >>> channel-group 12 mode desirable >>> ! >>> interface FastEthernet0/22 >>> channel-group 12 mode desirable >>> ! >>> interface FastEthernet0/23 >>> channel-group 12 mode desirable >>> ! >>> interface FastEthernet0/24 >>> channel-group 12 mode desirable >>> switchport mode access >>> ! [...] ------------------------------ Message: 2 Date: Thu, 13 Dec 2012 07:25:03 -0700 From: Sean Cook <[email protected]> To: Christian Schroeder <[email protected]> Cc: "[email protected]" <[email protected]> Subject: Re: [OSL | CCIE_RS] TrunkLink Over EtherChannel Message-ID: <[email protected]> Content-Type: text/plain; CHARSET=US-ASCII Sorry. You are correct. When I looked at this yesterday I had it in my head that switch 1 was configured as "on". Thanks for pointing that out. On 2012-12-13, at 12:55 AM, Christian Schroeder <[email protected]> wrote: > Hi, > > > I don`t think the protocols are mismatched. > Quoting from the documentation: > > desirable Unconditionally enable PAgP. > Desirable mode places a port into an active negotiating state in which the port starts negotiations with other ports by sending PAgP packets. > A channel is formed with another port group in either the desirable or auto mode. When desirable is enabled, silent operation is the default. > > auto Enable the Port Aggregation Protocol (PAgP) only if a PAgP device is detected. > Auto mode places a port into a passive negotiating state in which the port responds to PAgP packets it receives but does not start PAgP packet > negotiation. A channel is formed only with another port group in desirable mode. When auto is enabled, silent operation is the default. > > Both sides use PAgP and the right switch (Switch0) initiates the creation of the channel. Looks perfectly legal for me besides the > issue with fa0/24 as Imad pointed out already. > > > Cheers, > Christian > > >> Date: Wed, 12 Dec 2012 08:16:44 -0700 >> From: Sean Cook <[email protected]> >> To: imad Abdallah <[email protected]> >> Cc: "[email protected]" <[email protected]>, >> waheed Ahmed <[email protected]> >> Subject: Re: [OSL | CCIE_RS] TrunkLink Over EtherChannel >> >> Your protocols are mismatched. The etherchannel on switch 0 will >> never come up as its trying to negotiate using PagP. Switch 1 is not >> using any protocol. Match both sides and correct fa0/24 on switch 0. >> >> On 2012-12-12, at 7:41 AM, imad Abdallah <[email protected]> wrote: >> >>> Why do you have fa0/24 defined as access port ? >>> [...] >>> >>> On Dec 12, 2012, at 3:29 PM, "waheed Ahmed" <[email protected]> wrote: >>> >>>> Hi Guys, >>>> >>>> Am facing some problems related to VLAN and EtherChannel . Configurations are mentioned below please guide me what i did wrong with configurations:- >>>> 1. Switch0 and attached VLAN is okay working well. >>>> 2. EtherChannel on ports is okay and configured with Trunk capabilities. >>>> >>>> Left Switch configuration(Switch1) > [...] >>>> interface FastEthernet0/21 >>>> channel-group 12 mode auto >>>> ! >>>> interface FastEthernet0/22 >>>> channel-group 12 mode auto >>>> ! >>>> interface FastEthernet0/23 >>>> channel-group 12 mode auto >>>> ! >>>> interface FastEthernet0/24 >>>> channel-group 12 mode auto > > [...] > >>>> Right Switch configuration(Switch0) > [...] >>>> interface FastEthernet0/21 >>>> channel-group 12 mode desirable >>>> ! >>>> interface FastEthernet0/22 >>>> channel-group 12 mode desirable >>>> ! >>>> interface FastEthernet0/23 >>>> channel-group 12 mode desirable >>>> ! >>>> interface FastEthernet0/24 >>>> channel-group 12 mode desirable >>>> switchport mode access >>>> ! > [...] > > _______________________________________________ > For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com > > Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com > > http://onlinestudylist.com/mailman/listinfo/ccie_rs ------------------------------ Message: 3 Date: Thu, 13 Dec 2012 19:58:53 +0400 From: Saleh <[email protected]> To: Keller Giacomarro <[email protected]>, "IPExpert OSL, CCIE" <[email protected]> Subject: Re: [OSL | CCIE_RS] Multicast over NBMA makes my brain hurt Message-ID: <[email protected]> Content-Type: text/plain; charset="iso-8859-1" Hi keller Did you workout a solution for this issue? I am interested to know. -----Original Message----- From: Keller Giacomarro <[email protected]> Sent: Tuesday, 13 November, 2012 5:23 AM To: Baldwin, Patrick A. (MSFC-EO60)[HOSC SERVICES CONTRACT] <[email protected]> Cc: CCIE IPExpert OSL <[email protected]> Subject: Re: [OSL | CCIE_RS] Multicast over NBMA makes my brain hurt Hi all, Thanks for the information so far, been good to dig deep into this tech. Someone else recommended something -- add a loopback on your source router, enable it for PIM, create statics from the other two routers to get to it, and ping again. The (S,G) tree on the hub router still gets pruned off for the FR interface's source IP, but the (S,G) for the source's loopback interface is left in-tact. It sounds like what Patrick is saying -- even with spt-threshold set to infinity, the SPT switchover is still happening. And R2, thinking that its FR interface is a full-mesh multi-access interface, is sending a prune for R1 to stop sending it RP based traffic. R2's intention is to cut off the flow via the RPT and instead use the SPT. Except that in this case, there's no way for it to know that the source is only reachable via the RP. The solution seems to be to change the interface/IP structure. I am not currently seeing a way to ping with a source IP of the FR interface on R3 and get a response from any other spoke router on the FR cloud. They will all prune off their only connection to the stream (the hub), believing that they are doing SPT switchover. I will read the INE blog post and investigate further as well, but can anyone confirm or deny my thinking? Thanks! -Keller Keller Giacomarro [email protected] On Mon, Nov 12, 2012 at 4:45 PM, Baldwin, Patrick A. (MSFC-EO60)[HOSC SERVICES CONTRACT] <[email protected]> wrote: > > Keller, > > With certain topologies within PIM, it is not possible to prevent SPT > switchover, I believe your topology is one of those. > The article below covers this case and explains as well as possible that > PIM will automatically switchover in this case. > > http://blog.ine.com/2011/01/14/understanding-advanced-pim-shared-tree-design s/ > > Since you have configured the topology such that 2&3 cannot communicate > with each other directly, they cannot form a PIM neighbor relationship. > > Therefore the traffic will drop when PIM cuts over to the SPT. > > There are many ways to fix this, I suppose it just depends on what your > constraints are: > > P2P sub interfaces > add a new PVC and frame-relay map statements between 2&3 > use a GRE tunnel between 2&3 > Change the L3 assignments such that they are on different subnets > > Others smarter than me may have more to say on the subject.... > > > Hope that helps > > Patrick A Baldwin > > > > ________________________________________ > From: [email protected] [ > [email protected]] On Behalf Of Keller Giacomarro [ > [email protected]] > Sent: Monday, November 12, 2012 1:56 PM > To: Bal Birdy > Cc: CCIE IPExpert OSL > Subject: Re: [OSL | CCIE_RS] Multicast over NBMA makes my brain hurt > > Great input all, thanks so far! My configs above are from me re-doing the > scenario in 15.1. I've put it back into 12.4 (familiar territory), and > implemented your suggested changes. Same effect. > > * 12.4 Configs* > R1: http://pastebin.com/raw.php?i=sMdDzs4j > R2: http://pastebin.com/raw.php?i=uUXWippY > R3: http://pastebin.com/raw.php?i=HJqCGhgt > GNS: http://pastebin.com/raw.php?i=Fc8HpNyv > > Still seeing the same behavior. SPT-threshold is infinity on all devices. > All loopbacks are in PIM. > > I believe that R2 is the culprit. It is trying to do SPT-switchover (even > though it's disabled?!?), and is sending a PIM Prune towards the RP. That > just happens to be the same DLCI as the SPT takes. > > Evidence: > > ! Before ping > R2#show ip mroute 229.0.0.2 > (*, 229.0.0.2), 00:00:03/00:02:56, RP 1.1.1.1, flags: SCL > Incoming interface: Serial0/0, RPF nbr 10.0.0.1 > Outgoing interface list: > Loopback0, Forward/Sparse, 00:00:03/00:02:56 > > ! Ping from R3 happens now > R2# > *Mar 1 00:03:08.295: PIM(0): Insert (10.0.0.3,229.0.0.2) sgr prune in nbr > 10.0.0.1's queue > *Mar 1 00:03:08.303: PIM(0): Building Join/Prune packet for nbr 10.0.0.1 > *Mar 1 00:03:08.303: PIM(0): Adding v2 (10.0.0.3/32, 229.0.0.2), RPT-bit, > S-bit Prune > *Mar 1 00:03:08.307: PIM(0): Send v2 join/prune to 10.0.0.1 (Serial0/0) > > ! After ping from R3 > R2#show ip mroute 229.0.0.2 > (*, 229.0.0.2), 00:00:11/stopped, RP 1.1.1.1, flags: SCL > Incoming interface: Serial0/0, RPF nbr 10.0.0.1 > Outgoing interface list: > Loopback0, Forward/Sparse, 00:00:11/00:02:48 > > (10.0.0.3, 229.0.0.2), 00:00:03/00:02:59, flags: LJT > Incoming interface: Serial0/0, RPF nbr 0.0.0.0 > Outgoing interface list: > Loopback0, Forward/Sparse, 00:00:03/00:02:56 > > R2# > > While I know that we can use p2p subinterfaces, the lab I'm working > specifically uses the physical interfaces for all FR endpoints. Is there > any way to make this work? > > Thanks for everyone's input! > > -Keller > > Keller Giacomarro > [email protected] > > > On Mon, Nov 12, 2012 at 5:27 AM, Keller Giacomarro <[email protected] > >wrote: > > > It could...except it's not! > > > > (config) ip pim spt-threshold infinity > > > > has no effect. It does ACT like an SPT switchover. R2 seems to be > > telling R1, "stop sending me traffic from the RP, I'm using SPT now". > But > > since SPT is via that same interface and via R1, it is cutting off its > own > > SPT. > > > > For your full review, if you like... > > R1: http://pastebin.com/raw.php?i=cHFzBDEh > > R2: http://pastebin.com/raw.php?i=Dn6ATSPM > > R3: http://pastebin.com/raw.php?i=yEwnnc8y > > GNS3: http://pastebin.com/raw.php?i=A4MnALTq > > > > Configs and GNS3 are written for IOS 15.1. I have also tried this in > 12.4 > > with identical results. > > > > Note that I did this in GNS3 after I experienced the problem with my real > > equipment, so I do not believe this is a GNS3 problem. > > > > Thoughts appreciated! > > > > > > > > Keller Giacomarro > > [email protected] > > > > > > > > On Mon, Nov 12, 2012 at 4:56 AM, Bal Birdy <[email protected]> > wrote: > > > >> If the first ping gets through could this be spt switchover? > >> On Nov 12, 2012 8:03 PM, "Keller Giacomarro" <[email protected]> > wrote: > >> > >>> Okay, I must be totally missing the boat here, but I can't get > Multicast > >>> over NBMA to work AT ALL. > >>> > >>> R2-----\ > >>> -------- R1 > >>> R3-----/ > >>> > >>> All interfaces are physical interfaces with static ipv4 mappings. R1 > has > >>> DLCIs to both spoke routers, and spoke routers only have DLCIs to R1. > >>> This > >>> is as simple as I know how to get it. > >>> > >>> *** R1 *** > >>> interface Serial1/0 > >>> ip address 10.0.0.1 255.255.255.0 > >>> ip pim dr-priority 1000 > >>> ip pim nbma-mode > >>> ip pim sparse-mode > >>> encapsulation frame-relay > >>> frame-relay map ip 10.0.0.3 103 broadcast > >>> frame-relay map ip 10.0.0.2 102 broadcast > >>> no frame-relay inverse-arp > >>> ! > >>> interface Loopback0 > >>> ip address 1.1.1.1 255.255.255.0 > >>> ! > >>> ip pim rp-address 1.1.1.1 > >>> > >>> *** R2 *** > >>> interface Serial1/0 > >>> ip address 10.0.0.2 255.255.255.0 > >>> ip pim sparse-mode > >>> encapsulation frame-relay > >>> frame-relay map ip 10.0.0.3 201 > >>> frame-relay map ip 10.0.0.1 201 broadcast > >>> ! > >>> interface Loopback0 > >>> ip address 2.2.2.2 255.255.255.255 > >>> ip pim sparse-mode > >>> ip igmp join-group 229.0.0.2 > >>> ! > >>> ip route 1.1.1.1 255.255.255.255 10.0.0.1 > >>> ip pim rp-address 1.1.1.1 > >>> > >>> *** R3 *** > >>> interface Serial1/0 > >>> ip address 10.0.0.3 255.255.255.0 > >>> ip pim sparse-mode > >>> encapsulation frame-relay > >>> frame-relay map ip 10.0.0.2 301 > >>> frame-relay map ip 10.0.0.1 301 broadcast > >>> ! > >>> ip route 1.1.1.1 255.255.255.255 10.0.0.1 > >>> ip pim rp-address 1.1.1.1 > >>> > >>> *** Testing *** > >>> Ping is from R3 to 229.0.0.2, which is joined on R2. The first ping > goes > >>> through fine, all others drop until the mroute times out on R1. > >>> > >>> --- > >>> R3(config)#do ping 229.0.0.2 re 10 > >>> Type escape sequence to abort. > >>> Sending 10, 100-byte ICMP Echos to 229.0.0.2, timeout is 2 seconds: > >>> > >>> Reply to request 0 from 2.2.2.2, 48 ms......... > >>> R3(config)# > >>> --- > >>> > >>> Debugs indicate that R2 (subscriber router) is sending a PIM Prune to > R1 > >>> (the hub/RP) as soon as the first packet is received. R2 retains the > >>> (S,G) > >>> mapping with an incoming interface of s1/0, but the prune message > causes > >>> R1 > >>> to remove S1/0 from the OIL. Any packets after the first are dropped > on > >>> R1 > >>> due to the olist being null. > >>> > >>> I don't understand why the PIM Prune is being generated on R2 for R1 -- > >>> isn't that the router that's sending the stream? Most of all, I don't > >>> understand why something that seems so simple isn't working! > >>> > >>> In conclusion, I hate multicast! > >>> > >>> Appreciate any help you might be able to provide. =) > >>> > >>> Keller Giacomarro > >>> [email protected] > >>> _______________________________________________ > >>> For more information regarding industry leading CCIE Lab training, > >>> please visit www.ipexpert.com > >>> > >>> Are you a CCNP or CCIE and looking for a job? Check out > >>> www.PlatinumPlacement.com > >>> > >>> http://onlinestudylist.com/mailman/listinfo/ccie_rs > >>> > >> > > > _______________________________________________ > For more information regarding industry leading CCIE Lab training, please > visit www.ipexpert.com > > Are you a CCNP or CCIE and looking for a job? Check out > www.PlatinumPlacement.com > > http://onlinestudylist.com/mailman/listinfo/ccie_rs > _______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com http://onlinestudylist.com/mailman/listinfo/ccie_rs End of CCIE_RS Digest, Vol 83, Issue 19 *************************************** _______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com http://onlinestudylist.com/mailman/listinfo/ccie_rs
