Hi Tyson, Perhaps the question is related to how the pppoe client obtains and uses it's subnet mask depending on how you specify the addressing mode?
I've found that even though my client would negotiate its IP address via IPCP and request the netmask, it wouldn't use it (requiring the client RIP config needed to have no validate-update-source so that RIP updates from the PPPoE Server are accepted) unless I changed the client dialer interface to use "ip address dhcp" instead of what appears to be the more applicable "ip address negotiated" This is a config that works for me PPPoE Server --------------------- aaa new-model aaa authentication ppp default local ip dhcp excluded-address 172.16.1.254 ip dhcp pool pppoe network 172.16.1.0 255.255.255.0 username client password 0 pppoe bba-group pppoe global virtual-template 1 interface Loopback0 ip address 1.1.1.1 255.255.255.255 ! interface Loopback30 ip address 11.1.1.1 255.255.255.0 ! interface FastEthernet0/0.20 encapsulation dot1Q 20 ip address 172.16.1.254 255.255.255.0 pppoe enable group global ! interface Virtual-Template1 ip unnumbered FastEthernet0/0.20 peer default ip address dhcp-pool pppoe ppp authentication chap callin ppp ipcp mask 255.255.255.0 ! router rip version 2 redistribute connected metric 5 passive-interface default no passive-interface Virtual-Template1 network 172.16.0.0 no auto-summary ! PPPoE Client -------------------- interface Loopback0 ip address 2.2.2.2 255.255.255.255 ! interface FastEthernet0/0.20 encapsulation dot1Q 20 pppoe enable group global pppoe-client dial-pool-number 1 ! interface Dialer1 ip address dhcp encapsulation ppp dialer pool 1 dialer idle-timeout 0 dialer persistent ppp authentication chap callin ppp chap hostname client ppp chap password 0 pppoe ppp ipcp mask request ! router rip version 2 redistribute connected metric 5 passive-interface default no passive-interface Dialer1 network 172.16.0.0 no auto-summary ! If the Dialer1 interface was "ip address negotiated" with debug rip I would see *Aug 19 10:08:09.399: RIP: ignored v2 update from bad source 172.16.1.254 on Dialer1 Cheers, Adam On Thu, Aug 19, 2010 at 8:24 AM, Tyson Scott <[email protected]> wrote: > passive interface for loopback to prevent from sending unnecessary > updates out an interface that is not going to communicate with other > devices. > > > > I am not sure on your first question what you are asking about. > > > > If I am understanding you properly having or not having the /32 neighbor > route shouldn't affect RIP. > > > > Regards, > > > > Tyson Scott - CCIE #13513 R&S, Security, and SP > > Managing Partner / Sr. Instructor - IPexpert, Inc. > > Mailto: [email protected] > > Telephone: +1.810.326.1444, ext. 208 > > Live Assistance, Please visit: www.ipexpert.com/chat > > eFax: +1.810.454.0130 > > > > IPexpert is a premier provider of Self-Study Workbooks, Video on Demand, > Audio Tools, Online Hardware Rental and Classroom Training for the Cisco > CCIE (R&S, Voice, Security & Service Provider) certification(s) with > training locations throughout the United States, Europe, South Asia and > Australia. Be sure to visit our online communities at > www.ipexpert.com/communities and our public website at www.ipexpert.com > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Quentin Huberty > *Sent:* Wednesday, August 18, 2010 1:32 PM > *To:* [email protected] > *Cc:* [email protected] > *Subject:* [OSL | CCIE_RS] PPPoE > > > > Hi Marko, > > > > Can you tell me if disable 'peer neighbor-route' with PPPoE can influence > RIP routing ? > > Why sometimes put 'passive-interface' for loopback ? > > > > Rgds, Quentin > > > ####################################################################################### > This e-mail and any attached files are confidential and may be legally > privileged. > If you are not the addressee, any disclosure, reproduction, copying, > distribution, > or other dissemination or use of this communication is strictly prohibited. > If you have received this transmission in error please notify Simac PSF > S.A. immediately > and then delete this e-mail. > > Simac PSF S.A. has taken all reasonable precautions to avoid virusses in > this email. > Simac PSF S.A. does not accept liability for damage by virusses, for the > correct and complete > transmission of the information, nor for any delay or interruption of the > transmission, > nor for damages arising from the use of or reliance on the information. > > All e-mail messages addressed to, received or sent by Simac PSF S.A. or > Simac PSF S.A. employees > are deemed to be professional in nature. Accordingly, the sender or > recipient of > these messages agrees that they may be read by other Simac PSF S.A. > employees than the official > recipient or sender in order to ensure the continuity of work-related > activities > and allow supervision thereof. > > ###################################################################################### > > _______________________________________________ > For more information regarding industry leading CCIE Lab training, please > visit www.ipexpert.com > >
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
