PPPPOE-Server: Problem mit Virtual-Templates

[Lagerhaus_Jonny 10]

Hi Leute.

 

Ich habe ein Problem mit den Virtual-Templates auf nem Router.

Und zwar habe ich einen einfachen Aufbau aus drei Routern.

Client - Wan-Router - Client.

Die Clients sind über PPPOE Verbunden und sollen vom Wan-Router eine statische IP über PPP (nicht DHCP !) bekommen, damit ich so einen business-DSL Anschluss simulieren kann.

Mit einem Router klappt das ganze auch wunderbar, das Dialer-Interface kriegt eine statische IP vom WAN-Router.

Kommt jetzt aber der zweite dazu, kriegt er keine mehr.

Das Problem habe ich gefunden, nicht aber eine Lösung.

Aber hier erstmal die Config vom WAN-Router:

bba-group pppoe bras-demo
virtual-template 1
!
bba-group pppoe bras-demo2
virtual-template 2
!
!
interface Loopback0
no ip address
!
interface Loopback1
no ip address
!
interface FastEthernet0/0
ip address 87.32.75.33 255.255.255.240
ip nat inside
duplex auto
speed auto
pppoe enable group bras-demo2
!
interface FastEthernet0/1
ip address 85.130.56.231 255.0.0.0
ip nat inside
duplex auto
speed auto
pppoe enable group bras-demo
!
interface Virtual-Template1
mtu 1492
ip unnumbered Loopback0
peer default ip address pool bras-pool
no keepalive
ppp authentication chap
!
interface Virtual-Template2
mtu 1492
ip unnumbered Loopback1
peer default ip address pool bras-pool2
no keepalive
ppp authentication chap
!
ip local pool bras-pool2 87.32.75.32 group bras-demo2
ip local pool bras-pool 85.130.214.156 group bras-demo

–

Und so sieht das PPP-Debugging aus, wenn der Client erfolgreich eine IP aus einem Pool zugewiesen bekommt:

 

*Mar 13 22:12:14.667: ppp20 PPP: Received LOGIN Response PASS
*Mar 13 22:12:14.667: ppp20 PPP: Phase is FORWARDING, Attempting Forward
*Mar 13 22:12:14.667: ppp20 PPP: Send Message[Connect Local]
*Mar 13 22:12:14.675: ppp20 PPP: Bind to [Virtual-Access1.1]
*Mar 13 22:12:14.675: Vi1.1 PPP: Send Message[static Bind Response]
*Mar 13 22:12:14.675: Vi1.1 PPP: Phase is AUTHENTICATING, Authenticated User
*Mar 13 22:12:14.675: Vi1.1 PPP: Sent LCP AUTHOR Request
*Mar 13 22:12:14.679: Vi1.1 PPP: Sent IPCP AUTHOR Request
*Mar 13 22:12:14.679: Vi1.1 LCP: Received AAA AUTHOR Response PASS
*Mar 13 22:12:14.679: Vi1.1 IPCP: Received AAA AUTHOR Response PASS
*Mar 13 22:12:14.679: Vi1.1 CHAP: O SUCCESS id 1 len 4
*Mar 13 22:12:14.679: Vi1.1 PPP: Phase is UP
*Mar 13 22:12:14.679: Vi1.1 IPCP: O CONFREQ [Closed] id 1 len 10
*Mar 13 22:12:14.683: Vi1.1 IPCP:    Address 87.32.75.33 (0x030657204B21)
*Mar 13 22:12:14.683: Vi1.1 PPP: Process pending ncp packets
*Mar 13 22:12:14.683: Vi1.1 IPCP: I CONFREQ [REQsent] id 1 len 10
*Mar 13 22:12:14.683: Vi1.1 IPCP:    Address 0.0.0.0 (0x030600000000)
*Mar 13 22:12:14.683: Vi1.1 AAA/AUTHOR/IPCP: Start.  Her address 0.0.0.0, we want 0.0.0.0
*Mar 13 22:12:14.687: Vi1.1 AAA/AUTHOR/IPCP: Done.  Her address 0.0.0.0, we want 0.0.0.0
*Mar 13 22:12:14.687: Vi1.1 IPCP: Pool returned 87.32.75.32
*Mar 13 22:12:14.687: Vi1.1 IPCP: O CONFNAK [REQsent] id 1 len 10
*Mar 13 22:12:14.687: Vi1.1 IPCP:    Address 87.32.75.32 (0x030657204B20)
*Mar 13 22:12:14.687: Vi1.1 IPCP: I CONFACK [REQsent] id 1 len 10
*Mar 13 22:12:14.687: Vi1.1 IPCP:    Address 87.32.75.33 (0x030657204B21)
*Mar 13 22:12:14.687: Vi1.1 IPCP: I CONFREQ [ACKrcvd] id 2 len 10
*Mar 13 22:12:14.691: Vi1.1 IPCP:    Address 87.32.75.32 (0x030657204B20)
*Mar 13 22:12:14.691: Vi1.1 IPCP: O CONFACK [ACKrcvd] id 2 len 10
*Mar 13 22:12:14.691: Vi1.1 IPCP:    Address 87.32.75.32 (0x030657204B20)
*Mar 13 22:12:14.691: Vi1.1 IPCP: State is Open
*Mar 13 22:12:14.691: Vi1.1 IPCP: Install route to 87.32.75.32
*Mar 13 22:12:14.695: Vi1.1 IPCP: Add link info for cef entry 87.32.75.32

