Floating Default Route vs Flow Redirect

  • 0
  • 1
  • Question
  • Updated 10 months ago
  • Doesn't Need an Answer
Hi,

Currently working on integrating a legacy Cisco network with Extreme, where the default route for the interim is to send all traffic into the legacy Cisco network.

This is to be configured via static routing, due to problems in the legacy network enabling a common routing protocol. Below is an example of what the network interconnections will look like:



The two Extreme Switches are using MLAG, common VRRP between them for each of the VLANs with Fabric routing mode enabled, and OSPF also enable across the two.

So in the scenario I would like both cores to route all traffic to the first Cisco core, should that fail all traffic to be routed to the other core.

Have been looking at both these articles:

https://gtacknowledge.extremenetworks.com/articles/How_To/How-to-configure-flow-redirect

https://gtacknowledge.extremenetworks.com/articles/How_To/Need-floating-default-static-route

The new network is all on 10.x.x.x/8, everything else is to go to the legacy network.

Was exploring implementing something like the following:

create flow-redirect core3-redirect
configure flow-redirect core3-redirect add nexthop 10.0.254.204 priority 100
configure flow-redirect core3-redirect add nexthop 10.0.254.138 priority 200

edit policy ACL_redirect

Entry redirect {
If match all {
source-address 10.0.0.0/8;
} then {
permit;
redirect-name core3-redirect;
}
}

configure access-list ACL_redirect ports x ingress

---------------
create flow-redirect core4-redirect
configure flow-redirect core4-redirect add nexthop 10.0.254.142 priority 100
configure flow-redirect core4-redirect add nexthop 10.0.254.203 priority 200

edit policy ACL_redirect

Entry redirect {
If match all {
source-address 10.0.0.0/8;
} then {
permit;
redirect-name core4-redirect;
}
}

configure access-list ACL_redirect ports x ingress

--------------

Not sure if this is the best way to do it, perhaps using the following instead?:

configure iproute priority static <priority> [11-65534
]

Also, should I use flow-redirect I would probably have to apply the ACL to all ports bar the ISC link and interlinks to legacy network?

Will have to give the same consideration on the legacy side to stop any asymmetric routing, so if you also have any ideas around that?


Many thanks
Photo of Martin Flammia

Martin Flammia

  • 5,734 Points 5k badge 2x thumb

Posted 10 months ago

  • 0
  • 1
Photo of Mel78, CISSP, ECE

Mel78, CISSP, ECE

  • 1,044 Points 1k badge 2x thumb

Have you consider letting the legacy Cisco network running mVRRP ? Then there is no need to do the above stuff.

VRRP is a well known standard and can coexists between different vendors. The only thing to note the multicast hello which is tied to VRRP ID. So make sure no conflict there.



Photo of Martin Flammia

Martin Flammia

  • 5,734 Points 5k badge 2x thumb
Hi,

Thanks for replying, I hadn't considered this but one of the reasons for using default routes is the legacy Cisco network is old, end of life and deemed very unstable, so a minimum and simple as possible configuration work is to be considered for the integration.

So although this might be a good idea, I can't use it in this example.

My Cisco knowledge being a little out dated now, they are currently using HSRP and a presume utilising this method could take some extensive'ish configuration work?

Any other ways of doing it?

Just need to way up all my options and consider which is best really.

Many thanks
Photo of Mel78, CISSP, ECE

Mel78, CISSP, ECE

  • 1,044 Points 1k badge 2x thumb

Ok you are doing not doing the right thing. But rather trying to do the thing right.

Your above redirect is missing the health-check by ping/arp.

You are doing what Cisco is doing on their PBR with IP SLA monitoring the next-hop.

You can search the EXOS user-guide on ""Policy-based redirection redundancy"

The above will be doing the things right. But it will be complex, messy and complicated.


mVRRY or mHSRP will solve the common problem of load-sharing on FHRP (First-Hop Redundancy Protocol) in the first place for outgoing traffic.


Good Luck.



 



Photo of Martin Flammia

Martin Flammia

  • 5,734 Points 5k badge 2x thumb
Thanks for comment. I'll take a look at that section and post back if I work it out. Re the other comment about the health check, this link states the following:

