Did you have the prefix in the topology table of 12348 before the offset list?
 

> From: [email protected]
> Subject: CCIE_RS Digest, Vol 76, Issue 33
> To: [email protected]
> Date: Thu, 10 May 2012 08:55:34 -0400
> 
> 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: My Story CCIE#35355 (Marko Milivojevic)
> 2. A quick Check on Lab 30 (VOL1) (varan)
> 3. Re: My Story CCIE#35355 (Thomas Raabo - Zitcom A/S)
> 4. 15.29 (khaled al-ajeman)
> 5. Native Vlan (imad Abdallah)
> 6. Re: EIGRP Authentication again!! (Adam Booth)
> 7. Re: Native Vlan (Rob Hoover)
> 8. Re: EIGRP Authentication again!! (Jay McMickle)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Wed, 9 May 2012 19:22:57 -0700
> From: Marko Milivojevic <[email protected]>
> To: marc abel <[email protected]>
> Cc: [email protected]
> Subject: Re: [OSL | CCIE_RS] My Story CCIE#35355
> Message-ID:
> <cagdym0w0rpn733u+elhn9qf9p79myq6usnisqeum1sdwx0m...@mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
> 
> On Wed, May 9, 2012 at 7:06 PM, marc abel <[email protected]> wrote:
> > Well Marko the good news is there is less than a 1% chance any woman is
> > reading this list. The bad news is your wife is way out of your league so
> > she may leave you anyway. :)
> 
> :-))))
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Thu, 10 May 2012 13:44:35 +0800
> From: varan <[email protected]>
> To: [email protected]
> Subject: [OSL | CCIE_RS] A quick Check on Lab 30 (VOL1)
> Message-ID:
> <CALz97=oqnz3dmd14px+28h08239gtv1vokdmxe4tza1joyd...@mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> Hi,
> 
> A quick check on LAB30 VOL1 and please help to clarify. I'm currently
> doing LAB30 and managed to follow all the steps without any issues,
> however the step to configure MDT (Section 30.9), my router doesn't
> accepts the command. I'm running this Lab using GNS3 and I'm getting
> the following error.
> 
> R2(config-subif)#router bgp 256
> R2(config-router)#
> R2(config-router)#
> R2(config-router)#addre
> R2(config-router)#address-family ipv4 mdt
> ^
> % Invalid input detected at '^' marker.
> 
> What could be the issue here.... Do I need a more recent IOS as
> currently I'm using
> 
> R2(config-router)#do show ver
> Cisco IOS Software, 3700 Software (C3725-ADVENTERPRISEK9-M), Version
> 12.4(15)T8, RELEASE SOFTWARE (fc3)
> Technical Support: http://www.cisco.com/techsupport
> Copyright (c) 1986-2008 by Cisco Systems, Inc.
> Compiled Mon 01-Dec-08 19:46 by prod_rel_team
> 
> Thanks
> Yis
> 
> 
> ------------------------------
> 
> Message: 3
> Date: Thu, 10 May 2012 06:45:19 +0000
> From: Thomas Raabo - Zitcom A/S <[email protected]>
> To: Marko Milivojevic <[email protected]>, marc abel
> <[email protected]>
> Cc: "[email protected]" <[email protected]>
> Subject: Re: [OSL | CCIE_RS] My Story CCIE#35355
> Message-ID:
> <[email protected]>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> :) true...
> 
> -----Oprindelig meddelelse-----
> Fra: [email protected] 
> [mailto:[email protected]] P? vegne af Marko Milivojevic
> Sendt: 10. maj 2012 04:23
> Til: marc abel
> Cc: [email protected]
> Emne: Re: [OSL | CCIE_RS] My Story CCIE#35355
> 
> On Wed, May 9, 2012 at 7:06 PM, marc abel <[email protected]> wrote:
> > Well Marko the good news is there is less than a 1% chance any woman 
> > is reading this list. The bad news is your wife is way out of your 
> > league so she may leave you anyway. :)
> 
> :-))))
> _______________________________________________
> 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: Thu, 10 May 2012 11:19:26 +0300
> From: khaled al-ajeman <[email protected]>
> To: [email protected]
> Subject: [OSL | CCIE_RS] 15.29
> Message-ID:
> <CACv-o9u_juZDsGX6aNHEsCPK3G5zGkW=3wkkrcwxaz3dbzd...@mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> Hi there,
> 
> Can anyone help me, why I am not being able to see my BB1 routes going via
> 100.100.100.100 instead of going through CAT through the routes
> 150.101.81.108,
> 
> here is my configuration
> 
> R8
> 
> R8(config-if)#DO sir 100.100.100.100
> --------------------------------------------> bb1 route
> Routing entry for 100.100.100.0/24
> Known via "eigrp 7800", distance 170, metric 2560512256
> ---------------> It suppose to be eigrp 12348 before I add up
> the offest-list command
> Tag 120, type external
> Redistributing via eigrp 7800
> Last update from 150.100.78.7 on Serial0/0, 00:12:18 ago
> Routing Descriptor Blocks:
> * 150.100.78.7, from 150.100.78.7, 00:12:18 ago, via Serial0/0
> Route metric is 2560512256, traffic share count is 1
> Total delay is 20010 microseconds, minimum bandwidth is 1 Kbit
> Reliability 1/255, minimum MTU 1 bytes
> Loading 1/255, Hops 1
> Route tag 120
> .
> 
> R8
> router eigrp 12348
> passive-interface default
> no passive-interface Serial0/1
> offset-list 0 in 512000
> FastEthernet0/0 --------------------------------> offest-list command
> does change the route path of my backbone routes
> network 150.50.81.0 0.0.0.255
> network 150.100.81.0 0.0.0.255
> My question for you fellas, why am I not being able to see the path route
> of the backbone route 100.100.100.100 going throught the cat 1 ( eigrp
> 12348) by default before
> I configuer the offe-list statement? any thoughts
> 
> 
> 
> thanks to you all,
> 
> khaled
> 
> 
> ------------------------------
> 
> Message: 5
> Date: Thu, 10 May 2012 11:25:39 +0300
> From: imad Abdallah <[email protected]>
> To: <[email protected]>
> Subject: [OSL | CCIE_RS] Native Vlan
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> 
> Hi,I'm bit confused regarding native vlan and trunk allowed vlan. Let's say 
> we have two switches connected via trunk. Both switches have the default 
> native vlan (vlan 1). On the trunk between them, we issued the command: swi 
> trun allo vlan 2-100. So the native vlan 1 is not allowed on the trunk. is it 
> mandatory for the native vlan to be allowed on thee trunk? Do we need to 
> change the native vlan from (1) to any other vlan that are allowed through 
> the trunk? Thanks 
> 
> ------------------------------
> 
> Message: 6
> Date: Thu, 10 May 2012 22:09:58 +1000
> From: Adam Booth <[email protected]>
> To: Jay McMickle <[email protected]>
> Cc: IPExpert Study List <[email protected]>
> Subject: Re: [OSL | CCIE_RS] EIGRP Authentication again!!
> Message-ID:
> <cakxsbmqpjix1i3s29rx8wjetgzcdx-hjvja+fa_3jcwj8k3...@mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> I was bored and wanted to get my hands a little dirty with radius
> again so I decided to try labbing this up using PPPoE with a single
> virtual-template, you need to pre-configure the keys for the spokes on
> the PPPoE Server and RADIUS (through authorization) tells the server
> what key should be attached to the virtual-access interface..
> 
> 
> Configurations:
> 
> hostname R1
> aaa new-model
> aaa authentication login default none
> aaa authentication enable default none
> aaa authentication ppp default group radius
> aaa authorization network default group radius
> !
> key chain R1-R2
> key 1
> key-string cisco
> key chain R1-R3
> key 1
> key-string ccie
> !
> bba-group pppoe global
> virtual-template 1
> !
> interface FastEthernet0/0
> description To Ethernet Switch
> no ip address
> duplex auto
> speed auto
> pppoe enable group global
> !
> interface Virtual-Template1
> ip address 1.0.0.1 255.255.255.0
> ip authentication mode eigrp 123 md5
> peer default ip address pool PPPoE
> ppp authentication chap
> !
> router eigrp 123
> network 1.0.0.0 0.0.0.255
> no auto-summary
> !
> ip local pool PPPoE 1.0.0.2 1.0.0.254
> !
> radius-server host 192.168.100.253 auth-port 1812 acct-port 1813 key cisco
> 
> 
> 
> hostname R2
> key chain R1-R2
> key 1
> key-string cisco
> !
> interface FastEthernet0/0
> description To Ethernet Switch
> no ip address
> duplex auto
> speed auto
> pppoe enable
> pppoe-client dial-pool-number 1
> !
> interface Dialer1
> ip address negotiated
> ip authentication mode eigrp 123 md5
> ip authentication key-chain eigrp 123 R1-R2
> encapsulation ppp
> dialer pool 1
> dialer idle-timeout 0
> dialer persistent
> ppp chap hostname R2
> ppp chap password 0 R2
> !
> router eigrp 123
> network 1.0.0.0 0.0.0.255
> no auto-summary
> !
> 
> 
> hostname R3
> key chain R1-R3
> key 1
> key-string ccie
> !
> interface FastEthernet0/0
> description To Ethernet Switch
> no ip address
> duplex auto
> speed auto
> pppoe enable
> pppoe-client dial-pool-number 1
> !
> interface Dialer1
> ip address negotiated
> ip authentication mode eigrp 123 md5
> ip authentication key-chain eigrp 123 R1-R3
> encapsulation ppp
> dialer pool 1
> dialer idle-timeout 0
> dialer persistent
> ppp chap hostname R3
> ppp chap password 0 R3
> !
> router eigrp 123
> network 1.0.0.0 0.0.0.255
> no auto-summary
> !
> 
> 
> radius-server:~# cat /etc/freeradius/users
> R2 Cleartext-Password := "R2"
> Service-Type = Framed-User,
> Framed-Protocol = PPP,
> cisco-avpair = "lcp:interface-config=ip authentication
> key-chain eigrp 123 R1-R2"
> 
> R3 Cleartext-Password := "R3"
> Service-Type = Framed-User,
> Framed-Protocol = PPP,
> cisco-avpair = "lcp:interface-config=ip authentication
> key-chain eigrp 123 R1-R3"
> 
> 
> Verification:
> 
> R1#sh pppoe session all
> Total PPPoE sessions 2
> 
> 
> session id: 19
> local MAC address: c200.0740.0000, remote MAC address: c201.0740.0000
> virtual access interface: Vi3, outgoing interface: Fa0/0
> 424 packets sent, 425 received
> 25488 bytes sent, 25558 received
> 
> session id: 20
> local MAC address: c200.0740.0000, remote MAC address: c202.0740.0000
> virtual access interface: Vi4, outgoing interface: Fa0/0
> 274 packets sent, 274 received
> 16475 bytes sent, 16626 received
> 
> R1#sh ip route | b Gate
> Gateway of last resort is not set
> 
> 1.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
> C 1.0.0.0/24 is directly connected, Virtual-Access3
> is directly connected, Virtual-Access4
> C 1.0.0.3/32 is directly connected, Virtual-Access4
> C 1.0.0.2/32 is directly connected, Virtual-Access3
> C 192.168.100.0/24 is directly connected, FastEthernet1/0
> 
> R1#sh ip eigrp interfaces detail | i ^V|Authentication
> Vt1 0 0/0 0 0/1 0 0
> Authentication mode is md5, key-chain is not set
> Vi3 1 0/0 28 0/1 129 0
> Authentication mode is md5, key-chain is "R1-R2"
> Vi4 1 0/0 37 0/1 209 0
> Authentication mode is md5, key-chain is "R1-R3"
> 
> R2#sh ip route | b Gate
> Gateway of last resort is not set
> 
> 1.0.0.0/32 is subnetted, 3 subnets
> C 1.0.0.1 is directly connected, Dialer1
> D 1.0.0.3 [90/48786176] via 1.0.0.1, 00:13:23
> C 1.0.0.2 is directly connected, Dialer1
> R2#sh ip eigrp interfaces detail
> IP-EIGRP interfaces for process 123
> 
> Xmit Queue Mean Pacing Time Multicast Pending
> Interface Peers Un/Reliable SRTT Un/Reliable Flow Timer Routes
> Di1 1 0/0 11 11/434 50 0
> Hello interval is 5 sec
> Next xmit serial <none>
> Un/reliable mcasts: 0/3 Un/reliable ucasts: 3/2
> Mcast exceptions: 0 CR packets: 0 ACKs suppressed: 0
> Retransmissions sent: 0 Out-of-sequence rcvd: 0
> Authentication mode is md5, key-chain is "R1-R2"
> Use multicast
> R2#show key chain R1-R2
> Key-chain R1-R2:
> key 1 -- text "cisco"
> accept lifetime (always valid) - (always valid) [valid now]
> send lifetime (always valid) - (always valid) [valid now]
> 
> R3#sh ip route | b Gate
> Gateway of last resort is not set
> 
> 1.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
> C 1.0.0.1/32 is directly connected, Dialer1
> D 1.0.0.0/24 [90/48786176] via 1.0.0.1, 00:14:45
> C 1.0.0.3/32 is directly connected, Dialer1
> D 1.0.0.2/32 [90/48786176] via 1.0.0.1, 00:14:45
> R3#show ip eigrp interfaces detail
> IP-EIGRP interfaces for process 123
> 
> Xmit Queue Mean Pacing Time Multicast Pending
> Interface Peers Un/Reliable SRTT Un/Reliable Flow Timer Routes
> Di1 1 0/0 19 11/434 68 0
> Hello interval is 5 sec
> Next xmit serial <none>
> Un/reliable mcasts: 0/2 Un/reliable ucasts: 1/3
> Mcast exceptions: 1 CR packets: 1 ACKs suppressed: 0
> Retransmissions sent: 0 Out-of-sequence rcvd: 0
> Authentication mode is md5, key-chain is "R1-R3"
> Use multicast
> R3#show key chain R1-R3
> Key-chain R1-R3:
> key 1 -- text "ccie"
> accept lifetime (always valid) - (always valid) [valid now]
> send lifetime (always valid) - (always valid) [valid now]
> 
> R3#ping 1.0.0.1
> 
> Type escape sequence to abort.
> Sending 5, 100-byte ICMP Echos to 1.0.0.1, timeout is 2 seconds:
> !!!!!
> Success rate is 100 percent (5/5), round-trip min/avg/max = 4/8/28 ms
> R3#ping 1.0.0.2
> 
> Type escape sequence to abort.
> Sending 5, 100-byte ICMP Echos to 1.0.0.2, timeout is 2 seconds:
> !!!!!
> Success rate is 100 percent (5/5), round-trip min/avg/max = 8/10/16 ms
> R3#trace 1.0.0.2
> 
> Type escape sequence to abort.
> Tracing the route to 1.0.0.2
> 
> 1 1.0.0.1 4 msec 16 msec 4 msec
> 2 1.0.0.2 12 msec 8 msec *
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Wed, May 9, 2012 at 8:08 AM, Jay McMickle <[email protected]> wrote:
> > You must use a diaper for the virtual-template and PPPoE.
> >
> > Regards,
> > Jay McMickle- CCIE #35355
> > Sent from iJay
> >
> > On May 7, 2012, at 7:31 PM, George Leslie <[email protected]> 
> > wrote:
> >
> >>
> >>
> >>
> >>
> >> Hello all,Jay McM and I had an offline chat about my previous posting, 
> >> which was trying to do the EIGRP authentication on a hub and spoke 
> >> network, where the hubs use different authentication keys from each other. 
> >> ?I was playing around with frame hub and spoke. To recap, I previously 
> >> found that the hub, despite having the two different keys in its key 
> >> chain, both of which had valid lifetimes, refused to send using key 2. ?It 
> >> would only send with key 1 despite correctly authentication spoke 2 which 
> >> was using key 2. ?Therefore, hub authenticated spoke, but not vice versa. 
> >> On frame, you could use PPPoFr, and use different virtual templates on 
> >> each DLCI, and therefore have different key chains on each. ?What I 
> >> actually did was use point to point tunnels over the frame, which worked a 
> >> treat. In what my old physics teacher used to call, "a thought 
> >> experiment", I was thinking about what you could do, just on a bog 
> >> standard Ethernet segment. ?The tunnel approach would still work.
  ?