[Lagerhaus_Jonny 10]

Und so, wenn es nicht klappt:

 

*Mar 13 22:14:01.259: ppp21 PPP: Received LOGIN Response PASS
*Mar 13 22:14:01.259: ppp21 PPP: Phase is FORWARDING, Attempting Forward
*Mar 13 22:14:01.259: ppp21 PPP: Send Message[Connect Local]
*Mar 13 22:14:01.267: ppp21 PPP: Bind to [Virtual-Access1.2]
*Mar 13 22:14:01.267: Vi1.2 PPP: Send Message[static Bind Response]
*Mar 13 22:14:01.267: Vi1.2 PPP: Phase is AUTHENTICATING, Authenticated User
*Mar 13 22:14:01.271: Vi1.2 PPP: Sent LCP AUTHOR Request
*Mar 13 22:14:01.271: Vi1.2 PPP: Sent IPCP AUTHOR Request
*Mar 13 22:14:01.271: Vi1.2 LCP: Received AAA AUTHOR Response PASS
*Mar 13 22:14:01.271: Vi1.2 IPCP: Received AAA AUTHOR Response PASS
*Mar 13 22:14:01.271: Vi1.2 CHAP: O SUCCESS id 1 len 4
*Mar 13 22:14:01.275: Vi1.2 PPP: Phase is UP
*Mar 13 22:14:01.275: Vi1.2 IPCP: O CONFREQ [Closed] id 1 len 10
*Mar 13 22:14:01.275: Vi1.2 IPCP:    Address 87.32.75.33 (0x030657204B21)
*Mar 13 22:14:01.275: Vi1.2 PPP: Process pending ncp packets
*Mar 13 22:14:01.279: Vi1.2 IPCP: I CONFREQ [REQsent] id 1 len 10
*Mar 13 22:14:01.279: Vi1.2 IPCP:    Address 0.0.0.0 (0x030600000000)
*Mar 13 22:14:01.279: Vi1.2 AAA/AUTHOR/IPCP: Start.  Her address 0.0.0.0, we want 0.0.0.0
*Mar 13 22:14:01.279: Vi1.2 AAA/AUTHOR/IPCP: Done.  Her address 0.0.0.0, we want 0.0.0.0
*Mar 13 22:14:01.283: Vi1.2 IPCP: Cannot satisfy pool request
*Mar 13 22:14:01.283: Vi1.2 IPCP: Neither side knows remote address
*Mar 13 22:14:01.283: Vi1.2 IPCP: O CONFREJ [REQsent] id 1 len 10
*Mar 13 22:14:01.283: Vi1.2 IPCP:    Address 0.0.0.0 (0x030600000000)
*Mar 13 22:14:01.283: Vi1.2 IPCP: I CONFACK [REQsent] id 1 len 10
*Mar 13 22:14:01.283: Vi1.2 IPCP:    Address 87.32.75.33 (0x030657204B21)
*Mar 13 22:14:01.287: Vi1.2 IPCP: I CONFREQ [ACKrcvd] id 2 len 4
*Mar 13 22:14:01.287: Vi1.2 AAA/AUTHOR/IPCP: Start.  Her address 0.0.0.0, we want 0.0.0.0
*Mar 13 22:14:01.287: Vi1.2 AAA/AUTHOR/IPCP: Done.  Her address 0.0.0.0, we want 0.0.0.0
*Mar 13 22:14:01.287: Vi1.2 IPCP: O CONFACK [ACKrcvd] id 2 len 4
*Mar 13 22:14:01.287: Vi1.2 IPCP: State is Open

 