https://gtacknowledge.extremenetworks.com/articles/How_To/How-to-configure-flow-redirect

"If more than one next hope address is used, EXOS will automatically send ping health-checks to make sure the next hop is available. If the connectivity is loss then it will refer to the next highest priority next hop in the configuration."

So I'm assuming in my example with two next hope addresses it is doing this automatically?

Thanks.
Photo of Mel78, CISSP, ECE

Mel78, CISSP, ECE

  • 1,044 Points 1k badge 2x thumb

If you omit the health-check statement

configure flow-redirect flow_redirect_name health-check [ping | arp | neighbordiscovery]

If any of the legacy Cisco switch goes down, your static route will always be in the routing table. So you have a black-hole route.



Photo of Martin Flammia

Martin Flammia

  • 5,734 Points 5k badge 2x thumb
So had another idea (to try and keep it simple), but not sure if anyone can collaborate it - but basically to use software port redundancy instead:

https://gtacknowledge.extremenetworks.com/articles/How_To/How-to-configure-software-controlled-redun...

Take the following:



So here I have removed the LAG / Port-Channels between the Extreme and Cisco's. Each Extreme core has a default route configured to their respective Cisco core, and the software redundancy will take care of activating or re-activating the redundant links. Routes shared via OSPF between the Extreme cores would then handle where to direct traffic dependant on whether to links to legacy core 1 or legacy core 2 go down?

What do you think?
(Edited)
Photo of Mel78, CISSP, ECE

Mel78, CISSP, ECE

  • 1,044 Points 1k badge 2x thumb

Again how does "software redundancy will take care of activating or re-activating the redundant links" ?

Only when the port is disable or when 1 of cisco switches is down. But when that happens, your default route will still be in the routing table. You have no floating static default .route.

You can run all under OSPF with Cisco. All Layer 3. But again, that is what you want to avoid in the first place because of "legacy" cisco.

I can assure you, legacy Cisco is also a reputable product. You can accommodate mHSRP for sure.



Photo of Martin Flammia

Martin Flammia

  • 5,734 Points 5k badge 2x thumb
Hi,

Sure, and I know what your saying and makes perfect sense. Unfortunately I'm in the situation where I need to minimalise what I do on the Cisco's as much as possible - using OSPF is how I would typically do it.

To handle the routes I was wondering if I could use it on conjunction with the following to manage the route:

https://gtacknowledge.extremenetworks.com/articles/Q_A/Cisco-ASA-IP-SLA-Like-feature

configure iproute add 10.1.1.0/24 10.2.1.1 protection ping

Not sure if it would work with a default route?
Photo of Martin Flammia

Martin Flammia

  • 5,734 Points 5k badge 2x thumb
I would still have the same problem in the other direction, think mVRRP is the only way to go, as you say, in this example. I'll look further into that but if anything else comes to mind let me know. Many thanks
Photo of Martin Flammia

Martin Flammia

  • 5,734 Points 5k badge 2x thumb
So scratched this config up, what do you think, this what you had in mind?:

#### Extreme Core 1 ####

create vlan "Interlink1-VRRP"
configure vlan "Interlink1-VRRP" tag 3999
configure vlan "Interlink1-VRRP" add ports x tagged
configure vlan "Interlink1-VRRP" ipaddress 10.0.254.180 255.255.255.248
enable ipforwarding vlan "Interlink1-VRRP"

create vrrp vlan "Interlink1-VRRP" vrid 100
configure vrrp vlan "Interlink1-VRRP" vrid 100 add 10.0.254.182
configure vrrp vlan "Interlink1-VRRP" vrid 100 priority 150
enable vrrp vlan "Interlink1-VRRP" vrid 100

#### Extreme Core 2 ####

create vlan "Interlink2-VRRP"
configure vlan "Interlink2-VRRP" tag 3999
configure vlan "Interlink2-VRRP" add ports x tagged
configure vlan "Interlink2-VRRP" ipaddress 10.0.254.181 255.255.255.248
enable ipforwarding vlan "Interlink2-VRRP"

create vrrp vlan "Interlink2-VRRP" vrid 100
configure vrrp vlan "Interlink2-VRRP" vrid 100 add 10.0.254.182
enable vrrp vlan "Interlink2-VRRP" vrid 100


