- Community Home
- >
- Networking
- >
- Legacy
- >
- Switches, Hubs, Modems
- >
- Procurve connection to redundant Juniper firewalls
-
-
Categories
- Topics
- Hybrid IT with Cloud
- Mobile & IoT
- IT for Data & Analytics
- Transformation
- Strategy and Technology
- Products
- Cloud
- Integrated Systems
- Networking
- Servers and Operating Systems
- Services
- Storage
- Company
- Events
- Partner Solutions and Certifications
- Welcome
- Welcome
- Announcements
- Tips and Tricks
- Feedback
-
Blogs
- Alliances
- Around the Storage Block
- Behind the scenes @ Labs
- Converged Data Center Infrastructure
- Digital Transformation
- Grounded in the Cloud
- HPE Careers
- HPE Storage Tech Insiders
- Infrastructure Insights
- Inspiring Progress
- Internet of Things (IoT)
- My Learning Certification
- Networking
- OEM Solutions
- Servers: The Right Compute
- Telecom IQ
- Transforming IT
-
Quick Links
- Community
- Getting Started
- FAQ
- Ranking Overview
- Rules of Participation
- Contact
- Email us
- Tell us what you think
- Information Libraries
- Integrated Systems
- Networking
- Servers
- Storage
- Other HPE Sites
- Support Center
- Enterprise.nxt
- Marketplace
- Aruba Airheads Community
-
Categories
-
Forums
-
Blogs
-
InformationEnglish
Procurve connection to redundant Juniper firewalls
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
12-11-2009 03:58 AM
12-11-2009 03:58 AM
Procurve connection to redundant Juniper firewalls
Procurve connection to redundant Juniper firewalls
Configuration is as follows;
Equipment:
fw0 - Juniper SSG firewall (primary)
fw1 - Juniper SSG firewall (secondary)
sw0 - Procurve 2510G-24 (STP enabled)
fw0 is connected to sw0/p24
fw1 is connected to sw0/p23
I suspect this might be due to the ARP cache on sw0. Hence, when I failover to fw1, sw0 still sends data destined for the gateway IP (virtual) down p24 (to inactive fw0) instead of p23 (to fw1).
Is there a recommended configuration for the procurve ports in this way?
I have looked at LACP and spanning-tree options, but am a little confused as to the best way to proceed. Initially, I tried to trunk ports 23 + 24, but many hosts were not contactable when I connected p23->fw1, which I suspect was due to sw0 sending some data down p23 and some down p24 whilst only one of the links should have been utilised at any one time.
Any help/advice/links will be gratefully received!
Nick
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
12-11-2009 04:31 AM
12-11-2009 04:31 AM
Re: Procurve connection to redundant Juniper firewalls
Re: Procurve connection to redundant Juniper firewalls
your problem doesn't refer to spanning-tree or trunking. I either think that the secondary firewall doesn't send a gratuitous ARP after a failover. Can you provide us a "show running-config" from you switch?
Best regards,
Patrick
Patrick
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
12-11-2009 04:43 AM
12-11-2009 04:43 AM
Re: Procurve connection to redundant Juniper firewalls
Re: Procurve connection to redundant Juniper firewalls
running-config as follows;
------------snip---------------
Running configuration:
; J9279A Configuration Editor; Created on release #Y.11.01
hostname "sw0"
web-management ssl
trunk 24 Trk1 Trunk
trunk 22 Trk2 Trunk
ip default-gateway xxx.xx.xx.129
snmp-server community "public" Unrestricted
vlan 1
name "DEFAULT_VLAN"
untagged 1-21,23,Trk1-Trk2
ip address x.x.x.176 255.255.255.192
exit
vlan 667
name "Management"
tagged Trk1
exit
vlan 666
name "DMZ"
exit
fault-finder bad-driver sensitivity high
fault-finder bad-transceiver sensitivity high
fault-finder bad-cable sensitivity high
fault-finder too-long-cable sensitivity high
fault-finder over-bandwidth sensitivity high
fault-finder broadcast-storm sensitivity high
fault-finder loss-of-link sensitivity high
fault-finder duplex-mismatch-HDx sensitivity high
fault-finder duplex-mismatch-FDx sensitivity high
spanning-tree
spanning-tree Trk1 priority 4
spanning-tree Trk2 priority 4
password manager
password operator
--------------snip-----------------
Thank you!! In the meantime, I will investigate whether the Juniper sends gratuitous ARP, although I have configured other networks in this way (albeit not with Procurves).
Best regards,
Nick
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
12-11-2009 04:50 AM
12-11-2009 04:50 AM
Re: Procurve connection to redundant Juniper firewalls
Re: Procurve connection to redundant Juniper firewalls
Our Junipers' cluster config is set to send 4 gratuitous ARPs (default).
Regards,
Nick
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
12-11-2009 09:23 AM
12-11-2009 09:23 AM
Re: Procurve connection to redundant Juniper firewalls
Re: Procurve connection to redundant Juniper firewalls
You should be able to check whether it's an arp issue by running a "show arp" on the 2510 after the firewalls have failed over.
Have you tried communicating (ping etc) from the backup SSG back to the host network after failover?
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
12-11-2009 09:34 AM
12-11-2009 09:34 AM
Re: Procurve connection to redundant Juniper firewalls
Re: Procurve connection to redundant Juniper firewalls
there is no need to configure the ports, to which the firewalls are connected, as "trunk". You should change this.
Check the ARP table on the switches after a failover. You can try to ping the firewall from the switch, after a failover. Does this solve the problem or can't you reach the firewall?
Best regards,
Patrick
Patrick
Hewlett Packard Enterprise International
- Communities
- HPE Blogs and Forum
© Copyright 2018 Hewlett Packard Enterprise Development LP