Soweit so gut.

Wie man sehen kann, wird die erste eingehende Verbindung dem Interface Virtual-Access1.1 zugewiesen, weshalb es nach den Regeln des Virtual-Template1 behandelt wird.

Für dieses Template gibt es nur eine IP, die durch den ersten Router vergeben wird.

Die zweite Verbindung wird dem Interface Virtual-Access1.2 zugewiesen, womit das ganze zum scheitern verurteilt ist.

Denn es müsste dem Interface Virtual-Access2.1 zugewiesen werden.

 

Und genau da liegt der Hase im Pfeffer begragen (^^).

Insgesamt habe ich damit zwei Probleme.

Das erste ist: egal von welcher Seite die Verbindung kommt, sie wird dem Template 1 behandelt, bekommt also zwangsläufig die IP 85.130.214.156.

Wenn man sich mal die beiden FastEthernet-Interfaces anschaut, merkt man, dass das keinen Sinn macht.

Das macht nur auf einer von beiden Seiten Sinn.

Aber wie sage ich dem Router, das er gucken soll, von welcher Seite die Verbindungsaufforderung kommt und was er dann machen soll ?

 

Problem Nummer zwei ist natürlich klar:

Wie verhindere ich, das die zweite Verbindung auch unter Template 1 fällt ?

 

Kann mir da jemand helfen ?

[daking 10]

Hallo,

 

warum benutzt du zwei virt temps? der Sinn eines virt temps ist dieses x mal zu klonen. Wie soll der Router auch wissen, dass er das zweite hernehmen soll. Die virt temps werden sequentiell überprüft. Das virt temp 1 wird also immer an erster stelle sein (:-). Das virt temp 2 ist gleich konfiguriert (ausser die ip un numbered --> die existiert beim aufbau der pppoe session noch nicht).

 

Denke, dass du mit einem Template eine BRAS funktionalität realisieren kannst. Würde mich eher mal an local AAA für BRAS Parameter versuchen (:-).

[Lagerhaus_Jonny 10]

Nope, das zweite Template ist notwendig und keineswegs "gleich".

Man achte auf den dazugehörigen IP Pool und das ist der springende Punkt.

 

Ich habs mittlerweile auch hinbekommen.

Das Problem lag auf der Ebene, die ich völlig vernachlässigt hatte: Layer 2.

Ich hatte alle 3 Router über einen Switch verbunden, ohne VLans.

Mit getrennten VLANs funktionierte dann alles so wie es soll, da die PPP-Verbindungen nur noch über ein Interface reinkommen und nicht über beide gleichzeitig.

Das war das Problem.

[daking 10]

Hallo,

 

klar, dass es mit zwei vlans funzt...

 

ciao