cancel
Showing results for 
Search instead for 
Did you mean: 

mpls L3VPN between Cisco and Extreme Networks XOS devices

mpls L3VPN between Cisco and Extreme Networks XOS devices

Stefano_Dall_Os
New Contributor III
Hi everybody,
I'm trying to get L3VPN mpls working between Extreme Networks x460g2 and various cisco devices (3600, ASR920, 7600, 9000), and actually I'm stuck ...
Has anyone ever been able to do it?

I'll try to explain what I've done with some pictures and text information ...

Here are the L1 and L2/L3 schemes of version 1 of my lab ...

40ab4fb14f41484182f75b6310f0dc73_RackMultipart20170330-67611-119fmuq-MPLS_test_L1_version_1_inline.png



40ab4fb14f41484182f75b6310f0dc73_RackMultipart20170330-94705-13lkfzp-MPLS_test_L2_L3_version_1_inline.png



On each switch/router we have 2 loopback interfaces/vlans:
- 1 for OSPF 172.18.0.x/32
- 1 for iBGP 172.18.128.x/32
The «x» refers to the numeric ID of each switch/router, with the only exception of RFI1, where:
- OSPF loopback is 172.18.0.3/32
- iBGP loopback is 172.18.128.1/32
All switches are in the same OSPF area 172.18.128.217, and is the BGP AS 172. RFI1 is the RR for the BGP part, and the ONLY neighbor for each switch/router.

All ospf interfaces are PTP.
BGP and OSPF seems to work fine as soon as we DON’T enable MPLS.
LDP protocol seems to work well between the two vendors.
We created 2 VPN-VRF on every switch/router:
- vr-acme with RD 172:10 ad route-target 172:10 in both RX and TX, with a binded loopback interface 3.3.3.x/32
- vr-mgt_ool_104999 with RD 172:104999 and route-target 172:104999 in both RX ad TX, with a binded loopback interface 4.4.4.x/32

From my point of view, the main «suspect» is something in the routing part.
We changed the iBGP route priority in the extreme devices, to be similar to the Cisco administrative distance
configure iproute priority ibgp 4000
I still have doubts on «where» to put the priority of the MPLS.
I tried the default value, before iBGP or after iBGP, and the result is pretty close the same:
as soon as we enable the MPLS routing stuff, things start to work NOT in the way we expected/wanted.

Step1:
- We added the 2 loopback vlans and the ospf PTP vlan in the mpls and LDP «process».
- We enabled «mpls protocol ldp» and «mpls» itself
At this point, LDP starts to work, and we start to see some MPLS stuff, but the main goal, that is to see routing information on the two separate
VRF, is still not reached (we don’t see anything in the specific VRF routing table, as expected ... mpls routing is STILL not enabled)

Step2:
- We enable the MPLS routing
• enable iproute mpls-next-hop
• enable iproute mpls-next-hop vr vr-acme
• enable iproute mpls-next-hop vr vr-mgt_ool_104999
At this point, for a while (iBGP timeout), I see what I want to see in the VRF routing table (actually just the loopback interfaces binded to each VRF), but after the iBGP timeout, everything disappears.
The cause seems to be the fact that as soon as I enable the MPLS routing, I loose the reachability of the iBGP loopback interface, and from there I loose the iBPG neighborship.
And here is the MOST interesting part: the ISSUE is NOT everywhere, but just from a device
(and from that one, nothing works, like in a chain)
The «guilty device» is the FIRST cisco switch/router, no matter which model it is
(we tried to «switch» between cisco models, but nothing changed).

To be more specific, if we look at «version 1» of the test, if we try to ping from RFI1 using the iBGP loopback interface as source, and the iBGP
loopback interface of each other switch/router as the destination, we have:
- RFI1 can ping 217
- RFI1 can ping 216
- RFI1 CANNOT ping 213
- RFI1 CANNOT ping 214
- RFI1 CANNOT ping 215
Moreover: IF the chain is ONLY of extreme switches, everything works perfectly (still using RFI1, a cisco device, as RR ... same configuration ...)
Even more, just because RFI1 is a REAL production router, for a while I used a smaller set of devices.
Just take the same scheme of «version 1», remove RFI1, and take 217 as its replacement
(so 217 is the RR for iBGP, and all other router just have it as a neighbor).
In this way, everything works perfectly.

Here are pictures for version 2 of the same lab ... same results ...

40ab4fb14f41484182f75b6310f0dc73_RackMultipart20170330-45589-3deoju-MPLS_test_L1_version_2_inline.png



40ab4fb14f41484182f75b6310f0dc73_RackMultipart20170330-2593-zg6c1o-MPLS_test_L2_L3_version_2_inline.png

16 REPLIES 16

from what I know, yes ...

yes
GTM-P2G8KFN