#### Cisco Core 1 ####

interface TenGigabitEthernet1/1/2
 description "Interlink-VRRP-Extreme-Core1"
 switchport trunk encapsulation dot1q
 switchport trunk allowed vlan 3999
 switchport mode trunk

interface Vlan3999
 ip address 10.0.254.178 255.255.254.0
 vrrp 100 description "VRRP-Cisco-Extreme"
 vrrp 100 ip 10.0.254.182
 no vrrp 100 preempt
end

#### Cisco Core 2 ####

interface TenGigabitEthernet1/1/3
 description "Interlink-VRRP-Extreme-Core2"
 switchport trunk encapsulation dot1q
 switchport trunk allowed vlan 3999
 switchport mode trunk

interface Vlan3999
 ip address 10.0.254.179 255.255.254.0
 vrrp 100 description "VRRP-Cisco-Extreme"
 vrrp 100 ip 10.0.254.182
 no vrrp 100 preempt
end
(Edited)
Photo of Mel78, CISSP, ECE

Mel78, CISSP, ECE

  • 1,044 Points 1k badge 2x thumb

Nope.

What I am recommending is as follows. (As an example)

1) VRRP ID 100 (for Cisco switches only, switch A:10.0.254.178 primary gateway, switch B:10.0.254.179), virtual IP is 10.0.254.182

2) Add a default route to the Extreme virtual IP 10.0.254.192

The above is single group VRRP. You can defined another VRRP group with a new ID and switch B as primary gateway.


3) VRRP ID 101 (for Extreme switches only, switch C:10.0.254.188 primary gateway, switch D:10.0.254.189), virtual IP is 10.0.254.192

4) Add a default route to the Cisco virtual IP 10.0.254.182

The above is single group VRRP. You can defined another VRRP group with a new ID and switch D as primary gateway.


Extreme Switches default route will point to Cisco VRRP and vice-versa.

You can create multiple VRRP group with different primary gateway on both sides to load-share the traffic. 



 

(Edited)
Photo of Martin Flammia

Martin Flammia

  • 5,734 Points 5k badge 2x thumb
Oh, right, that makes sense..... assume all these addresses share the same VLAN 3999 and mask of /29, as per my example above (just noticed some errors in my masks above) so that the default route see's the opposing VIP addresses as being in same subnet?
Photo of Mel78, CISSP, ECE

Mel78, CISSP, ECE

  • 1,044 Points 1k badge 2x thumb

Yes. Each VRRP Group default gateway will be the opposing VIP address.

Again, you can have multiple VRRP group (mVRRP) with multiple VIP addresses.

From there, you can use destination-based static route to the respective gateway on those VIP addresses.

The load-sharing algorithm is based on your static route. You have control how to load share your traffic based on your 2-pairs of opposing VRRP. This design is very  deterministic and works much better than load-balancing algorithms in small networks.

Photo of Martin Flammia

Martin Flammia

  • 5,734 Points 5k badge 2x thumb
Nice one Wong, your a genius! Your time and support has been very much appreciated.

Cheers
Photo of Martin Flammia

Martin Flammia

  • 5,734 Points 5k badge 2x thumb
So having a think about this and decided I would end up creating a L2 loop if I was to add the VLAN 3999 everywhere.

This article mentions a similar problem, where they just omitted the VLAN between one pair of the cores but VRRP information was still shared between the other core pair because of the common VLAN:

https://supportforums.cisco.com/t5/lan-switching-and-routing/vrrp-looping-issue/td-p/2117103

Below I have tried to depict this in the diagram, by omitting VLAN 3999 between the Cisco Cores:


Would that make sense, or am I missing something or need to do it in another fashion?
Photo of Mel78, CISSP, ECE

Mel78, CISSP, ECE

  • 1,044 Points 1k badge 2x thumb

You did the 1st step right. Retain the LAG at Cisco side and MLAG at Extreme side.

There will be no loop at MLAG-ISC link.

Theres no need to tag VLAN 3999 over the link between the Cisco switches.

The VRRP multicast hello packet will traverse between Extreme Switches.

Photo of Martin Flammia

Martin Flammia

  • 5,734 Points 5k badge 2x thumb
Great, thanks