cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3857
Views
5
Helpful
13
Replies

PPPoE not working on a CSR1000V bridge-domain

Elektordi
Level 1
Level 1

Hello Cisco fans,

 

I have a problem with a proof-of-concept config on a CSR1000V in my lab.

 

I have set up a full PPPoE server configuration with L2TP forward (bba, vpdn, virtual template...) with a bba-group named PPP.

When I enable the server on my local interface, my client (an old 1841 with a pppoe-client dial-pool-number) in the same LAN connect without problem:

interface GigabitEthernet1
 no ip address
 pppoe enable group PPP

 

But when I switch my PPPoE server to a bridge-domain, it seems the server process don't receive "PADI" packets anymore:

bridge-domain 12
!
interface GigabitEthernet1
 no ip address
 service instance 1 ethernet
  encapsulation untagged
  bridge-domain 12
!
interface BDI12
 no ip address
 pppoe enable group PPP

 

When the client sends PADI packets, the input count of Gi1 increments but the input count of BDI12 don't. And "debug pppoe packets" won't display any packet on the CSR side.

I already tried to put an IP on BDI12, and I can ping it without problem from my test client, so the connectivity seems ok.

 

For information, I need to move my PPPoE server to a BDI interface because the final idea is to receive requests from partners NNI over remote pseudowires, not locally:

l2 vfi ppp-test manual
 vpn id 12
 bridge-domain 12
 neighbor 1.1.1.2 1234 encapsulation mpls

This part is ready (pings works with static IPs) but same problem with PPPoE packets.

 

Does anyone have any idea why the PPPoE is not working on the BDI interface?

Thanks for your help !

 

Best regards,

 

Guillaume

1 Accepted Solution

Accepted Solutions

Peter Paluch
Cisco Employee
Cisco Employee

Guillaume,

I am sorry to disappoint you but it seems that the combination of Ethernet service instances and PPPoE is not supported. The documentation for ASR-1K that runs principially the same IOS-XE states this explicitly:

http://www.cisco.com/c/en/us/td/docs/routers/asr1000/configuration/guide/chassis/asrswcfg/bdi.html#pgfId-1054861

Unfortunately, I do not have enough experiences with these features to suggest a workaround - apart from, obviously, dedicating an extra port on the device performing the bridge-domain aggregation, and have a PPPoE access server connected to that extra port.

Best regards,
Peter

View solution in original post

13 Replies 13

Peter Paluch
Cisco Employee
Cisco Employee

Guillaume,

I am sorry to disappoint you but it seems that the combination of Ethernet service instances and PPPoE is not supported. The documentation for ASR-1K that runs principially the same IOS-XE states this explicitly:

http://www.cisco.com/c/en/us/td/docs/routers/asr1000/configuration/guide/chassis/asrswcfg/bdi.html#pgfId-1054861

Unfortunately, I do not have enough experiences with these features to suggest a workaround - apart from, obviously, dedicating an extra port on the device performing the bridge-domain aggregation, and have a PPPoE access server connected to that extra port.

Best regards,
Peter

Too bad... But thanks for your answer!

 

Best regards,

Guillaume

Hi Guillaume,

But hey - this is a virtual router running in a virtual environment, right? There should not be a problem adding two virtual interfaces bridged by the virtual environment! Consider the following topology:

Here, Gi3 and Gi4 are interfaces that are connected together by the environment (KVM or VMWare) in which the CSRv runs. Now assume that Gi2 and Gi3 are in the same bridge-domain, and the PPPoE server instance is started on Gi4. The bridge-domain will bridge frames coming from Gi2 onto Gi3, and they will be further delivered to Gi4 - and vice versa. It's a hack, yes - but I've just tested this in VIRL and it worked just nice!

So this should be possible for you, too. You want to terminate pseudowires in your bridge-domain which is fine. You should add two more interfaces on your CSRv, with one of them becoming a member of the bridge-domain, the other running the PPPoE server, and the KVM/VMWare bridging those two interfaces together.

