routing
44 TopicsLTM source based routing, different default gateway for each Vlan
Hi all, I would like to get my routing assumptions confirmed by somebody who already has the experience with source based routing on LTM. Or in case the assumption is not correct, I would be happy to get help with it. Imagine following situation. Servers reside in Vlan A and Vlan B behind a firewall. Each Vlan has a subinterface on the firewall and the firewall's IP is the default gateway for particular Vlan. This is clear, no need for any special routing: | | ----------------------------------- | FIREWALL | | | | 10.0.1.1 10.0.2.1 | ----------------------------------- | | | | VLAN A VLAN B | | | | SERVERS SERVERS 10.0.1.60 10.0.2.60 10.0.1.61 10.0.2.61 Now I need to be able to do some load balancing in both Vlans so I introduce LTM in the following way: | | ----------------------------------- | FIREWALL | | | | 10.0.1.1 10.0.2.1 | ----------------------------------- | | | | VLAN A VLAN B | | | | --------------------------------------- | VIP:10.0.1.15 VIP:10.0.2.15 | | F5 LTM | | | | SNAT:10.0.1.25 SNAT:10.0.2.25 | --------------------------------------- | | | | VLAN A VLAN B | | | | SERVERS SERVERS 10.0.1.60 10.0.2.60 10.0.1.61 10.0.2.61 So the LTM (VIP, SNAT) shares the same subnet with backend servers. This allows clients to reach the backend servers either way: directly from the firewall: client->firewall->server and on the way back it's server's default gateway which points the packet from the server back to firewall. via LTM through VIP: client->firewall->VIP->SNAT->server. On the way back the server sends the packet back to SNAT, so it's: server->SNAT->VIP->firewall->client. Now to my routing question. I don't know the IPs of our clients, they can come from any subnet. So on the F5 I need a default route towards firewall for each Vlan, but response packet must adhere to the same Vlan through which the request came in, otherwise the firewall will drop the response packet (anti-spoofing). Basically I need to achieve the following, for example: REQUEST: client 123.1.1.1 -> firewall 10.0.1.1 -> F5 VIP 10.0.1.15 -> F5 SNAT 10.0.1.25 -> SRV 10.0.1.60 RESPONSE: 10.0.1.60 -> 10.0.1.25 -> 10.0.1.15 -> !!! 10.0.1.1 !!! -> 123.1.1.1 REQUEST: client 123.1.1.1 -> firewall 10.0.2.1 -> F5 VIP 10.0.2.15 -> F5 SNAT 10.0.2.25 -> SRV 10.0.2.60 RESPONSE: 10.0.2.60 -> 10.0.2.25 -> 10.0.2.15 -> !!! 10.0.2.1 !!! -> 123.1.1.1 Does the Auto Last Hop feature solves this 'source based routing' problem? If it does, do I still need anything else in F5 routing table, for example to reach the backend servers? Or can I leave the routing table empty (assuming F5 should be able to reach directly attached networks)? Thanks. Martin366Views0likes1CommentRouting application traffic through management interface
Hello all, I have a PoC setup in our lab with a management, internal and DMZ network and have a problem with routing. The F5 always sends the connection to the ADFS backend out from its DMZ interface, even though it's management interface is in the same subnet as the ADFS. MGMT: 10.x.250.0/24 DMZ: 10.x.251.128/25 Internal: 10.x.251.0/25 (not used here) I read this information which seems to suggest that application traffic must always be separate from management traffic, TMM handles the application traffic and the underlying linux handles the management traffic: https://clouddocs.f5.com/cli/tmsh-reference/latest/modules/sys/sys-management-route.html The management interface is available on all switch platforms and is designed for management purposes. You can access the browser-based Configuration utility and command line configuration utility through the management port. You cannot use the management interface in traffic management VLANs. So I understand from that that the MGMT is completely separate and I cannot make a routing hack to use the management interface for the ADFS application traffic. I can't change the location of the AD FS server. I could just open the firewall for the F5 connection from the DMZ to the management network but this is quite annoying as the F5 management and AD FS are directly connected on the same subnet. Is there anyway to instruct the F5 to use it's management interface 10.x.250.150 to contact the AD FS? Thanks, PeterSolved1.5KViews0likes2CommentsBIG-IP Version 9.3 routing - address translation problem
I am tring to setup traffic between two internal vlans (10.1.0.0 and 10.2.1.0). It works but the bigip is translating the source address to itself. Client (10.2.1.64): mysql -h 10.1.2.14 -u whatever -p Server (10.1.2.14): root@i-db0:~ netstat -an4 | grep 3306 | grep 10.1.2.14 tcp4 0 0 10.1.2.14.3306 10.1.1.240.37105 ESTABLISHED Bigip1 - self addresses 10.1.1.240 (floating) 10.1.1.241 and 10.2.1.240 (floating) and 10.2.1.241 Client - host address: 10.2.1.64/24, gateway set to 10.2.1.240 Server - host address: 10.1.2.200/16, gateway set to 10.1.1.240 traceroute to 10.1.2.14 (10.1.2.14), 64 hops max, 52 byte packets 1 bigip01-snat (10.2.1.241) 0.316 ms 0.189 ms 0.178 ms 2 i-db0 (10.1.2.14) 0.464 ms 0.443 ms 0.346 ms and back traceroute to 10.2.1.64 (10.2.1.64), 64 hops max, 52 byte packets 1 bigip1 (10.1.1.241) 0.228 ms 0.175 ms 0.153 ms 2 i-proxy1 (10.2.1.64) 0.454 ms 0.376 ms 0.305 ms Here is the bigip configuration: BIG-IP Version 9.3.1 81.1 self 10.1.1.240 { netmask 255.255.0.0 unit 1 floating enable vlan Default allow default } self 10.2.1.240 { netmask 255.255.255.0 unit 1 floating enable vlan Default allow default } I tried adding this and it didn't change anything. virtual vs-forward { destination 10.2.1.0:any ip forward ip protocol tcp mask 255.255.255.0 translate address disable translate service disable profile forward-fastl4 } Any help would be appreciated. Irwin179Views0likes0Commentsvirtual server on a different routing group
I'd like to use a different routing group to provide balanced web services on an internal VLAN that must not be routable from the normal Internet traffic. I'm Using BigIP 11.2.1 I'm not able to forward traffic to the backend servers. Here are my two test virtuals: ltm virtual VSVR_TESTROUTING { destination 192.168.200.102%1:http ip-protocol tcp mask 255.255.255.255 pool pool_courtesy_page profiles { http { } tcp { } } snat automap vlans-disabled } ltm virtual VSVR_TESTROUTING2 { destination 192.168.100.203:http ip-protocol tcp mask 255.255.255.255 pool pool_courtesy_page profiles { http { } tcp { } } snat automap vlans-disabled } The pool is correctly routed from routing group 0 (default) where it resides. Trying to access http://192.168.100.203/ works fine, while any access to http://192.168.200.202/ is reset just like when the pool members are not accessible. Of course the routing is OK, and if I attach to VSVR_TESTROUTING an iRule containing just a HTTP::respond 200 content {....}, the virtual correctly returns the given content. I did a tcpdump on both VLANs, there is no traffic at all related to failed accesses to VSVR_TESTROUTING, while succeeding accesses to VSVR_TESTROUTING2 are visible (SNAT-ed with the right self-ip) It really seems to refuse to forward the requests to the pool, and not simply forwarding the request to the wrong default gateway, but I don't understand why... Does this scenario ring a bell in anyone's ear? Thanks, Angelo.282Views0likes1CommentBIG-IQ device discovery issue - no route
Hi guys, trying to discover BIG-IP devices via a mgmt interface of the BIG-IQ and getting the "no route to host" error. I have only the mgmt interface on this big-iq VE with default mgmt route and specific mgmt route to the big-ip device. ping and trace work fine but 443 and 22 fail with "no route to host". [root@bigiq1:Active:Standalone] config tmsh list sys management-route sys management-route ccnet { description configured-statically gateway 10.10.10.1 mtu 1500 network 10.20.20.0/24 } sys management-route default { description configured-statically gateway 10.10.10.1 mtu 1500 network default } [root@bigiq1:Active:Standalone] config ping 10.20.20.130 PING 10.20.20.130 (10.20.20.130) 56(84) bytes of data. 64 bytes from 10.20.20.130: icmp_seq=1 ttl=54 time=1.09 ms 64 bytes from 10.20.20.130: icmp_seq=2 ttl=54 time=0.947 ms ^C --- 10.20.20.130 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1776ms rtt min/avg/max/mdev = 0.947/1.023/1.099/0.076 ms [root@bigiq1:Active:Standalone] config curl -k -v -X GET https://admin:admin@10.20.20.130/mgmt/shared/echo * About to connect() to 10.20.20.130 port 443 (0) * Trying 10.20.20.130... No route to host * couldn't connect to host * Closing connection 0 curl: (7) couldn't connect to host [root@bigiq1:Active:Standalone] config ssh 10.20.20.130 ssh: connect to host 10.20.20.130 port 22: No route to host Any advice will be appreciated. Mike438Views0likes0CommentsSelf IP in different subnet and VS and pool members are in same subnet then Self ip
Hi Team, I'm working on one of the installation where the requirement is that VS - e.g 10.10.10.X and pool members are in same subnet 10.10.10.X whereas F5 Self IPs will be in different subnet e.g 10.10.20.X and would like to understand how the routing will work for traffic hitting to VS (We need switch/router to point the route to F5 self IP e.g 10.10.20.1 for the subnet 10.10.10.X ) and from VS to pool members and return traffic from pool members to client. Can someone help?1.6KViews0likes5CommentsProblem when attempting to route between two route domains.
Hello, I have this scenario A front-end vlan (vlan_one), belonging to Route Domain #1 A back-end vlan (vlan_two), belonging to Route Domain #2 Some virtual servers in between, to balance traffic from the front-end users to the back-end servers. Now, some administrators behind a firewall connected to the front-end (vlan_one) need to reach the back-end servers directly. So that routing between Routing Domains #1 & #2 should be enabled. How can I perform the routing between both Route Domains? I disabled the "strict isolation" on both Route Domains, plus within the Route Domain #1 (Front-End) I set the Route Domain #2 (Back-End) as his parent Domain. But the routing does not seems to work. Do you think this is the right way to do that? Or did I left something? Regards in advance.395Views0likes2CommentsProblem when attempting to route between two route domains.
Hello, I have this scenario A front-end vlan (vlan_one), belonging to Route Domain #1 A back-end vlan (vlan_two), belonging to Route Domain #2 Some virtual servers in between, to balance traffic from the front-end users to the back-end servers. Now, some administrators behind a firewall connected to the front-end (vlan_one) need to reach the back-end servers directly. So that routing between Routing Domains #1 & #2 should be enabled. How can I perform the routing between both Route Domains? I disabled the "strict isolation" on both Route Domains, plus within the Route Domain #1 (Front-End) I set the Route Domain #2 (Back-End) as his parent Domain. But the routing does not seems to work. Do you think this is the right way to do that? Or did I left something? Regards in advance.428Views0likes2CommentsIs it possible to have a virtual local L3 loopback interface
Hi everyone, Is it possible to have a local virutal IP address similar to what cisco calls loopback interface ? I am trying to achieve a network topology as follows: [Internet]----[router]----subnetX-----[F5] The subnet between the router and F5 is a /30 RFC 1918 subnet used for routing. F5 has a Self IP 10.0.0.X/30 on this subnet and a default route pointing to 10.0.0.Y In F5 I have DNS service listening on a public IP, e.g 1.2.3.4. This IP is also configured as a Self IP 1.2.3.4/32. Incoming traffic is OK: traffic from internet is reaching 1.2.3.4 by the mean of a route configured on the router, and return traffic from F5 has 1.2.3.4 as a source IP. However, traffic originating from F5 is not working because its source IP is always 10.0.0.X, so packets get lost. I would like to source the outgoing traffic from 1.2.3.4. SNAT didn't help here. Also, when I test with a ping request and manually source the traffic from 1.2.3.4 using the -I argument, outbound traffic is OK. I would like to have this exact behavior for data traffic (iquery, monitoring ...etc). The customer has requirements to not use public IPs for interconnection links. Any help is appreciated400Views0likes0CommentsUnderstanding the BGP Peering details your CCNA didn't teach you
1 Quick Facts BGP usesTCP port 179 and is path vector protocol, rather than distance vector or link-state Keep-alive is 60s by default and Hold time is 180s Only hold time isnegotiatedin Open message Lowest hold time is used Routes are only installed in the routing table and advertised to peer is deemed valid (*) and best (>) For BGP to advertise a route using network command such route has to be in the routing table first BGP transport and route advertisement (known as NLRI in BGP) are independent Transport can use either IPv4 or IPv6 IPv6 NLRI can be advertised over an IPv4 BGP connection and vice-versa 2. The BGP peering for IPv4 BIG-IP establishes TCP connection on port 179 with peer and each one exchangeOPEN Message: Here's BIG-IP'sOPEN Message: Here's Cisco'sOPEN Message: Markeris always the same value and is just to signal the beginning of BGP message so don't worry about it. Lengthis just the total length of this BGP message Typecould be UPDATE (2), KEEPALIVE (4) but in this case it is an OPEN Message (1). Versionis always the same as this is BGPv4. My ASis the same because this is iBGP but if it was eBGP My AS on both sides would differ. Hold Timepicked value is the lowest one and this is negotiated. Since lowest value on BIG-IP's side is 90 seconds then both peers will send KEEPALIVE messages at 30 seconds interval. BGP Identifieris the bgp router-id that we typed in. Optional Parameters Lengthis the total length combined of all BGP extensions Optional Parametersare BGP extensions. At this point, if something goes wrong with peering, we should see BGP sending a NOTIFICATION message to terminate peering process: The above one was issued because I shutdown the neighbour relationship manually but other types of error would reveal a different message. In a running packet capture, we should see KEEPALIVE messages and corresponding TCP ACKs at agreed interval based on Hold Time: Other than that, UPDATE messages are also common and I will show them right now. 3. The UPDATE message for IPv4 It's kind of built-in. For IPv4 we will see Type 2 message (UPDATE) and the NLRI (routes). The 2 prefixes below share the same attributes and this is why they're grouped together: 4. The BGP peering for IPv6 It's the same thing as IPv4 but an additional capability is negotiated calledMultiprotocol extensions capabilitywithIPv6asAFIvalue: In case you never heard of AFI/SAFI here's what they mean: AFI (Address Family Indicator):This is the kind of route BGP is capable of handling, normally IPv4 or IPv6 but can also be VPNv4 for MP-BGP (out of scope here). SAFI (Subsequent Address Family Indicator): This is whether route is UNICAST or MULTICAST, normally UNICAST. If you ever configured BGP and typed in address-family commands then you've touched AFI/SAFI already. 5. BONUS! Carrying IPv4 prefixes over an IPv6 BGP connection (WHAT?) Yes, it's possible but next-hop of an IPv4 route is going to be IPv4 so make sure there is connectivity or create the relevant route-map. Notice that we're transporting BGP packets over IPv6 but routes advertised are IPv4 prefixes: You can also carry IPv6 prefixes over IPv4 if we do the other way round.1.2KViews1like11Comments