Be careful of licensing if upgrading.  Lesson learned here.  I now have an 
EIGRP stub.

Sent from my iPhone

On Jan 26, 2013, at 11:09 AM, [email protected] wrote:

> 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: QoS remarking not working (John Dooner)
>   2.  neighbor default-originate (Lukasz)
>   3. Re: neighbor default-originate (Marko Milivojevic)
>   4. Re: neighbor default-originate (Anthony Sequeira)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Fri, 25 Jan 2013 14:02:25 -0600
> From: John Dooner <[email protected]>
> To: ccie_rs <[email protected]>
> Subject: Re: [OSL | CCIE_RS] QoS remarking not working
> Message-ID:
>    <cadokfwmeexroxe-u2pwm58tjpr6m8tjodk7nq3ugmjdhr-z...@mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> TAC has recommended that we upgrade IOS to version 15, or to not use ranges
> and just equal the specific port. For us that will mean upgrading to 15 as
> we have too many ports to do this manually. (unfortunately we have 5000
> switches so this will be fun...) Apparently more TAC cases have been opened
> recently regarding this issue with port ranges per our TAC engineer.
> 
> Thanks to all those who responded.
> 
> 
> 
> On Thu, Jan 24, 2013 at 8:49 PM, Matt Hill <[email protected]> wrote:
> 
>> Looks like we are going somewhere here.  Try this test:
>> 
>> Put the ACL with permit statements for the range on an L3 interface on
>> the switch, ie so it doesnt do anything fancy, dont forget permit ip
>> any any after the range entry.
>> 
>> If the counters increment, then problem is only limited to using
>> class-maps.  If the counters do not increment, then you have a bug
>> with the range command for ACLs in general.
>> 
>> Cheers,
>> Matt
>> 
>> CCIE #22386
>> CCSI #31207
>> 
>> On 25 January 2013 13:38, John Dooner <[email protected]> wrote:
>>> It is working on those ports. We did a capture, although the codec tells
>>> you what port it is using when you establish a video conference. Also
>>> remember that when I change the ACL to equal the udp port as shown by the
>>> codec I get the packets remarked with af41 (decimal 34). This is
>> confirmed
>>> using the show mls qos interface stat command. When I change the ACL to
>> use the
>>> range command the packets stay at dscp 0 as confirmed using the show mls
>>> qos interface stat command.
>>> 
>>> On Thursday, January 24, 2013, Samir Idris wrote:
>>> 
>>>> Can you run a packet capture to make sure video traffic is working on
>> the
>>>> UDP ports you have specified in the ACL?
>>>> 
>>>> On Fri, Jan 25, 2013 at 9:13 AM, John Dooner 
>>>> <[email protected]<javascript:_e({},
>> 'cvml', '[email protected]');>
>>>>> wrote:
>>>> 
>>>>> Hi everyone,
>>>>> I cannot get a 3750x  to remark video traffic if I use these commands.
>> I
>>>>> have abbreviated the config to concentrate on one aspect.
>>>>> 
>>>>> class-map match-any CLASS-VIDEO
>>>>> match access-group name ACL-VIDEO
>>>>> !
>>>>> policy-map POLICY-INGRESS
>>>>> class CLASS-VIDEO
>>>>>  set ip dscp af41
>>>>> !
>>>>> ip access-list extended ACL-VIDEO
>>>>> permit udp any any range 2326 2487 <-----this line does not seem to
>> work
>>>>> and the traffic will go out dscp 0.
>>>>> 
>>>>> But if I change the extended access-list from permit range to permit
>> equal
>>>>> the UDP port, it will work. Example:
>>>>> 
>>>>> class-map match-any CLASS-VIDEO
>>>>> match access-group name ACL-VIDEO
>>>>> !
>>>>> !
>>>>> policy-map POLICY-INGRESS
>>>>> class CLASS-VIDEO
>>>>>  set ip dscp af41
>>>>> !
>>>>> ip access-list extended ACL-VIDEO
>>>>>  permit udp any any eq 2344 <---this works and the traffic is remarked
>>>>> DSCP 41.
>>>>> 
>>>>> Does anyone have any ideas? I don't see ACL hit, but I think you cannot
>>>>> see
>>>>> any access-list hits because of it being nested in the policy map.The
>>>>> version of IOS is 12.2(55)SE3 LANBASE.
>>>>> 
>>>>> Thanks,
>>>>> JD
>>>>> _______________________________________________
>>>>> 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://www.platinumplacement.com/>
>>>>> 
>>>>> http://onlinestudylist.com/mailman/listinfo/ccie_rs
>>>> 
>>>> 
>>>> 
>>>> --
>>>> Samir Idris
>>> _______________________________________________
>>> 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: 2
> Date: Sat, 26 Jan 2013 00:55:13 +0000
> From: Lukasz <[email protected]>
> To: CCIE OSL <[email protected]>
> Subject: [OSL | CCIE_RS]  neighbor default-originate
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=UTF-8; format=flowed
> 
> Hi All,
> 
> 
> I am just trying to replicate Marko scenario from blog Multicast RPF 
> Failure: Recovery Using BGP. I have only changed addressing but other 
> details are the same. I have ipv4 unicast working and Pim enabled.
> I have disabled pim between R3 and R4 on Fa interface and I can see RPF 
> failure. I set up MP-BGP and that is active as well but..command 
> neighbor x.x.x.x default-originate does not seem to send default route 
> to the neighbor.
> 
> 
> R3
> 
> router bgp 34
>  no bgp default ipv4-unicast
>  bgp log-neighbor-changes
>  neighbor 4.4.4.4 remote-as 34
>  neighbor 4.4.4.4 update-source Loopback0
>  !
>  address-family ipv4 multicast
>   neighbor 4.4.4.4 activate
>   neighbor 4.4.4.4 default-originate
>   no auto-summary
> 
> 
> R3#show bgp ipv4 multicast neighbors 4.4.4.4 | b def
>   Default information originate, default not sent
> 
> 
> R4
> 
> 
> router bgp 34
>  no bgp default ipv4-unicast
>  bgp log-neighbor-changes
>  neighbor 3.3.3.3 remote-as 34
>  neighbor 3.3.3.3 update-source Loopback0
>  !
>  address-family ipv4 multicast
>   neighbor 3.3.3.3 activate
>   no auto-summary
>   no synchronization
>  exit-address-family
> R4#
> R4#show bgp ipv4 mul
> 
> 
> R4#show bgp ipv4 mul s
> Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  
> State/PfxRcd
> 3.3.3.3         4    34      61      59        3    0    0 00:34:57     
>   0
> 
> 
> I guess I misinterpret something. Where is the problem?
> 
> 
> THanks,
> 
> 
> 
> 
> ------------------------------
> 
> Message: 3
> Date: Fri, 25 Jan 2013 20:58:31 -0800
> From: Marko Milivojevic <[email protected]>
> To: Lukasz <[email protected]>
> Cc: CCIE OSL <[email protected]>
> Subject: Re: [OSL | CCIE_RS] neighbor default-originate
> Message-ID: <[email protected]>
> Content-Type: text/plain;    charset=us-ascii
> 
> You need to arm yourself with patience.  When I demonstrate this in the 
> class, I usually go and get coffee while the router makes up its mind about 
> advertising the 0.0.0.0/0 :-)
> 
> --
> Marko Milivojevic - CCIE #18427 (SP R&S)
> Senior CCIE Instructor / Managing Partner - IPexpert
> 
> :: This message was sent from a mobile device. I apologize for errors and 
> brevity. ::
> 
> On Jan 25, 2013, at 16:55, Lukasz <[email protected]> wrote:
> 
>> Hi All,
>> 
>> 
>> I am just trying to replicate Marko scenario from blog Multicast RPF 
>> Failure: Recovery Using BGP. I have only changed addressing but other 
>> details are the same. I have ipv4 unicast working and Pim enabled.
>> I have disabled pim between R3 and R4 on Fa interface and I can see RPF 
>> failure. I set up MP-BGP and that is active as well but..command neighbor 
>> x.x.x.x default-originate does not seem to send default route to the 
>> neighbor.
>> 
>> 
>> R3
>> 
>> router bgp 34
>> no bgp default ipv4-unicast
>> bgp log-neighbor-changes
>> neighbor 4.4.4.4 remote-as 34
>> neighbor 4.4.4.4 update-source Loopback0
>> !
>> address-family ipv4 multicast
>> neighbor 4.4.4.4 activate
>> neighbor 4.4.4.4 default-originate
>> no auto-summary
>> 
>> 
>> R3#show bgp ipv4 multicast neighbors 4.4.4.4 | b def
>> Default information originate, default not sent
>> 
>> 
>> R4
>> 
>> 
>> router bgp 34
>> no bgp default ipv4-unicast
>> bgp log-neighbor-changes
>> neighbor 3.3.3.3 remote-as 34
>> neighbor 3.3.3.3 update-source Loopback0
>> !
>> address-family ipv4 multicast
>> neighbor 3.3.3.3 activate
>> no auto-summary
>> no synchronization
>> exit-address-family
>> R4#
>> R4#show bgp ipv4 mul
>> 
>> 
>> R4#show bgp ipv4 mul s
>> Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  
>> State/PfxRcd
>> 3.3.3.3         4    34      61      59        3    0    0 00:34:57       0
>> 
>> 
>> I guess I misinterpret something. Where is the problem?
>> 
>> 
>> THanks,
>> 
>> 
>> _______________________________________________
>> 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: 4
> Date: Sat, 26 Jan 2013 11:25:42 +0000
> From: Anthony Sequeira <[email protected]>
> To: Marko Milivojevic <[email protected]>, Lukasz
>    <[email protected]>
> Cc: CCIE OSL <[email protected]>
> Subject: Re: [OSL | CCIE_RS] neighbor default-originate
> Message-ID:
>    
> <F8E2B2161E302C498E5A29B2F848584E731D63@MBX029-E1-VA-2.EXCH029.DOMAIN.LOCAL>
>    
> Content-Type: text/plain; charset="us-ascii"
> 
> That is hilarious! 
> 
> On 1/25/13 11:58 PM, "Marko Milivojevic" <[email protected]> wrote:
> 
>> You need to arm yourself with patience.  When I demonstrate this in the
>> class, I usually go and get coffee while the router makes up its mind
>> about advertising the 0.0.0.0/0 :-)
>> 
>> --
>> Marko Milivojevic - CCIE #18427 (SP R&S)
>> Senior CCIE Instructor / Managing Partner - IPexpert
>> 
>> :: This message was sent from a mobile device. I apologize for errors and
>> brevity. ::
>> 
>> On Jan 25, 2013, at 16:55, Lukasz <[email protected]> wrote:
>> 
>>> Hi All,
>>> 
>>> 
>>> I am just trying to replicate Marko scenario from blog Multicast RPF
>>> Failure: Recovery Using BGP. I have only changed addressing but other
>>> details are the same. I have ipv4 unicast working and Pim enabled.
>>> I have disabled pim between R3 and R4 on Fa interface and I can see RPF
>>> failure. I set up MP-BGP and that is active as well but..command
>>> neighbor x.x.x.x default-originate does not seem to send default route
>>> to the neighbor.
>>> 
>>> 
>>> R3
>>> 
>>> router bgp 34
>>> no bgp default ipv4-unicast
>>> bgp log-neighbor-changes
>>> neighbor 4.4.4.4 remote-as 34
>>> neighbor 4.4.4.4 update-source Loopback0
>>> !
>>> address-family ipv4 multicast
>>> neighbor 4.4.4.4 activate
>>> neighbor 4.4.4.4 default-originate
>>> no auto-summary
>>> 
>>> 
>>> R3#show bgp ipv4 multicast neighbors 4.4.4.4 | b def
>>> Default information originate, default not sent
>>> 
>>> 
>>> R4
>>> 
>>> 
>>> router bgp 34
>>> no bgp default ipv4-unicast
>>> bgp log-neighbor-changes
>>> neighbor 3.3.3.3 remote-as 34
>>> neighbor 3.3.3.3 update-source Loopback0
>>> !
>>> address-family ipv4 multicast
>>> neighbor 3.3.3.3 activate
>>> no auto-summary
>>> no synchronization
>>> exit-address-family
>>> R4#
>>> R4#show bgp ipv4 mul
>>> 
>>> 
>>> R4#show bgp ipv4 mul s
>>> Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down
>>> State/PfxRcd
>>> 3.3.3.3         4    34      61      59        3    0    0 00:34:57
>>> 0
>>> 
>>> 
>>> I guess I misinterpret something. Where is the problem?
>>> 
>>> 
>>> THanks,
>>> 
>>> 
>>> _______________________________________________
>>> 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 84, Issue 38
> ***************************************
_______________________________________________
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

Reply via email to