Just for clarity, this was my quick-and-dirty config on the CSRv that worked:

bridge-domain 1
 member GigabitEthernet2 service-instance 1
 member GigabitEthernet3 service-instance 1
!
bba-group pppoe PPP
 virtual-template 1
!         
interface Loopback0
 ip address 192.0.2.1 255.255.255.255
!         
interface GigabitEthernet2
 description => To a client <=
 no ip address
 negotiation auto
 service instance 1 ethernet
  encapsulation untagged
 !
!
interface GigabitEthernet3
 description => To myself <=
 no ip address
 negotiation auto
 service instance 1 ethernet
  encapsulation untagged
 !        
!         
interface GigabitEthernet4
 no ip address
 negotiation auto
 pppoe enable group PPP
!         
interface Virtual-Template1
 ip unnumbered Loopback0
 peer default ip address pool IPs
!
ip local pool IPs 192.0.2.11 192.0.2.100


Would you mind testing this?

Best regards,
Peter

I'll test this tomorrow and keep you updated! Thanks.

Hi Guillaume,

Any news on this?

Best regards,
Peter

Hi Peter,

 

I just tested your idea but I have bad news... It's not working. :(

 

I added interfaces Gi2 and Gi3 on CSR100V, then xconnected Gi2 to my remote device and enabled PPPoE server on Gi3.

Gi2 and Gi3 were in the same internal network on my VirtualBox.

 

The PADI packets arrives to Gi3, then a PADO packet is answered on Gi3 but never enters Gi2 (can be confirmed by interfaces counters) so never goes back in the xconnect to the original device.

