08-07-2015 08:53 PM - edited 03-05-2019 02:01 AM
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
Solved! Go to Solution.
08-08-2015 02:16 PM
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:
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
08-08-2015 02:16 PM
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:
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
08-10-2015 05:24 AM
Too bad... But thanks for your answer!
Best regards,
Guillaume
08-10-2015 06:20 AM
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
08-10-2015 07:42 AM
I'll test this tomorrow and keep you updated! Thanks.
08-12-2015 07:27 AM
Hi Guillaume,
Any news on this?
Best regards,
Peter
08-14-2015 03:04 PM
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
08-15-2015 06:39 AM
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
08-15-2015 09:23 AM
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
08-15-2015 12:18 PM
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
08-16-2015 06:38 PM
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
08-17-2015 03:16 AM
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
03-19-2018 10:18 AM - edited 03-19-2018 10:20 AM
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
07-07-2019 06:51 PM
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?
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide