Q
Sent from my Verizon Wireless BlackBerry
-----Original Message-----
From: [email protected]
Date: Fri, 05 Mar 2010 15:36:34
To: <[email protected]>
Subject: CCIE_RS Digest, Vol 50, Issue 20
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: odd prefix (Joe Astorino)
2. Version Vol1. Lab 6 R6<->R9 links (Frank)
3. Re: Version Vol1. Lab 6 R6<->R9 links (Di Bias, Steve)
4. Re: Version Vol1. Lab 6 R6<->R9 links (Joe Astorino)
5. Re: Version Vol1. Lab 6 R6<->R9 links (Marko Milivojevic)
----------------------------------------------------------------------
Message: 1
Date: Fri, 5 Mar 2010 15:05:00 -0500
From: Joe Astorino <[email protected]>
Subject: Re: [OSL | CCIE_RS] odd prefix
To: Mustafa Yadav <[email protected]>
Cc: ccie_rs <[email protected]>
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Let me break it down a little bit more:
permit 0.0.0.0 255.255.254.255
The 255.255.254.255 is a wildcard mask....so in binary we have
11111111.11111111.11111110.11111111
This means we could care less about 31 out of the 32 bits in that IP
address. The only thing we care about is that the least significant bit of
the third octet is a 0, meaning anything with an even third octet is
permitted.
On Fri, Mar 5, 2010 at 3:01 PM, Joe Astorino <[email protected]> wrote:
> You have it backwards.
>
> In wildcard masks 0 means "it must be" and 1 means " I don't care"
>
>
> On Fri, Mar 5, 2010 at 2:33 PM, Mustafa Yadav <[email protected]>wrote:
>
>> I understood from here 255.255.254.255 is wildcard mask and normally it
>> means 0.0.1.0 .
>>
>> 1 means I do care that bit and 0 means I do not care.Since 1 isd the least
>> significant bit and in the network portion is zero ,having 0 in the that
>> bit is a must.
>>
>> Is my understanding correct?
>>
>> On Fri, Mar 5, 2010 at 9:07 PM, Joe Astorino <[email protected]>wrote:
>>
>>> The access-list you have below will only allow networks with an even
>>> third octet. Since it denies everything else, that would work.
>>>
>>> The logic here is that the least significant bit of the third octet must
>>> be equal to a 0. Therefore, only evens are permitted since all even
>>> networks end with a 0.
>>>
>>> On Fri, Mar 5, 2010 at 2:02 PM, Mustafa Yadav <[email protected]
>>> > wrote:
>>>
>>>> hi all,
>>>> I have read in one question asked do not want odd in third octet .I am
>>>> not pretty sure about the answer but it was something like below.Can
>>>> someone
>>>> clarify the llogic behind it?
>>>>
>>>> access-list 1 permit 0.0.0.0 255.255.254.255
>>>>
>>>> _______________________________________________
>>>> For more information regarding industry leading CCIE Lab training,
>>>> please visit www.ipexpert.com
>>>>
>>>>
>>>
>>>
>>> --
>>> Regards,
>>>
>>> Joe Astorino CCIE #24347 (R&S)
>>> Sr. Technical Instructor - IPexpert
>>> Mailto: [email protected]
>>> Telephone: +1.810.326.1444
>>> Live Assistance, Please visit: www.ipexpert.com/chat
>>> eFax: +1.810.454.0130
>>>
>>> IPexpert is a premier provider of Classroom and Self-Study Cisco CCNA
>>> (R&S, Voice & Security), CCNP, CCVP, CCSP and CCIE (R&S, Voice, Security &
>>> Service Provider) Certification Training with locations throughout the
>>> United States, Europe and Australia. Be sure to check out our online
>>> communities at www.ipexpert.com/communities and our public website at
>>> www.ipexpert.com
>>>
>>>
>>>
>>
>
>
> --
> Regards,
>
> Joe Astorino CCIE #24347 (R&S)
> Sr. Technical Instructor - IPexpert
> Mailto: [email protected]
> Telephone: +1.810.326.1444
> Live Assistance, Please visit: www.ipexpert.com/chat
> eFax: +1.810.454.0130
>
> IPexpert is a premier provider of Classroom and Self-Study Cisco CCNA (R&S,
> Voice & Security), CCNP, CCVP, CCSP and CCIE (R&S, Voice, Security & Service
> Provider) Certification Training with locations throughout the United
> States, Europe and Australia. Be sure to check out our online communities at
> www.ipexpert.com/communities and our public website at www.ipexpert.com
>
>
>
--
Regards,
Joe Astorino CCIE #24347 (R&S)
Sr. Technical Instructor - IPexpert
Mailto: [email protected]
Telephone: +1.810.326.1444
Live Assistance, Please visit: www.ipexpert.com/chat
eFax: +1.810.454.0130
IPexpert is a premier provider of Classroom and Self-Study Cisco CCNA (R&S,
Voice & Security), CCNP, CCVP, CCSP and CCIE (R&S, Voice, Security & Service
Provider) Certification Training with locations throughout the United
States, Europe and Australia. Be sure to check out our online communities at
www.ipexpert.com/communities and our public website at www.ipexpert.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://onlinestudylist.com/pipermail/ccie_rs/attachments/20100305/d9651319/attachment-0001.htm
------------------------------
Message: 2
Date: Fri, 05 Mar 2010 21:28:28 +0100
From: Frank <[email protected]>
Subject: [OSL | CCIE_RS] Version Vol1. Lab 6 R6<->R9 links
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
Hi,
I came up with a different solution for the missing LMI and keep-alive
on the interlinks between R6 and R9.
Instead of using "no keepalive", you can also make one side of the links
a FR switch.
For example, if I do:
interface MFR1
no ip address
frame-relay intf-type dce <=========
!
interface MFR1.69 point-to-point
ip address 150.100.69.9 255.255.255.0
frame-relay interface-dlci 69
!
interface MFR1.96 point-to-point
ip address 150.100.96.9 255.255.255.0
frame-relay interface-dlci 96
then R9 will act as the FR switch, and R6 and R9 will exchange LMI
status messages; and you do not have the problem that the PVC's don't
become active:
R6# sh frame pvc | i ACTIVE.*MFR
DLCI = 69, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = MFR1.69
DLCI = 96, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = MFR1.96
R9#sh frame pvc | i ACT
DLCI = 69, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = MFR1.69
DLCI = 96, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = MFR1.96
R9#sh frame map
MFR1.96 (up): point-to-point dlci, dlci 96(0x60,0x1800), broadcast
status defined, active
MFR1.69 (up): point-to-point dlci, dlci 69(0x45,0x1050), broadcast
status defined, active
Questions:
1) Would this be an acceptable solution (it does not seem to violate any
requirements)?
2) Are there any drawbacks to this approach that I'm overlooking?
Regards,
Farnk
------------------------------
Message: 3
Date: Fri, 5 Mar 2010 15:35:04 -0500
From: "Di Bias, Steve" <[email protected]>
Subject: Re: [OSL | CCIE_RS] Version Vol1. Lab 6 R6<->R9 links
To: Frank <[email protected]>, "[email protected]"
<[email protected]>
Message-ID:
<bc94447e8dc3754d97451ba6d93b5ecf1b85a2f...@corp-exvs01.corp.uhsinc.biz>
Content-Type: text/plain; charset="us-ascii"
This would work and satisfy the requirement as far as I can see, however there
is obviously more commands involved with this approach.
Everyone else agree?
Steve
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Frank
Sent: Friday, March 05, 2010 12:28 PM
To: [email protected]
Subject: [OSL | CCIE_RS] Version Vol1. Lab 6 R6<->R9 links
Hi,
I came up with a different solution for the missing LMI and keep-alive
on the interlinks between R6 and R9.
Instead of using "no keepalive", you can also make one side of the links
a FR switch.
For example, if I do:
interface MFR1
no ip address
frame-relay intf-type dce <=========
!
interface MFR1.69 point-to-point
ip address 150.100.69.9 255.255.255.0
frame-relay interface-dlci 69
!
interface MFR1.96 point-to-point
ip address 150.100.96.9 255.255.255.0
frame-relay interface-dlci 96
then R9 will act as the FR switch, and R6 and R9 will exchange LMI
status messages; and you do not have the problem that the PVC's don't
become active:
R6# sh frame pvc | i ACTIVE.*MFR
DLCI = 69, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = MFR1.69
DLCI = 96, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = MFR1.96
R9#sh frame pvc | i ACT
DLCI = 69, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = MFR1.69
DLCI = 96, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = MFR1.96
R9#sh frame map
MFR1.96 (up): point-to-point dlci, dlci 96(0x60,0x1800), broadcast
status defined, active
MFR1.69 (up): point-to-point dlci, dlci 69(0x45,0x1050), broadcast
status defined, active
Questions:
1) Would this be an acceptable solution (it does not seem to violate any
requirements)?
2) Are there any drawbacks to this approach that I'm overlooking?
Regards,
Farnk
_______________________________________________
For more information regarding industry leading CCIE Lab training, please visit
www.ipexpert.com
UHS Confidentiality Notice: This e-mail message, including any attachments, is
for the sole use of the intended recipient (s) and may contain confidential and
privileged information. Any unauthorized review, use, disclosure or
distribution of this information is prohibited. If this was sent to you in
error, please notify the sender by reply e-mail and destroy all copies of the
original message.
------------------------------
Message: 4
Date: Fri, 5 Mar 2010 15:34:20 -0500
From: Joe Astorino <[email protected]>
Subject: Re: [OSL | CCIE_RS] Version Vol1. Lab 6 R6<->R9 links
To: Frank <[email protected]>
Cc: [email protected]
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Frank,
Excellent work! I think this is a totally acceptable answer. In fact, in
some cases it might be the ONLY answer (nudge, nudge check out volume 3 TS
section I believe ....Lab 9)
On Fri, Mar 5, 2010 at 3:28 PM, Frank <[email protected]> wrote:
>
> Hi,
>
> I came up with a different solution for the missing LMI and keep-alive
> on the interlinks between R6 and R9.
> Instead of using "no keepalive", you can also make one side of the links
> a FR switch.
>
> For example, if I do:
>
> interface MFR1
> no ip address
> frame-relay intf-type dce <=========
> !
> interface MFR1.69 point-to-point
> ip address 150.100.69.9 255.255.255.0
> frame-relay interface-dlci 69
> !
> interface MFR1.96 point-to-point
> ip address 150.100.96.9 255.255.255.0
> frame-relay interface-dlci 96
>
> then R9 will act as the FR switch, and R6 and R9 will exchange LMI
> status messages; and you do not have the problem that the PVC's don't
> become active:
>
> R6# sh frame pvc | i ACTIVE.*MFR
> DLCI = 69, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = MFR1.69
> DLCI = 96, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = MFR1.96
>
> R9#sh frame pvc | i ACT
> DLCI = 69, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = MFR1.69
> DLCI = 96, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = MFR1.96
> R9#sh frame map
> MFR1.96 (up): point-to-point dlci, dlci 96(0x60,0x1800), broadcast
> status defined, active
> MFR1.69 (up): point-to-point dlci, dlci 69(0x45,0x1050), broadcast
> status defined, active
>
> Questions:
>
> 1) Would this be an acceptable solution (it does not seem to violate any
> requirements)?
>
> 2) Are there any drawbacks to this approach that I'm overlooking?
>
> Regards,
>
> Farnk
>
>
>
>
>
> _______________________________________________
> For more information regarding industry leading CCIE Lab training, please
> visit www.ipexpert.com
>
--
Regards,
Joe Astorino CCIE #24347 (R&S)
Sr. Technical Instructor - IPexpert
Mailto: [email protected]
Telephone: +1.810.326.1444
Live Assistance, Please visit: www.ipexpert.com/chat
eFax: +1.810.454.0130
IPexpert is a premier provider of Classroom and Self-Study Cisco CCNA (R&S,
Voice & Security), CCNP, CCVP, CCSP and CCIE (R&S, Voice, Security & Service
Provider) Certification Training with locations throughout the United
States, Europe and Australia. Be sure to check out our online communities at
www.ipexpert.com/communities and our public website at www.ipexpert.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://onlinestudylist.com/pipermail/ccie_rs/attachments/20100305/9b7e4fc9/attachment-0001.htm
------------------------------
Message: 5
Date: Fri, 5 Mar 2010 20:36:13 +0000
From: Marko Milivojevic <[email protected]>
Subject: Re: [OSL | CCIE_RS] Version Vol1. Lab 6 R6<->R9 links
To: Frank <[email protected]>
Cc: [email protected]
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=UTF-8
Hello Frank,
Unless you are told not to do it - perfectly valid solution.
--
Marko Milivojevic - CCIE #18427
Senior Technical Instructor - IPexpert
Mailto: [email protected]
Telephone: +1.810.326.1444
Fax: +1.810.454.0130
R&S Video on Demand Demo: http://bit.ly/aFyrU4
On Fri, Mar 5, 2010 at 20:28, Frank <[email protected]> wrote:
>
> Hi,
>
> I came up with a different solution for the missing LMI and keep-alive
> on the interlinks between R6 and R9.
> Instead of using "no keepalive", you can also make one side of the links
> a FR switch.
>
> For example, if I do:
>
> ? ?interface MFR1
> ? ? no ip address
> ? ? frame-relay intf-type dce ?<=========
> ? ?!
> ? ?interface MFR1.69 point-to-point
> ? ? ip address 150.100.69.9 255.255.255.0
> ? ? frame-relay interface-dlci 69
> ? ?!
> ? ?interface MFR1.96 point-to-point
> ? ? ip address 150.100.96.9 255.255.255.0
> ? ? frame-relay interface-dlci 96
>
> then R9 will act as the FR switch, and R6 and R9 will exchange LMI
> status messages; and you do not have the problem that the PVC's don't
> become active:
>
> R6# sh frame pvc | i ACTIVE.*MFR
> DLCI = 69, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = MFR1.69
> DLCI = 96, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = MFR1.96
>
> R9#sh frame pvc | i ACT
> DLCI = 69, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = MFR1.69
> DLCI = 96, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = MFR1.96
> R9#sh frame map
> MFR1.96 (up): point-to-point dlci, dlci 96(0x60,0x1800), broadcast
> ? ? ? ? ?status defined, active
> MFR1.69 (up): point-to-point dlci, dlci 69(0x45,0x1050), broadcast
> ? ? ? ? ?status defined, active
>
> Questions:
>
> 1) Would this be an acceptable solution (it does not seem to violate any
> requirements)?
>
> 2) Are there any drawbacks to this approach that I'm overlooking?
>
> Regards,
>
> Farnk
>
>
>
>
>
> _______________________________________________
> For more information regarding industry leading CCIE Lab training, please
> visit www.ipexpert.com
>
End of CCIE_RS Digest, Vol 50, Issue 20
***************************************
_______________________________________________
For more information regarding industry leading CCIE Lab training, please visit
www.ipexpert.com