I added IPs in the L2 area and confirmed that broadcasts works in both ways, but directed works only in one way: packets from Gi3 to remote device never enters Gi2. I think this may be caused by VirtualBox virtual switch which does not recognize the target MAC address in the packet and drop it. (I'm not sure there is a real forwarding-table implemented in this switch, it may just be looking at MACs of attached NICs to forward the packets)

 

I had another VM running Linux in the same internal network, and ran a tcpdump on it: I received only broadcast PADI. But if I enabled promiscuous on this VM and on my tcpdump, I saw PADO answers directed to my other device MAC.

I also tried to change the virtual NICs of my CSR 1000V to "UDPTunnel" mode and then loop back the two NICs, but packets are still dropped. And even if I authorize promiscuous mode, the IOS seems to never request this mode.

 

I'll try to set up my CSR 1000V on another hypervisor, but for now I don't have another one near hand.

 

Thanks again for your help, I'll keep you updated.

 

Best regards,

Guillaume

Guillaume,

I was definitely able to get this going successfully. This is my setup:

Client was configured as a trivial PPPoE client:

hostname Client
!
interface GigabitEthernet0/1
 no ip address
 duplex auto
 speed auto
 media-type rj45
 pppoe enable
 pppoe-client dial-pool-number 1
!
interface Dialer0
 ip address negotiated
 encapsulation ppp
 dialer pool 1

Agg was configured to create a simple MPLS pseudowire, transporting all received Ethernet frames on Gi0/1 to the PPPoE box and vice versa:

hostname Agg
!
mpls label protocol ldp
!
interface Loopback0
 ip address 198.51.100.1 255.255.255.255
 ip ospf 1 area 0
!
interface GigabitEthernet0/1
 description => To the Client <=
 no ip address
 duplex auto
 speed auto
 media-type rj45
 xconnect 198.51.100.2 1 encapsulation mpls
!
interface GigabitEthernet0/2
 description => To the PPPoE server on CSRv <=
 ip address 192.0.2.1 255.255.255.0
 ip ospf 1 area 0
 duplex auto
 speed auto
 media-type rj45
 mpls ip
!
mpls ldp router-id Loopback0 force

The CSRv was configured with the hostname "PPPoE", and was configured with the VFI you intended, and a simple PPPoE server instance:

hostname PPPoE
mpls label protocol ldp
!
bridge-domain 1
!
l2 vfi PPP-test manual
 vpn id 1
 bridge-domain 1
 neighbor 198.51.100.1 encapsulation mpls
!
bba-group pppoe PPP
 virtual-template 1
!
interface Loopback0
 ip address 198.51.100.2 255.255.255.255
 ip ospf 1 area 0
!
interface Loopback1
 ip address 10.0.0.1 255.255.255.255
!
interface GigabitEthernet2
 description => To the Agg <=
 ip address 192.0.2.2 255.255.255.0
 ip ospf 1 area 0
 negotiation auto
 mpls ip
!
interface GigabitEthernet3
 description => To myself Gi4 over a transparent bridge <=
 no ip address
 negotiation auto
 service instance 1 ethernet
  encapsulation untagged
  bridge-domain 1
 !
!
interface GigabitEthernet4
 description => To myself Gi3 over a transparent bridge <=
 no ip address
 negotiation auto
 pppoe enable group PPP
!
interface Virtual-Template1
 ip unnumbered Loopback1
 peer default ip address pool IPs
!
ip local pool IPs 10.0.0.11 10.0.0.200
!
mpls ldp router-id Loopback0 force

Because I was doing this setup in VIRL, and VIRL does not allow two interfaces of a router to be connected to the same network (it's trying to be smart but here, it's kind of stupid), I have created the "loop" between the Gi3 and Gi4 on the CSRv using an additional router with two interfaces, performing common bridging:

hostname Bridge
!
bridge irb
!         
interface GigabitEthernet0/1
 description => To PPPoE Gi3 <=
 no ip address
 duplex auto
 speed auto
 media-type rj45
 bridge-group 1
 bridge-group 1 spanning-disabled
!
interface GigabitEthernet0/2
 description => To PPPoE Gi4 <=
 no ip address
 duplex auto
 speed auto
 media-type rj45
 bridge-group 1
 bridge-group 1 spanning-disabled

And voila - it works!

Client(config)# do show ip int brief
Interface                  IP-Address      OK? Method Status                Protocol
GigabitEthernet0/0         unassigned      YES unset  administratively down down   
GigabitEthernet0/1         unassigned      YES unset  up                    up     
Dialer0                    unassigned      YES IPCP   administratively down down   
Virtual-Access1            unassigned      YES unset  down                  down   
Client(config)# int di0            
Client(config-if)# no shut
Client(config-if)#
*Aug 15 13:17:16.092: %LINK-3-UPDOWN: Interface Dialer0, changed state to up
*Aug 15 13:17:35.598: %DIALER-6-BIND: Interface Vi1 bound to profile Di0
*Aug 15 13:17:35.599: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to up
*Aug 15 13:17:35.666: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to up
Client(config-if)#do show ip int brief
Interface                  IP-Address      OK? Method Status                Protocol
GigabitEthernet0/0         unassigned      YES unset  administratively down down   
GigabitEthernet0/1         unassigned      YES unset  up                    up     
Dialer0                    10.0.0.14       YES IPCP   up                    up     
Virtual-Access1            unassigned      YES unset  up                    up     
Client(config-if)#do show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       a - application route
       + - replicated route, % - next hop override, p - overrides from PfR

Gateway of last resort is not set

      10.0.0.0/32 is subnetted, 2 subnets
C        10.0.0.1 is directly connected, Dialer0
C        10.0.0.14 is directly connected, Dialer0
Client(config-if)#do ping 10.0.0.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 6/16/31 ms
Client(config-if)#

Client(config-if)# do show pppoe session
     1 client session

Uniq ID  PPPoE  RemMAC          Port                    VT  VA         State
           SID  LocMAC                                      VA-st      Type
    N/A      4  fa16.3e77.daa6  Gi0/1                   Di0 Vi1        UP      
                fa16.3eb7.309d                              UP              
Client(config-if)#

And on PPPoE server at CSRv:

PPPoE# show ppp all
Interface/ID OPEN+ Nego* Fail-     Stage    Peer Address    Peer Name
------------ --------------------- -------- --------------- --------------------
Vi1.1        LCP+ IPCP+            LocalT   10.0.0.14                       
PPPoE# show pppoe session
     1 session  in LOCALLY_TERMINATED (PTA) State
     1 session  total

Uniq ID  PPPoE  RemMAC          Port                    VT  VA         State
           SID  LocMAC                                      VA-st      Type
      4      4  fa16.3eb7.309d  Gi4                      1  Vi1.1      PTA  
                fa16.3e77.daa6                              UP              
PPPoE#

 

So if the configuration above (except the Bridge) does not work for you then I suspect the VirtualBox to be the problem.

Let me ask you: In what hypervisor is the production CSRv being run? Is it KVM, or is it VMware? I do not suppose you are running VirtualBox to run a production CSRv.

I am sure we can get this done and going :)

