Support Support Downloads Knowledge Base Case Manager My Juniper Community

Knowledge Base

Search our Knowledge Base sites to find answers to your questions.

Ask All Knowledge Base Sites All Knowledge Base Sites JunosE Defect (KA)Knowledge BaseSecurity AdvisoriesTechnical BulletinsTechnotes Sign in to display secure content and recently viewed articles

[ScreenOS] Unable to manage Backup firewall even with 'set flow mac-cache mgt' from remote subnet

0

0

Article ID: KB21398 KB Last Updated: 06 Sep 2013Version: 3.0
Summary:
Customer is unable to manage backup device running on ScreenOS 6.2 from a single remote subnet even though he has configured ‘set flow mac-cache mgt’ command on the device.
Symptoms:
A customer is unable to manage the backup firewall from a remote subnet 10.10.10.15/32, through manage IP assigned to E1/1. The command ‘set flow mac-cache mgt’ was configured on the backup.Traffic is hitting the interface E1/1, however the reverse route is pointing to E1/2, which is inactive.

Example command and debug output:


get interface
Name       IP Address             Zone
   mgt     192.168.1.1/24         MGT
eth1/1     172.27.201.193/24      Untrust
eth1/2     10.10.10.10/24         Trust

Routing Table :
  ID         IP-Prefix        Interface  Gateway       P      Pref  Mtr   Vsys
   7      10.10.10.10/32      eth1/2     0.0.0.0       H      0     0     Root
 * 2      192.168.1.1/32      mgt        0.0.0.0       H      0     0     Root
   8      172.27.199.15/32    eth1/2     172.27.201.1  S      20    1     Root
 * 3      172.27.201.0/24     eth1/1     0.0.0.0       C      0     0     Root
* 1       192.168.1.0/24      mgt        0.0.0.0       C      0     0     Root
   4      172.27.201.193/32   eth1/1     0.0.0.0       H      0     0     Root
   6      10.10.10.0/24       eth1/2     0.0.0.0       C      0     0     Root
get nsrp
group priority preempt holddown inelig       master            PB          other members myself uptime
    0       100          no           3               no       10523776     myself              00:15:41
total number of vsd groups: 1
Total iteration=945,time=1811211,max=389190,min=1054,average=1916
RTO mirror info:
run time object sync: disabled
route synchronization: disabled
ping session sync: enabled
coldstart sync done
nsrp data packet forwarding is disabled


In the debug, it is noticed that the firewall is caching the route; however a reply packet is not generated.
**st: <Untrust|ethernet1/1|Root|0> 4814cc0: 3d1d:10.10.10.15/200->10.10.10.194/4a0a,1,60
01387.0: ethernet1/1(i) len=74:00101863902a->002283a0aa87/0800
10.10.10.15 -> 10.10.10.194/1
vhl=45, tos=00, id=15645, frag=0000, ttl=127 tlen=60
icmp:type=8, code=0

****** 01387.0: <Untrust/ethernet1/1> packet received [60]******
ipid = 15645(3d1d), @04814cc0
packet passed sanity check.
flow_decap_vector IPv4 process
ethernet1/1:10.10.10.15/18954->10.10.10.194/512,1(8/0)<Root>
no session found
flow_first_sanity_check: in <ethernet1/1>, out <N/A>
existing vector list 20-2884c6a4.
create a self session (flag 0x206), timeout=60sec.
flow_first_install_session======>
handle cleartext reverse route
search route to (self, 10.10.10.194->10.10.10.15) in vr trust-vr for vsd-0/flag-3000/ifp-ethernet1/1
cached route 0 for 10.10.10.15
no route to (0.0.0.0->10.10.10.15) in vr trust-vr/0
ifp2 ethernet1/1, out_ifp ethernet1/1, flag 00000601, tunnel ffffffff, rc 0
cache src mac in session for reverse direction
flow got session.
flow session id 524274
flow_main_body_vector in ifp ethernet1/1 out ifp N/A
flow vector index 0x20, vector addr 0x2884c6a4, orig vector 0x2884c6a4
post addr xlation: 10.10.10.15->10.10.10.194.
packet is for self, copy packet to self
copy packet to us.

Solution:
For the ‘set flow mac-cache mgt’ command to work, an active route for the source subnet (doesn’t matter to which interface it is pointing), is required because the reply packet is handled by kernel protocol stack at first and in current implementation, the kernel protocol stack does not care about the status of 'set flow mac-cache mgt'.
The kernel always looks up the route table. If kernel cannot find an active route, the packet is dropped. There must be an active route for the source subnet, although it is not necessary to use the interface specified in this route, as the outgoing interface for the reply traffic.

As per KB13985 - After upgrade to ScreenOS 6.2.0, the VSI state of a backup device changes from Inactive to Down. Why?, in ScreenOS 6.2 or later, if NSRP data forwarding is disabled and there is no manage IP on the interface, then the route linked to that interface is shown as down. In this case as the route for source subnet is pointing to E1/2 and there was no manage-ip configured on that interface, it is shown as down. After configuring a manage-ip on E1/2, the route becomes active and backup device is accessible from that source subnet.
Comment on this article > Affected Products Browse the Knowledge Base for more articles related to these product categories. Select a category to begin.

Getting Up and Running with Junos

Getting Up and Running with Junos Security Alerts and Vulnerabilities Product Alerts and Software Release Notices Problem Report (PR) Search Tool EOL Notices and Bulletins JTAC User Guide Customer Care User Guide Pathfinder SRX High Availability Configurator SRX VPN Configurator Training Courses and Videos End User Licence Agreement Global Search