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
