Re: router as pppoe client in bridging mode

If this was a question in the lab, you would be getting no points,
because the original question specifically calls for bridging on PPPoE
server, R1... :-)

Just sayin'

--
Marko Milivojevic - CCIE #18427
Senior Technical Instructor - IPexpert
FREE CCIE training: http://bit.ly/vLecture
Mailto: markom_at_ipexpert.com
Telephone: +1.810.326.1444
Web: http://www.ipexpert.com/
On Wed, Oct 13, 2010 at 18:33, Adam Booth <adam.booth_at_gmail.com> wrote:
> Hi Garry,
>
> Wouldn't using "dialer persistant" eliminate the need for classifying
> interesting traffic and always activate the dialer interface to callout?
>
> However as it seems you are suggesting, having the PPPoE client bridge it's
> dialer to the ethernet for the end host doesn't resolve things like how does
> the server/client perform dynamic address allocation since the host (R2)
> would use DHCP, and the PPPoE server (R0) IPCP unless the PPPoE bridge (R1)
> can proxy/translate this somehow, as well as proxying ARP requests from R2
> and so on.
>
> From the top of my my head, some alternatives which I'm guessing Koen has
> discarded as they are relatively straightforward:
> 1) As Garry mentioned already - have the PPPoE client running directly on
> the end host (R2), having the bridge bridging frames with Ethertypes of
> 0x8863 and 0x8864
> 2) Reconfig the bridge to act as a router - requiring IP allocation from the
> SP for the end hosts
> 3) Reconfig the bridge to act as a router that performs NAT for the end
> host.
>
> Cheers,
> Adam
>
>
>
> On Thu, Oct 14, 2010 at 5:00 AM, garry baker <baker.garry_at_gmail.com> wrote:
>
>> i dont have a perfectly clear answer for you, but how can the R1 server be
>> the client if it is a bridge?
>>
>> i know it will work if you make R2 the client and let R1 bridge the PPPoE
>> packets between the client R2 and the server R0
>>
>> because i do not see how R1 can be a client and have the bridged traffic
>> made interesting to establish the P2P connection to pass traffic for the
>> 1.1.1.0 subnet between R0 and R2
>>
>> in your setup somehow you need to make the arp coming from R2 interesting
>> traffic in the bridge group to get the PPPoE encapsulation started
>>
>> hope that makes sense
>>
>> i could see this more clearly when i looked at in wireshark and also did a
>> debug of the arp traffic that goes away once you have the pppoe client on
>> R2, because pppoe doesnt use arp it is p2p circuit
>>
>> HTH
>> garry
>>
>> --
>> Garry L. Baker
>>
>> "There is no 'patch' for stupidity." - www.sqlsecurity.com
>>
>>
>> On Wed, Oct 13, 2010 at 1:26 AM, <koen_at_koenzeilstra.com> wrote:
>>
>> > Hi group,
>> >
>> > Below is a challenge i would like to present to you and hope someone can
>> > help me out on this.
>> >
>> > The task is relatively simple.
>> >
>> > There are 3 routers in this scenario
>> >
>> > R0 (f0/0) --- (f0/0) R1 (f1/0) --- (f0/0) R2
>> >
>> > R0 is PPPoE server
>> > R1 is PPPoE client
>> > R2 is simulating a server or pc
>> >
>> > The goal is to have all the public ip addresses configured on R2 and have
>> > R1 act as a bridge. R0 should route it's traffic directly towards R2
>> (over
>> > bridge R1)
>> >
>> > What i have achieved so far:
>> > 1. R1 as PPPoE client
>> > 2. R1 as bridge (without PPPoE)
>> >
>> > The combination does not seem to work.
>> >
>> > 1.1.1.1 is R0
>> > 1.1.1.2 is R2
>> >
>> > R2#ping 1.1.1.1
>> >
>> > Type escape sequence to abort.
>> > Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
>> >
>> > *Mar B 1 00:02:05.639: IP: tableid=0, s=1.1.1.2 (local), d=1.1.1.1
>> > (FastEthernet0/0), routed via RIB
>> > *Mar B 1 00:02:05.639: IP: s=1.1.1.2 (local), d=1.1.1.1 (FastEthernet0/0),
>> > len 100, sending
>> > *Mar B 1 00:02:05.643: IP: s=1.1.1.2 (local), d=1.1.1.1 (FastEthernet0/0),
>> > len 100, encapsulation failed.
>> > *Mar B 1 00:02:07.639: IP: tableid=0, s=1.1.1.2 (local), d=1.1.1.1
>> > (FastEthernet0/0), routed via RIB
>> >
>> >
>> >
>> > Here's the config of R1:
>> >
>> > version 12.4
>> > service timestamps debug datetime msec
>> > service timestamps log datetime msec
>> > no service password-encryption
>> > !
>> > hostname R1
>> > !
>> > boot-start-marker
>> > boot-end-marker
>> > !
>> > !
>> > no aaa new-model
>> > memory-size iomem 5
>> > no ip routing
>> > !
>> > !
>> > no ip cef
>> > no ip domain lookup
>> > !
>> > !
>> > !
>> > !
>> > !
>> > interface FastEthernet0/0
>> > B no ip address
>> > B no ip route-cache
>> > B duplex auto
>> > B speed auto
>> > B pppoe enable group global
>> > B pppoe-client dial-pool-number 1
>> > !
>> > interface FastEthernet1/0
>> > B no ip address
>> > B no ip route-cache
>> > B duplex auto
>> > B speed auto
>> > B bridge-group 1
>> > !
>> > interface Dialer1
>> > B no ip address
>> > B encapsulation ppp
>> > B no ip route-cache
>> > B dialer pool 1
>> > B dialer-group 1
>> > B ppp pap sent-username TEST password 0 TEST
>> > B bridge-group 1
>> > !
>> > ip http server
>> > ip forward-protocol nd
>> > !
>> > !
>> > !
>> > !
>> > !
>> > !
>> > control-plane
>> > !
>> > bridge 1 protocol ieee
>> > !
>> > !
>> > !
>> > !
>> > !
>> > !
>> > !
>> > !
>> > line con 0
>> > B logging synchronous
>> > line aux 0
>> > line vty 0 4
>> > B login
>> > !
>> > !
>> > end
>> >
>> >
>> > Any help is appreciated.
>> >
>> > Thanks in advance,
>> >
>> > Koen
>> >
>> >
>> > Blogs and organic groups at http://www.ccie.net
>> >
>> > _______________________________________________________________________
>> > Subscription information may be found at:
>> > http://www.groupstudy.com/list/CCIELab.html
>>
>>
>> Blogs and organic groups at http://www.ccie.net
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
Blogs and organic groups at http://www.ccie.net