cancel
Showing results for 
Search instead for 
Did you mean: 

Fabric Extend with FIGW VM over MPLS not directly terminated

Fabric Extend with FIGW VM over MPLS not directly terminated

Martin_Flammia
Valued Contributor

Hi,

Currently in the process of trying to configure Fabric Extend over an MPLS cloud that sits externally to the VSP4900’s where the FE tunnels will be configured.

Below is a logical view of the topology:

237061000b3d4006b227e267fb2a42bf_794debf4-aa9a-4258-bb0b-d243acc70bef.png

 

The two switches at the top left and right represent the new VSP4900’s. There will be at some point direct P2P links joining the two hopefully using native NNI links, if not, FE will need to be introduced here.

The MPLS cloud is terminated on other switches (VSP8404’s). The four bottom switches have OSPF enabled and share routing information between all the devices.

The WAN VSP4900 at the top are joined via fabric connect (isis / spbm) to the four switches below it and sharing ISIS information with all the nodes . The WAN switches / routers only have a default route pointing back to the core / primary network.

As can been seen OSPF is redistributed into ISIS but not the other way, so the WAN routers are not aware of any routes outside ISIS of which the default route is handling traffic back in the other direction. The WANs VSP4900’s are redistributing direct, hence the rest of the network is therefore aware via the ISIS to OSPF redistribution about all the WAN switch interfaces / CLIPs / Mgmt. Only thing that isn’t being redistributed into ISIS at this time is the vIST subnets as per best practice.

So my issue is how do I configure the FE / FIGW interfaces if using GRT?

References I have seen has the WAN directly connected to the 4900’s and the FE is put into a VRF / L3VSN, so the tunnel end points only see themselves directly attached and not shared into GRT, but this would not work in this case with the end-point only being aware of each other indirectly over OSPF / MPLS.

If I use GRT I believe I would need to stop the redistribution of the FE interfaces into ISIS, at which point it would not get redistributed into OSPF and the FE tunnels would not know how to reach each other?

I might be making my life difficult and the answer would simply be to just introduce OSPF onto the WAN routers, that way I can still not redistribute the FE into ISIS (underlay), but OSPF (overlay) would be aware of how to reach the other end dynamically.

Either that I could just add some static routes as it stands pointing back to the WAN VSP’s?

Guess there are multiple options but it is somewhat confusing to me with running underlay and overlay routing protocols, configuring FE with FIGW VM, what needs pointing to what when the WAN network is not directly terminated on the 4900’s.

Below is an another diagram that I have attempted to add some configuration and some context. I’ve only included one VSP 4900 at each site for simplicity:

237061000b3d4006b227e267fb2a42bf_17ffa20e-163f-41a4-853b-ea617a90aea8.png

There is obviously a lot of configuration components to understand here, but hopefully provided enough to get a conversation going and context to understand what I am trying to achieve.

Appreciate any pointers.

Many thanks in advance

1 ACCEPTED SOLUTION

Martin_Flammia
Valued Contributor

Thanks Ludovico for assisting piecing the last few elements together.

Hopefully this will be useful to someone else, but here is an overview diagram showing the topology and the configuration added to each device.

This has x2 4900’s at each location, so effectively two FE tunnels have been created.

87c8236a8642487087b5b716acec381a_c2d4bc9d-8a99-4e5a-96b9-7db016659522.png

 

View solution in original post

3 REPLIES 3

Martin_Flammia
Valued Contributor

Thanks Ludovico for assisting piecing the last few elements together.

Hopefully this will be useful to someone else, but here is an overview diagram showing the topology and the configuration added to each device.

This has x2 4900’s at each location, so effectively two FE tunnels have been created.

87c8236a8642487087b5b716acec381a_c2d4bc9d-8a99-4e5a-96b9-7db016659522.png

 

Ludovico_Steven
Contributor III

If it’s an MPLS network then it should be able to support oversized frames; so why do fragmentation on the FE tunnels ?

In which case better to configure the FR tunnels on the 8400s.

Or else move the MPLS connections to the 4900s if F&R is really a must.

What you are trying to do is too complicated in my opinion. Remember that if the 4900 is using an ISIS route (directly or indirectly) to reach the FE Tunnel destination IP then you are in an unsupported configuration.

 

Martin_Flammia
Valued Contributor

Just thought I would post a small update.

Have a clear plan now that involves static routing on the VSP4900 and route-map’s that limit the redistribution of certain interfaces into ISIS i.e. the only thing I want to be able to route to is the other reassembly address of the FIGW on other side, and the local FIGW. FE address is not advertised into the network, as a static route will be in places that tunnel it through the FIGW.

This is a bit of an overview, but will post full details if I get this working.

The diagram just shows the conf and relationship to the configs for just the left side, with the right being much the same.

da56d4e198794b9f86249cfea106b3e1_3aa0fce2-38ac-46a8-b32b-b287e5419a7a.png

 

GTM-P2G8KFN