Ah Jay your in the CCIE circle I'm new to all this didn't know about Darby.

BR

Tony

Sent from my iPhone on 3

On 18 May 2012, at 13:06, [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: CCIE how to pass the lab (light humour)
>      (Thomas Raabo - Zitcom A/S)
>   2. Re: Access list question (Fulvio allegretti)
>   3. Re: CCIE how to pass the lab (light humour) (Jay McMickle)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Fri, 18 May 2012 07:00:02 +0000
> From: Thomas Raabo - Zitcom A/S <[email protected]>
> To: Ken Wyan <[email protected]>, "[email protected]"
>    <[email protected]>
> Subject: Re: [OSL | CCIE_RS] CCIE how to pass the lab (light humour)
> Message-ID:
>    <[email protected]>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> Even mr Cisco Russ White is no more.
> 
> Thomas
> 
> -----Oprindelig meddelelse-----
> Fra: [email protected] 
> [mailto:[email protected]] P? vegne af Ken Wyan
> Sendt: 18. maj 2012 07:18
> Til: [email protected]
> Emne: Re: [OSL | CCIE_RS] CCIE how to pass the lab (light humour)
> 
> Thanks for sharing.
> 
> This is more or less what's hapenning everywhere. These type of marketing 
> guys dominate cisco also & those with good practical experience slowly quit 
> due to these jokers.
> 
> Finally , Cisco products are full of defects. Smallest bugs remain unresolved 
> for a series of releases.
> 
> On Fri, May 18, 2012 at 7:55 AM, Tony Singh <[email protected]> wrote:
> 
>> This article is good humour, enjoy
>> 
>> http://ccieflyer.com/2010-02-Darby-Weaver-Achilles-Heel.php
>> 
>> BR
>> 
>> Tony
>> 
>> CCNP CCNA R&S JNCIS-SEC MCSE
>> 
>> Sent from my iPhone on 3
>> 
>> On 17 May 2012, at 17:00, [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: ? (Adam Booth)
>>>  2. Re: Interworking in L2VPN (CCIE KID)
>>>  3. WB-1 LAB-17 TASK-17.3 (Ren? Huet)
>>> 
>>> 
>>> --------------------------------------------------------------------
>>> --
>>> 
>>> Message: 1
>>> Date: Thu, 17 May 2012 06:46:35 +1000
>>> From: Adam Booth <[email protected]>
>>> To: "Bodnar, Edward" <[email protected]>
>>> Cc: "[email protected]" <[email protected]>
>>> Subject: Re: [OSL | CCIE_RS] ?
>>> Message-ID:
>>> 
>>> <CAKXsBmpn4KoO45ybp-3=pd31hmpsext-bw28_h1ck2l5ltc...@mail.gmail.com>
>>> Content-Type: text/plain; charset=ISO-8859-1
>>> 
>>> Hi Edward,
>>> 
>>> The Switch adds these via option 82 to the DHCP packet made by a 
>>> DHCP client, so the DHCP server can make some decisions as to what 
>>> to do with that user.  Generally Circuit-Id is used to identify the 
>>> originating
>> switch
>>> and switch port that the customer is connected to, and the remote-id 
>>> may
>> be
>>> a service id/customer id.
>>> 
>>> Depending on your context you could use the Circuit-Id/Remote-Id to
>> always
>>> allocate a specific IP address to a Switch port regardless as to 
>>> what the mac address of the client device is.
>>> 
>>> In a situation where the network infrastructure owner is different 
>>> to the service owner (e.g. a wholesale environment) the 
>>> infrastructure owner may move ports associated with a customer 
>>> around - so the wholesale operator
>> in
>>> a lot of instances is told to rely on using the remote-id and not 
>>> the circuit-id to identify their client (but knowing the circuit-id 
>>> may be useful if there is a fault)
>>> 
>>> Cheers,
>>> Adam
>>> 
>>> 
>>> 
>>> 
>>> On Thu, May 17, 2012 at 4:25 AM, Bodnar, Edward <
>> [email protected]>wrote:
>>> 
>>>> Can anybody provide some clarity around these commands.
>>>> 
>>>> Ip dhcp snooping information option format-type ( circuit-id |
>> remote-id )
>>>> 
>>>> 
>>>> Need info on what they do and why I would use them.
>>>> _______________________________________________
>>>> 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
>>>> 
>>> 
>>> 
>>> ------------------------------
>>> 
>>> Message: 2
>>> Date: Thu, 17 May 2012 12:45:36 +0530
>>> From: CCIE KID <[email protected]>
>>> To: Mohammad Khalil <[email protected]>
>>> Cc: [email protected], [email protected]
>>> Subject: Re: [OSL | CCIE_RS] Interworking in L2VPN
>>> Message-ID:
>>> 
>>> <CAJuc+Q9ZzpE48kSd3YE=y2kshay5e5x9ovuhn9gykblhzhk...@mail.gmail.com>
>>> Content-Type: text/plain; charset=ISO-8859-1
>>> 
>>> Thanks Mohammad,
>>> 
>>> What are the parameters to match when u want to form a Targeted LDP 
>>> peer between two PE's if u have two different VC Types in them.
>>> For example on one side u have Ethernet and on the other side u have FR.
>>> What are the parameters to match on both the sides .
>>> 
>>> 
>>> 
>>> On Tue, May 15, 2012 at 10:52 AM, Mohammad Khalil 
>>> <[email protected]
>>> wrote:
>>> 
>>>> Hi , i did a similar setup using xconnect between EThernet and ATM 
>>>> , please find below (note that TESTING1 is connected to PE1 through 
>>>> NSP
>> and
>>>> TESTING2 is connected to PE2)
>>>> 
>>>> TESTING1
>>>> 
>>>> interface ATM0
>>>> description *** TEC-TEC2 ATM 5/7 *** no ip address no atm 
>>>> ilmi-keepalive dsl operating-mode ansi-dmt end interface ATM0.1 
>>>> point-to-point ip address 172.16.18.98 255.255.255.252 pvc 2/222 
>>>> protocol ip 172.16.18.97 broadcast !
>>>> interface ATM0.2 point-to-point
>>>> ip address 10.10.10.2 255.255.255.252 pvc 30/30 protocol ip 
>>>> 10.10.10.1 broadcast
>>>> 
>>>> TESTING2
>>>> 
>>>> interface FastEthernet0/0
>>>> no ip address
>>>> duplex full
>>>> speed 100
>>>> interface FastEthernet0/0.94
>>>> encapsulation dot1Q 94
>>>> ip address 10.10.10.2 255.255.255.252 !
>>>> interface FastEthernet0/0.99
>>>> encapsulation dot1Q 99
>>>> ip address 172.16.18.97 255.255.255.252
>>>> 
>>>> PE1
>>>> 
>>>> interface GigabitEthernet2/1/0
>>>> mtu 1530
>>>> ip address 62.215.0.49 255.255.255.252 ip ospf network 
>>>> point-to-point negotiation auto mpls ip end interface ATM2/0/0 
>>>> description *** ATM STM-1 Link To 6400-TEC ( ATM3/1/0 ) *** no ip 
>>>> address load-interval 30 no atm enable-ilmi-trap no atm 
>>>> ilmi-keepalive pvc 0/5 qsaal !
>>>> pvc 0/16 ilmi
>>>> !
>>>> End
>>>> interface ATM2/0/0.2020 point-to-point no atm enable-ilmi-trap pvc 
>>>> 12/195 l2transport encapsulation aal5snap xconnect 62.215.0.222 133 
>>>> pw-class inter-ether
>>>> 
>>>> PE2
>>>> 
>>>> interface GigabitEthernet0/1
>>>> mtu 1530
>>>> ip address 62.215.0.50 255.255.255.252 ip ospf network 
>>>> point-to-point media-type sfp speed auto duplex auto negotiation 
>>>> auto mpls ip
>>>> 
>>>> interface GigabitEthernet0/3
>>>> mtu 4470
>>>> no ip address
>>>> media-type rj45
>>>> speed auto
>>>> duplex full
>>>> negotiation auto
>>>> end
>>>> interface GigabitEthernet0/3.99
>>>> encapsulation dot1Q 99
>>>> xconnect 62.215.0.194 133 pw-class inter-ether
>>>> 
>>>> PE2#sh xconnect all
>>>> Legend: XC ST=Xconnect State S1=Segment1 State S2=Segment2 State 
>>>> UP=Up DN=Down AD=Admin Down IA=Inactive SB=Standby RV=Recovering 
>>>> NH=No Hardware XC ST Segment 1 S1 Segment 2
>>>> S2
>>>> 
>> ------+---------------------------------+--+--------------------------
>> ------+---------------------------------+--+---
>>>> ----+--
>>>> UP ac Gi0/3.99:99(Eth VLAN) UP mpls 62.215.0.194:133 UP
>>>> 
>>>> PE2#sh xconnect peer 62.215.0.194 all detail Core network division 
>>>> Xconnect test
>>>> Distribution: Confidential Page 5
>>>> Legend: XC ST=Xconnect State S1=Segment1 State S2=Segment2 State 
>>>> UP=Up DN=Down AD=Admin Down IA=Inactive SB=Standby RV=Recovering 
>>>> NH=No Hardware XC ST Segment 1 S1 Segment 2
>>>> S2
>>>> 
>> ------+---------------------------------+--+--------------------------
>> ------+---------------------------------+--+---
>>>> ----+--
>>>> UP ac Gi0/3.99:99(Eth VLAN) UP mpls 62.215.0.194:133 UP
>>>> Interworking: ip Local VC label 276 Remote VC label 3090
>>>> pw-class: inter-ether
>>>> 
>>>> TEC-TEST#sh mpls l2transport binding 133 Destination Address: 
>>>> 62.215.0.194, VC ID: 133 Local Label: 276
>>>> Cbit: 1, VC Type: IP, GroupID: 0
>>>> MTU: 4470, Interface Desc: n/a
>>>> VCCV: CC Type: CW [1], RA [2]
>>>> CV Type: LSPV [2]
>>>> Remote Label: 3090
>>>> Cbit: 1, VC Type: IP, GroupID: 0
>>>> MTU: 4470, Interface Desc: n/a
>>>> VCCV: CC Type: RA [2]
>>>> CV Type: LSPV [2]
>>>> TEC-TEST#sh mpls l2transport vc 133 detail Local interface: 
>>>> Gi0/3.99 up, line protocol up, Eth VLAN 99 up MPLS VC type is Eth 
>>>> VLAN, interworking type is IP Destination address: 62.215.0.194, VC 
>>>> ID: 133, VC status: up Output interface: Gi0/1, imposed label stack 
>>>> {3090} Preferred path: not configured Default path: active Next 
>>>> hop: 62.215.0.49 Create time: 03:55:11, last status change time: 
>>>> 03:55:11 Signaling protocol: LDP, peer 62.215.0.194:0 up Targeted 
>>>> Hello: 62.215.0.222(LDP Id) -> 62.215.0.194 Status TLV support 
>>>> (local/remote) : enabled/supported Label/status state machine : 
>>>> established, LruRru Last local dataplane status rcvd: no fault Last 
>>>> local SSS circuit status rcvd: no fault Last local SSS circuit 
>>>> status sent: no fault Last local LDP TLV status sent: no fault Last 
>>>> remote LDP TLV status rcvd: no fault MPLS VC labels: local 276, 
>>>> remote 3090 Group ID: local 0, remote 0
>>>> MTU: local 4470, remote 4470
>>>> Remote interface description:
>>>> Sequencing: receive disabled, send disabled VC statistics:
>>>> packet totals: receive 1034, send 1034 byte totals: receive 
>>>> 1066540, send 1089288 packet drops: receive 0, seq error 0, send 0 
>>>> Core network division Xconnect test
>>>> Distribution: Confidential Page 6
>>>> PING
>>>> TESTING2#ping 172.16.18.98 repeat 1000 size 1500 Type escape 
>>>> sequence to abort.
>>>> Sending 1000, 1500-byte ICMP Echos to 172.16.18.98, timeout is 2
>> seconds:
>>>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>>>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>>>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>>>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>>>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>>>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>>>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>>>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>>>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>>>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>>>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>>>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>>>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>>>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>>>> !!!!!!!!!!!!!!!!!!!!
>>>> Success rate is 100 percent (1000/1000), round-trip min/avg/max =
>>>> 40/43/60 ms
>>>> 
>>>> BR,
>>>> Mohammad
>>>> 
>>>>> Date: Mon, 14 May 2012 14:53:17 +0530
>>>>> Subject: Interworking in L2VPN
>>>>> From: [email protected]
>>>>> To: [email protected]; [email protected]
>>>> 
>>>>> 
>>>>> Hi all
>>>>> 
>>>>> I have a scenario where my Frame-Relay to Ethernet interworking is 
>>>>> not working properly. Can someone tell me what are all the 
>>>>> parameters to
>>>> match
>>>>> when forming a T-LDP Pseudowire to be established between Ethernet 
>>>>> one
>>>> side
>>>>> of pseudowire and Frame Relay on the other side of Pseudowire.
>>>>> I know that there are certain parameters to match to make my 
>>>>> Pseudowire T-LDP up The parameters are :
>>>>> 1.VC-ID
>>>>> 2.VC <http://2.vc/> Type ( Port, VLAN, etc) 3.Interface MTU (AC) 
>>>>> 4. LDP password
>>>>> 
>>>>> But when u have interworking configured on both sides , Ur VC Type 
>>>>> wont be matched on both the sides. In this cases, how will my 
>>>>> T-LDP session
>>>> will
>>>>> be up ?
>>>>> 
>>>>> How will the Control plane signaling happens when there is a 
>>>>> different
>> VC
>>>>> types on both sides and i have configured my Interworking on both 
>>>>> the
>>>> sides.
>>>>> 
>>>>> How will the router signal the other end of the peer to know which 
>>>>> VC
>>>> Type
>>>>> it is using and also the Interworking has been configured ?
>>>>> 
>>>>> Is the use of Control Word comes into picture here ?
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> With Warmest Regards,
>>>>> 
>>>>> CCIE KID
>>>>> CCIE#29992 (Security)
>>>>> 
>>>>> 
>>>>> Blogs and organic groups at http://www.ccie.net
>>>>> 
>>>>> __________________________________________________________________
>>>>> _____ Subscription information may be found at:
>>>>> http://www.groupstudy.com/list/CCIELab.html
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>> 
>>> 
>>> 
>>> --
>>> With Warmest Regards,
>>> 
>>> CCIE KID
>>> CCIE#29992 (Security)
>>> 
>>> 
>>> ------------------------------
>>> 
>>> Message: 3
>>> Date: Thu, 17 May 2012 09:53:08 +0200
>>> From: Ren? Huet <[email protected]>
>>> To: [email protected]
>>> Subject: [OSL | CCIE_RS] WB-1 LAB-17 TASK-17.3
>>> Message-ID:
>>> 
>>> <CADFAz+6e2xs2+a-=5E=6eJTxKM7nMUdxkyezaSyfQLkeSxVz=w...@mail.gmail.com>
>>> Content-Type: text/plain; charset=ISO-8859-1
>>> 
>>> Dear all,
>>> 
>>> For the WB-1 LAB-17 TASK-17.3
>>> 
>>> Why we don't deny any 150.100.78.8
>>> what is the difference between deny any 150.100.78.8 or Network address?
>>> 
>>> Normally if I deny any 150.100.78.8 (NVI) is ok no ?
>>> 
>>> If anyone has an explanation I'm interested
>>> 
>>> Best regards
>>> 
>>> Ren?
>>> 
>>> 
>>> End of CCIE_RS Digest, Vol 76, Issue 48
>>> ***************************************
>> _______________________________________________
>> 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
>> 
> _______________________________________________
> 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: Fri, 18 May 2012 11:01:24 +0000
> From: Fulvio allegretti <[email protected]>
> To: <[email protected]>
> Cc: [email protected]
> Subject: Re: [OSL | CCIE_RS] Access list question
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> 
> Yes I did mean 0.0.0.14 and thanks I can see now that my one doesn't match 
> any of the odd 
> 
> 
> 
> Date: Thu, 17 May 2012 18:36:27 -0500
> Subject: Re: [OSL | CCIE_RS] Access list question
> From: [email protected]
> To: [email protected]
> CC: [email protected]
> 
> I think you must be because your access-list is going to match
> 
> 
> 200.0.0.1
> 200.0.0.2
> 200.0.2.0
> 200.0.4.0
> 200.0.6.0
> 200.0.8.0
> 200.0.10.0
> 200.0.12.0
> 200.0.14.0
> 
> 
> 
> 
> I think you meant that second line to be access-list 14 permit 200.0.0.2 
> 0.0.0.14 which still isn't going to match .3 .5 .7 .9 .11 .13
> 
> 
> 
> 
> 
> On Thu, May 17, 2012 at 4:49 PM, Fulvio allegretti <[email protected]> 
> wrote:
> 
> 
> Lab 13 Vol 2 - The task is only hosts with a source ip address range 
> 200.0.0.1 to 200.0.0.14 should be allowed access, use the least amount of 
> lines
> 
> my solution:
> access-list 14 permit 200.0.0.1
> access-list 14 permit 200.0.0.2 0.0.14.0
> 
> IPX solution:
> access-list 23 deny 200.0.0.0
> access-list 23 deny 200.0.0.15
> access-list 23 permit 200.0.0.0 0.0.0.15
> 
> This is not the first time I have seen IPX solutions use this approach 
> instead of mine, am I missing something?
> Fulvio
> 
> 
> _______________________________________________
> 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: Fri, 18 May 2012 07:06:18 -0500
> From: Jay McMickle <[email protected]>
> To: Thomas Raabo - Zitcom A/S <[email protected]>
> Cc: "[email protected]" <[email protected]>
> Subject: Re: [OSL | CCIE_RS] CCIE how to pass the lab (light humour)
> Message-ID: <[email protected]>
> Content-Type: text/plain;    charset=utf-8
> 
> Ken-
> Wow- with that attitude, I would wonder why you would be pursuing such an 
> elite certification. Dumps alone will not get anyone to pass.
> 
> Oh, and keep in mind that Darby is bitter due to his multiple failed attempts 
> since 2002. Jus sayin'.
> 
> Regards,
> Jay McMickle- CCIE #35355 (R&S)
> Sent from iJay
> 
> On May 18, 2012, at 2:00 AM, Thomas Raabo - Zitcom A/S <[email protected]> wrote:
> 
>> Even mr Cisco Russ White is no more.
>> 
>> Thomas
>> 
>> -----Oprindelig meddelelse-----
>> Fra: [email protected] 
>> [mailto:[email protected]] P? vegne af Ken Wyan
>> Sendt: 18. maj 2012 07:18
>> Til: [email protected]
>> Emne: Re: [OSL | CCIE_RS] CCIE how to pass the lab (light humour)
>> 
>> Thanks for sharing.
>> 
>> This is more or less what's hapenning everywhere. These type of marketing 
>> guys dominate cisco also & those with good practical experience slowly quit 
>> due to these jokers.
>> 
>> Finally , Cisco products are full of defects. Smallest bugs remain 
>> unresolved for a series of releases.
>> 
>> On Fri, May 18, 2012 at 7:55 AM, Tony Singh <[email protected]> wrote:
>> 
>>> This article is good humour, enjoy
>>> 
>>> http://ccieflyer.com/2010-02-Darby-Weaver-Achilles-Heel.php
>>> 
>>> BR
>>> 
>>> Tony
>>> 
>>> CCNP CCNA R&S JNCIS-SEC MCSE
>>> 
>>> Sent from my iPhone on 3
>>> 
>>> On 17 May 2012, at 17:00, [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: ? (Adam Booth)
>>>> 2. Re: Interworking in L2VPN (CCIE KID)
>>>> 3. WB-1 LAB-17 TASK-17.3 (Ren? Huet)
>>>> 
>>>> 
>>>> --------------------------------------------------------------------
>>>> --
>>>> 
>>>> Message: 1
>>>> Date: Thu, 17 May 2012 06:46:35 +1000
>>>> From: Adam Booth <[email protected]>
>>>> To: "Bodnar, Edward" <[email protected]>
>>>> Cc: "[email protected]" <[email protected]>
>>>> Subject: Re: [OSL | CCIE_RS] ?
>>>> Message-ID:
>>>> 
>>>> <CAKXsBmpn4KoO45ybp-3=pd31hmpsext-bw28_h1ck2l5ltc...@mail.gmail.com>
>>>> Content-Type: text/plain; charset=ISO-8859-1
>>>> 
>>>> Hi Edward,
>>>> 
>>>> The Switch adds these via option 82 to the DHCP packet made by a 
>>>> DHCP client, so the DHCP server can make some decisions as to what 
>>>> to do with that user.  Generally Circuit-Id is used to identify the 
>>>> originating
>>> switch
>>>> and switch port that the customer is connected to, and the remote-id 
>>>> may
>>> be
>>>> a service id/customer id.
>>>> 
>>>> Depending on your context you could use the Circuit-Id/Remote-Id to
>>> always
>>>> allocate a specific IP address to a Switch port regardless as to 
>>>> what the mac address of the client device is.
>>>> 
>>>> In a situation where the network infrastructure owner is different 
>>>> to the service owner (e.g. a wholesale environment) the 
>>>> infrastructure owner may move ports associated with a customer 
>>>> around - so the wholesale operator
>>> in
>>>> a lot of instances is told to rely on using the remote-id and not 
>>>> the circuit-id to identify their client (but knowing the circuit-id 
>>>> may be useful if there is a fault)
>>>> 
>>>> Cheers,
>>>> Adam
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On Thu, May 17, 2012 at 4:25 AM, Bodnar, Edward <
>>> [email protected]>wrote:
>>>> 
>>>>> Can anybody provide some clarity around these commands.
>>>>> 
>>>>> Ip dhcp snooping information option format-type ( circuit-id |
>>> remote-id )
>>>>> 
>>>>> 
>>>>> Need info on what they do and why I would use them.
>>>>> _______________________________________________
>>>>> 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
>>>>> 
>>>> 
>>>> 
>>>> ------------------------------
>>>> 
>>>> Message: 2
>>>> Date: Thu, 17 May 2012 12:45:36 +0530
>>>> From: CCIE KID <[email protected]>
>>>> To: Mohammad Khalil <[email protected]>
>>>> Cc: [email protected], [email protected]
>>>> Subject: Re: [OSL | CCIE_RS] Interworking in L2VPN
>>>> Message-ID:
>>>> 
>>>> <CAJuc+Q9ZzpE48kSd3YE=y2kshay5e5x9ovuhn9gykblhzhk...@mail.gmail.com>
>>>> Content-Type: text/plain; charset=ISO-8859-1
>>>> 
>>>> Thanks Mohammad,
>>>> 
>>>> What are the parameters to match when u want to form a Targeted LDP 
>>>> peer between two PE's if u have two different VC Types in them.
>>>> For example on one side u have Ethernet and on the other side u have FR.
>>>> What are the parameters to match on both the sides .
>>>> 
>>>> 
>>>> 
>>>> On Tue, May 15, 2012 at 10:52 AM, Mohammad Khalil 
>>>> <[email protected]
>>>> wrote:
>>>> 
>>>>> Hi , i did a similar setup using xconnect between EThernet and ATM 
>>>>> , please find below (note that TESTING1 is connected to PE1 through 
>>>>> NSP
>>> and
>>>>> TESTING2 is connected to PE2)
>>>>> 
>>>>> TESTING1
>>>>> 
>>>>> interface ATM0
>>>>> description *** TEC-TEC2 ATM 5/7 *** no ip address no atm 
>>>>> ilmi-keepalive dsl operating-mode ansi-dmt end interface ATM0.1 
>>>>> point-to-point ip address 172.16.18.98 255.255.255.252 pvc 2/222 
>>>>> protocol ip 172.16.18.97 broadcast !
>>>>> interface ATM0.2 point-to-point
>>>>> ip address 10.10.10.2 255.255.255.252 pvc 30/30 protocol ip 
>>>>> 10.10.10.1 broadcast
>>>>> 
>>>>> TESTING2
>>>>> 
>>>>> interface FastEthernet0/0
>>>>> no ip address
>>>>> duplex full
>>>>> speed 100
>>>>> interface FastEthernet0/0.94
>>>>> encapsulation dot1Q 94
>>>>> ip address 10.10.10.2 255.255.255.252 !
>>>>> interface FastEthernet0/0.99
>>>>> encapsulation dot1Q 99
>>>>> ip address 172.16.18.97 255.255.255.252
>>>>> 
>>>>> PE1
>>>>> 
>>>>> interface GigabitEthernet2/1/0
>>>>> mtu 1530
>>>>> ip address 62.215.0.49 255.255.255.252 ip ospf network 
>>>>> point-to-point negotiation auto mpls ip end interface ATM2/0/0 
>>>>> description *** ATM STM-1 Link To 6400-TEC ( ATM3/1/0 ) *** no ip 
>>>>> address load-interval 30 no atm enable-ilmi-trap no atm 
>>>>> ilmi-keepalive pvc 0/5 qsaal !
>>>>> pvc 0/16 ilmi
>>>>> !
>>>>> End
>>>>> interface ATM2/0/0.2020 point-to-point no atm enable-ilmi-trap pvc 
>>>>> 12/195 l2transport encapsulation aal5snap xconnect 62.215.0.222 133 
>>>>> pw-class inter-ether
>>>>> 
>>>>> PE2
>>>>> 
>>>>> interface GigabitEthernet0/1
>>>>> mtu 1530
>>>>> ip address 62.215.0.50 255.255.255.252 ip ospf network 
>>>>> point-to-point media-type sfp speed auto duplex auto negotiation 
>>>>> auto mpls ip
>>>>> 
>>>>> interface GigabitEthernet0/3
>>>>> mtu 4470
>>>>> no ip address
>>>>> media-type rj45
>>>>> speed auto
>>>>> duplex full
>>>>> negotiation auto
>>>>> end
>>>>> interface GigabitEthernet0/3.99
>>>>> encapsulation dot1Q 99
>>>>> xconnect 62.215.0.194 133 pw-class inter-ether
>>>>> 
>>>>> PE2#sh xconnect all
>>>>> Legend: XC ST=Xconnect State S1=Segment1 State S2=Segment2 State 
>>>>> UP=Up DN=Down AD=Admin Down IA=Inactive SB=Standby RV=Recovering 
>>>>> NH=No Hardware XC ST Segment 1 S1 Segment 2
>>>>> S2
>>>>> 
>>> ------+---------------------------------+--+--------------------------
>>> ------+---------------------------------+--+---
>>>>> ----+--
>>>>> UP ac Gi0/3.99:99(Eth VLAN) UP mpls 62.215.0.194:133 UP
>>>>> 
>>>>> PE2#sh xconnect peer 62.215.0.194 all detail Core network division 
>>>>> Xconnect test
>>>>> Distribution: Confidential Page 5
>>>>> Legend: XC ST=Xconnect State S1=Segment1 State S2=Segment2 State 
>>>>> UP=Up DN=Down AD=Admin Down IA=Inactive SB=Standby RV=Recovering 
>>>>> NH=No Hardware XC ST Segment 1 S1 Segment 2
>>>>> S2
>>>>> 
>>> ------+---------------------------------+--+--------------------------
>>> ------+---------------------------------+--+---
>>>>> ----+--
>>>>> UP ac Gi0/3.99:99(Eth VLAN) UP mpls 62.215.0.194:133 UP
>>>>> Interworking: ip Local VC label 276 Remote VC label 3090
>>>>> pw-class: inter-ether
>>>>> 
>>>>> TEC-TEST#sh mpls l2transport binding 133 Destination Address: 
>>>>> 62.215.0.194, VC ID: 133 Local Label: 276
>>>>> Cbit: 1, VC Type: IP, GroupID: 0
>>>>> MTU: 4470, Interface Desc: n/a
>>>>> VCCV: CC Type: CW [1], RA [2]
>>>>> CV Type: LSPV [2]
>>>>> Remote Label: 3090
>>>>> Cbit: 1, VC Type: IP, GroupID: 0
>>>>> MTU: 4470, Interface Desc: n/a
>>>>> VCCV: CC Type: RA [2]
>>>>> CV Type: LSPV [2]
>>>>> TEC-TEST#sh mpls l2transport vc 133 detail Local interface: 
>>>>> Gi0/3.99 up, line protocol up, Eth VLAN 99 up MPLS VC type is Eth 
>>>>> VLAN, interworking type is IP Destination address: 62.215.0.194, VC 
>>>>> ID: 133, VC status: up Output interface: Gi0/1, imposed label stack 
>>>>> {3090} Preferred path: not configured Default path: active Next 
>>>>> hop: 62.215.0.49 Create time: 03:55:11, last status change time: 
>>>>> 03:55:11 Signaling protocol: LDP, peer 62.215.0.194:0 up Targeted 
>>>>> Hello: 62.215.0.222(LDP Id) -> 62.215.0.194 Status TLV support 
>>>>> (local/remote) : enabled/supported Label/status state machine : 
>>>>> established, LruRru Last local dataplane status rcvd: no fault Last 
>>>>> local SSS circuit status rcvd: no fault Last local SSS circuit 
>>>>> status sent: no fault Last local LDP TLV status sent: no fault Last 
>>>>> remote LDP TLV status rcvd: no fault MPLS VC labels: local 276, 
>>>>> remote 3090 Group ID: local 0, remote 0
>>>>> MTU: local 4470, remote 4470
>>>>> Remote interface description:
>>>>> Sequencing: receive disabled, send disabled VC statistics:
>>>>> packet totals: receive 1034, send 1034 byte totals: receive 
>>>>> 1066540, send 1089288 packet drops: receive 0, seq error 0, send 0 
>>>>> Core network division Xconnect test
>>>>> Distribution: Confidential Page 6
>>>>> PING
>>>>> TESTING2#ping 172.16.18.98 repeat 1000 size 1500 Type escape 
>>>>> sequence to abort.
>>>>> Sending 1000, 1500-byte ICMP Echos to 172.16.18.98, timeout is 2
>>> seconds:
>>>>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>>>>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>>>>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>>>>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>>>>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>>>>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>>>>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>>>>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>>>>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>>>>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>>>>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>>>>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>>>>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>>>>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>>>>> !!!!!!!!!!!!!!!!!!!!
>>>>> Success rate is 100 percent (1000/1000), round-trip min/avg/max =
>>>>> 40/43/60 ms
>>>>> 
>>>>> BR,
>>>>> Mohammad
>>>>> 
>>>>>> Date: Mon, 14 May 2012 14:53:17 +0530
>>>>>> Subject: Interworking in L2VPN
>>>>>> From: [email protected]
>>>>>> To: [email protected]; [email protected]
>>>>> 
>>>>>> 
>>>>>> Hi all
>>>>>> 
>>>>>> I have a scenario where my Frame-Relay to Ethernet interworking is 
>>>>>> not working properly. Can someone tell me what are all the 
>>>>>> parameters to
>>>>> match
>>>>>> when forming a T-LDP Pseudowire to be established between Ethernet 
>>>>>> one
>>>>> side
>>>>>> of pseudowire and Frame Relay on the other side of Pseudowire.
>>>>>> I know that there are certain parameters to match to make my 
>>>>>> Pseudowire T-LDP up The parameters are :
>>>>>> 1.VC-ID
>>>>>> 2.VC <http://2.vc/> Type ( Port, VLAN, etc) 3.Interface MTU (AC) 
>>>>>> 4. LDP password
>>>>>> 
>>>>>> But when u have interworking configured on both sides , Ur VC Type 
>>>>>> wont be matched on both the sides. In this cases, how will my 
>>>>>> T-LDP session
>>>>> will
>>>>>> be up ?
>>>>>> 
>>>>>> How will the Control plane signaling happens when there is a 
>>>>>> different
>>> VC
>>>>>> types on both sides and i have configured my Interworking on both 
>>>>>> the
>>>>> sides.
>>>>>> 
>>>>>> How will the router signal the other end of the peer to know which 
>>>>>> VC
>>>>> Type
>>>>>> it is using and also the Interworking has been configured ?
>>>>>> 
>>>>>> Is the use of Control Word comes into picture here ?
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> With Warmest Regards,
>>>>>> 
>>>>>> CCIE KID
>>>>>> CCIE#29992 (Security)
>>>>>> 
>>>>>> 
>>>>>> Blogs and organic groups at http://www.ccie.net
>>>>>> 
>>>>>> __________________________________________________________________
>>>>>> _____ Subscription information may be found at:
>>>>>> http://www.groupstudy.com/list/CCIELab.html
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> 
>>>> --
>>>> With Warmest Regards,
>>>> 
>>>> CCIE KID
>>>> CCIE#29992 (Security)
>>>> 
>>>> 
>>>> ------------------------------
>>>> 
>>>> Message: 3
>>>> Date: Thu, 17 May 2012 09:53:08 +0200
>>>> From: Ren? Huet <[email protected]>
>>>> To: [email protected]
>>>> Subject: [OSL | CCIE_RS] WB-1 LAB-17 TASK-17.3
>>>> Message-ID:
>>>> 
>>>> <CADFAz+6e2xs2+a-=5E=6eJTxKM7nMUdxkyezaSyfQLkeSxVz=w...@mail.gmail.com>
>>>> Content-Type: text/plain; charset=ISO-8859-1
>>>> 
>>>> Dear all,
>>>> 
>>>> For the WB-1 LAB-17 TASK-17.3
>>>> 
>>>> Why we don't deny any 150.100.78.8
>>>> what is the difference between deny any 150.100.78.8 or Network address?
>>>> 
>>>> Normally if I deny any 150.100.78.8 (NVI) is ok no ?
>>>> 
>>>> If anyone has an explanation I'm interested
>>>> 
>>>> Best regards
>>>> 
>>>> Ren?
>>>> 
>>>> 
>>>> End of CCIE_RS Digest, Vol 76, Issue 48
>>>> ***************************************
>>> _______________________________________________
>>> 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
>>> 
>> _______________________________________________
>> 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 76, Issue 50
> ***************************************
_______________________________________________
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