Best regards,
Peter

Hi Peter,

 

Good news!

I have exactly the same setup, Agg being an ASR920 (in lab) and Client a 1841.

 

Right now, we don't have any CSR 1000V in production, but I plan to use VMWare. I will try to install a new server in my lab with vSphere and test the CSR 1000V on it, I'm just waiting for a test server to be available (we have only one lab for many people.) That's why I was using VirtualBox on my desktop computer...

 

But I confirm the VirtualBox virtual switch have no forwarding table, I read that on some VirtualBox design papers...

 

I'll keep you updated as soon as I have a running VMWare!

 

Thanks again for your help!

 

Best regards,

 

Guillaume

 

Hi Guillaume,

That's why I was using VirtualBox on my desktop computer...

And what operating system are you running on your desktop computer - Linux or Windows? I believe I could suggest a solution if you're running Linux. With Windows, alas, I do not know (Windows is not a networker's operating system, anyway :) ).

Best regards,
Peter

Hi Peter,

 

Don't worry, I'm using Linux (Xubuntu), as any good network engineer ;)

I was thinking about using VDE switch, it should work, it's a real switch with a forwarding table. But I have to use a patched version of virtualbox to be fully compatible with VDE if I remember correctly, which I have to install again... I don't have it anymore...

Is it the idea you were thinking of? Or have you another idea?

 

Best regards,

Guillaume

Hi Guillaume,

Actually, I have a different idea - using purely Linux's features.

Please enter the following commands as root:

ip link add type veth
ip link set veth0 up
ip link set veth1 up

This command creates a pair of virtual Ethernet interfaces linked together: Whatever is sent out by one of them is received by the other, and vice versa. Essentially, they behave like two NICs connected together by a crossover cable.

Now, in the VirtualBox virtual machine settings, configure the "Gi3" interface of the CSRv to be bridged onto veth0, "Gi4" interface of the CSRv to be bridged onto veth1 - and you should be all set!

The three commands above are only runtime changes and do not modify your Xubuntu permanently. After a reboot, every change is forgotten.

Best regards,
Peter

Hi Peter,

 

   I was looking for a workaround to terminate a VPLS tunnel on the BRAS itself and could find a feature called Pseusowire Headend which is only designed for ASR9k and then came across your perfect solution which saved my day. I just wanted to send my token of appreciation for this nice solution. I have not tested this on real hardware which happens to be ASR1k on our side but using this technique I am going to get rid of 25 Mikrotik routers playing the EoIP tunnel termination role next to our BRASes which I take as granted as a working solution.

 

Regards,

Hesam

Hi there, has anyone tested PPPoE on BDI or over VPLS since the new IOS has become available for the ASR1001-X? Does it work?

Review Cisco Networking products for a $25 gift card