> H
> > ?ow
> >> ever, with PPPoE, the server virtual template is tied to the physical, via 
> >> the bba-group. ?Therefore the key chain would be applied to all clients 
> >> that use the virtual template, which presents the same problem as on the 
> >> frame network. My question: is there any way that you can configure a 
> >> PPPoE virtual template on the hub that is somehow tied to each individual 
> >> client? ?For example, is there a mechanism to tie the virtual template to 
> >> the PPP chap username? ?Bit of chicken and egg here, as you need the 
> >> virtual template to know to authenticate by chap, but need chap to know 
> >> the virtual template to apply.....My head hurts. Regards, George.
> >> _______________________________________________
> >> 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
> 
> 
> ------------------------------
> 
> Message: 7
> Date: Thu, 10 May 2012 08:33:36 -0400
> From: Rob Hoover <[email protected]>
> To: imad Abdallah <[email protected]>
> Cc: [email protected]
> Subject: Re: [OSL | CCIE_RS] Native Vlan
> Message-ID:
> <caasacxj8eeoxrdy53bht96behyy-4besgyfqjh2y0wjbfmc...@mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> You have to list the native VLAN in the allowed statement or the packet
> will be dropped.
> On May 10, 2012 3:31 AM, "imad Abdallah" <[email protected]> wrote:
> 
> >
> > Hi,I'm bit confused regarding native vlan and trunk allowed vlan. Let's
> > say we have two switches connected via trunk. Both switches have the
> > default native vlan (vlan 1). On the trunk between them, we issued the
> > command: swi trun allo vlan 2-100. So the native vlan 1 is not allowed on
> > the trunk. is it mandatory for the native vlan to be allowed on thee trunk?
> > Do we need to change the native vlan from (1) to any other vlan that are
> > allowed through the trunk? 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: 8
> Date: Thu, 10 May 2012 07:55:27 -0500
> From: Jay McMickle <[email protected]>
> To: Adam Booth <[email protected]>
> Cc: IPExpert Study List <[email protected]>
> Subject: Re: [OSL | CCIE_RS] EIGRP Authentication again!!
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=us-ascii
> 
> Yuk! You are a masochist!
> 
> Very nice of you to lab up for George. We need about 100 of you on this DL.
> 
> Thanks!
> 
> Regards,
> Jay McMickle- CCIE #35355
> Sent from iJay
> 
> On May 10, 2012, at 7:09 AM, Adam Booth <[email protected]> wrote:
> 
> > I was bored and wanted to get my hands a little dirty with radius
> > again so I decided to try labbing this up using PPPoE with a single
> > virtual-template, you need to pre-configure the keys for the spokes on
> > the PPPoE Server and RADIUS (through authorization) tells the server
> > what key should be attached to the virtual-access interface..
> > 
> > 
> > Configurations:
> > 
> > hostname R1
> > aaa new-model
> > aaa authentication login default none
> > aaa authentication enable default none
> > aaa authentication ppp default group radius
> > aaa authorization network default group radius
> > !
> > key chain R1-R2
> > key 1
> > key-string cisco
> > key chain R1-R3
> > key 1
> > key-string ccie
> > !
> > bba-group pppoe global
> > virtual-template 1
> > !
> > interface FastEthernet0/0
> > description To Ethernet Switch
> > no ip address
> > duplex auto
> > speed auto
> > pppoe enable group global
> > !
> > interface Virtual-Template1
> > ip address 1.0.0.1 255.255.255.0
> > ip authentication mode eigrp 123 md5
> > peer default ip address pool PPPoE
> > ppp authentication chap
> > !
> > router eigrp 123
> > network 1.0.0.0 0.0.0.255
> > no auto-summary
> > !
> > ip local pool PPPoE 1.0.0.2 1.0.0.254
> > !
> > radius-server host 192.168.100.253 auth-port 1812 acct-port 1813 key cisco
> > 
> > 
> > 
> > hostname R2
> > key chain R1-R2
> > key 1
> > key-string cisco
> > !
> > interface FastEthernet0/0
> > description To Ethernet Switch
> > no ip address
> > duplex auto
> > speed auto
> > pppoe enable
> > pppoe-client dial-pool-number 1
> > !
> > interface Dialer1
> > ip address negotiated
> > ip authentication mode eigrp 123 md5
> > ip authentication key-chain eigrp 123 R1-R2
> > encapsulation ppp
> > dialer pool 1
> > dialer idle-timeout 0
> > dialer persistent
> > ppp chap hostname R2
> > ppp chap password 0 R2
> > !
> > router eigrp 123
> > network 1.0.0.0 0.0.0.255
> > no auto-summary
> > !
> > 
> > 
> > hostname R3
> > key chain R1-R3
> > key 1
> > key-string ccie
> > !
> > interface FastEthernet0/0
> > description To Ethernet Switch
> > no ip address
> > duplex auto
> > speed auto
> > pppoe enable
> > pppoe-client dial-pool-number 1
> > !
> > interface Dialer1
> > ip address negotiated
> > ip authentication mode eigrp 123 md5
> > ip authentication key-chain eigrp 123 R1-R3
> > encapsulation ppp
> > dialer pool 1
> > dialer idle-timeout 0
> > dialer persistent
> > ppp chap hostname R3
> > ppp chap password 0 R3
> > !
> > router eigrp 123
> > network 1.0.0.0 0.0.0.255
> > no auto-summary
> > !
> > 
> > 
> > radius-server:~# cat /etc/freeradius/users
> > R2 Cleartext-Password := "R2"
> > Service-Type = Framed-User,
> > Framed-Protocol = PPP,
> > cisco-avpair = "lcp:interface-config=ip authentication
> > key-chain eigrp 123 R1-R2"
> > 
> > R3 Cleartext-Password := "R3"
> > Service-Type = Framed-User,
> > Framed-Protocol = PPP,
> > cisco-avpair = "lcp:interface-config=ip authentication
> > key-chain eigrp 123 R1-R3"
> > 
> > 
> > Verification:
> > 
> > R1#sh pppoe session all
> > Total PPPoE sessions 2
> > 
> > 
> > session id: 19
> > local MAC address: c200.0740.0000, remote MAC address: c201.0740.0000
> > virtual access interface: Vi3, outgoing interface: Fa0/0
> > 424 packets sent, 425 received
> > 25488 bytes sent, 25558 received
> > 
> > session id: 20
> > local MAC address: c200.0740.0000, remote MAC address: c202.0740.0000
> > virtual access interface: Vi4, outgoing interface: Fa0/0
> > 274 packets sent, 274 received
> > 16475 bytes sent, 16626 received
> > 
> > R1#sh ip route | b Gate
> > Gateway of last resort is not set
> > 
> > 1.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
> > C 1.0.0.0/24 is directly connected, Virtual-Access3
> > is directly connected, Virtual-Access4
> > C 1.0.0.3/32 is directly connected, Virtual-Access4
> > C 1.0.0.2/32 is directly connected, Virtual-Access3
> > C 192.168.100.0/24 is directly connected, FastEthernet1/0
> > 
> > R1#sh ip eigrp interfaces detail | i ^V|Authentication
> > Vt1 0 0/0 0 0/1 0 0
> > Authentication mode is md5, key-chain is not set
> > Vi3 1 0/0 28 0/1 129 0
> > Authentication mode is md5, key-chain is "R1-R2"
> > Vi4 1 0/0 37 0/1 209 0
> > Authentication mode is md5, key-chain is "R1-R3"
> > 
> > R2#sh ip route | b Gate
> > Gateway of last resort is not set
> > 
> > 1.0.0.0/32 is subnetted, 3 subnets
> > C 1.0.0.1 is directly connected, Dialer1
> > D 1.0.0.3 [90/48786176] via 1.0.0.1, 00:13:23
> > C 1.0.0.2 is directly connected, Dialer1
> > R2#sh ip eigrp interfaces detail
> > IP-EIGRP interfaces for process 123
> > 
> > Xmit Queue Mean Pacing Time Multicast Pending
> > Interface Peers Un/Reliable SRTT Un/Reliable Flow Timer Routes
> > Di1 1 0/0 11 11/434 50 0
> > Hello interval is 5 sec
> > Next xmit serial <none>
> > Un/reliable mcasts: 0/3 Un/reliable ucasts: 3/2
> > Mcast exceptions: 0 CR packets: 0 ACKs suppressed: 0
> > Retransmissions sent: 0 Out-of-sequence rcvd: 0
> > Authentication mode is md5, key-chain is "R1-R2"
> > Use multicast
> > R2#show key chain R1-R2
> > Key-chain R1-R2:
> > key 1 -- text "cisco"
> > accept lifetime (always valid) - (always valid) [valid now]
> > send lifetime (always valid) - (always valid) [valid now]
> > 
> > R3#sh ip route | b Gate
> > Gateway of last resort is not set
> > 
> > 1.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
> > C 1.0.0.1/32 is directly connected, Dialer1
> > D 1.0.0.0/24 [90/48786176] via 1.0.0.1, 00:14:45
> > C 1.0.0.3/32 is directly connected, Dialer1
> > D 1.0.0.2/32 [90/48786176] via 1.0.0.1, 00:14:45
> > R3#show ip eigrp interfaces detail
> > IP-EIGRP interfaces for process 123
> > 
> > Xmit Queue Mean Pacing Time Multicast Pending
> > Interface Peers Un/Reliable SRTT Un/Reliable Flow Timer Routes
> > Di1 1 0/0 19 11/434 68 0
> > Hello interval is 5 sec
> > Next xmit serial <none>
> > Un/reliable mcasts: 0/2 Un/reliable ucasts: 1/3
> > Mcast exceptions: 1 CR packets: 1 ACKs suppressed: 0
> > Retransmissions sent: 0 Out-of-sequence rcvd: 0
> > Authentication mode is md5, key-chain is "R1-R3"
> > Use multicast
> > R3#show key chain R1-R3
> > Key-chain R1-R3:
> > key 1 -- text "ccie"
> > accept lifetime (always valid) - (always valid) [valid now]
> > send lifetime (always valid) - (always valid) [valid now]
> > 
> > R3#ping 1.0.0.1
> > 
> > Type escape sequence to abort.
> > Sending 5, 100-byte ICMP Echos to 1.0.0.1, timeout is 2 seconds:
> > !!!!!
> > Success rate is 100 percent (5/5), round-trip min/avg/max = 4/8/28 ms
> > R3#ping 1.0.0.2
> > 
> > Type escape sequence to abort.
> > Sending 5, 100-byte ICMP Echos to 1.0.0.2, timeout is 2 seconds:
> > !!!!!
> > Success rate is 100 percent (5/5), round-trip min/avg/max = 8/10/16 ms
> > R3#trace 1.0.0.2
> > 
> > Type escape sequence to abort.
> > Tracing the route to 1.0.0.2
> > 
> > 1 1.0.0.1 4 msec 16 msec 4 msec
> > 2 1.0.0.2 12 msec 8 msec *
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > On Wed, May 9, 2012 at 8:08 AM, Jay McMickle <[email protected]> wrote:
> >> You must use a diaper for the virtual-template and PPPoE.
> >> 
> >> Regards,
> >> Jay McMickle- CCIE #35355
> >> Sent from iJay
> >> 
> >> On May 7, 2012, at 7:31 PM, George Leslie <[email protected]> 
> >> wrote:
> >> 
> >>> 
> >>> 
> >>> 
> >>> 
> >>> Hello all,Jay McM and I had an offline chat about my previous posting, 
> >>> which was trying to do the EIGRP authentication on a hub and spoke 
> >>> network, where the hubs use different authentication keys from each 
> >>> other. I was playing around with frame hub and spoke. To recap, I 
> >>> previously found that the hub, despite having the two different keys in 
> >>> its key chain, both of which had valid lifetimes, refused to send using 
> >>> key 2. It would only send with key 1 despite correctly authentication 
> >>> spoke 2 which was using key 2. Therefore, hub authenticated spoke, but 
> >>> not vice versa. On frame, you could use PPPoFr, and use different virtual 
> >>> templates on each DLCI, and therefore have different key chains on each. 
> >>> What I actually did was use point to point tunnels over the frame, which 
> >>> worked a treat. In what my old physics teacher used to call, "a thought 
> >>> experiment", I was thinking about what you could do, just on a bog 
> >>> standard Ethernet segment. The tunnel approach would still work. 
> H
> >> ow
> >>> ever, with PPPoE, the server virtual template is tied to the physical, 
> >>> via the bba-group. Therefore the key chain would be applied to all 
> >>> clients that use the virtual template, which presents the same problem as 
> >>> on the frame network. My question: is there any way that you can 
> >>> configure a PPPoE virtual template on the hub that is somehow tied to 
> >>> each individual client? For example, is there a mechanism to tie the 
> >>> virtual template to the PPP chap username? Bit of chicken and egg here, 
> >>> as you need the virtual template to know to authenticate by chap, but 
> >>> need chap to know the virtual template to apply.....My head hurts. 
> >>> Regards, George.
> >>> _______________________________________________
> >>> 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 33
> ***************************************
                                          
_______________________________________________
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