service chain RPF route issue

Bug #1769542 reported by ping
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Juniper Openstack
Status tracked in Trunk
R3.2
New
High
Sivakumar Ganapathy
R4.0
New
High
Raghunandan Srinivasan
R4.1
New
High
Raghunandan Srinivasan
R5.0
Incomplete
High
ping
Trunk
New
High
Raghunandan Srinivasan

Bug Description

## issue
version 3.2.8.

ATT noticed traffic from some VM does not reach the server after traversing
service chain (innetwork NAT) hosted by certain compute nodes. the RPF check at
the "right" interface towards the source failed (local tap not included) and
hence dropstats shows increasing "invalid source" counter. after
troubleshooting with ATT in bridge it turns out to be routing issue - the
forwarding entry towards the source does not have the tap interface included as
NH, and the reason seems to be the unexpected priority '100' , as opposed to
'200', which is the case for the working compute.

the issue was noticed at around April 6, ATT recovered the issue asap since it
is service impacting. JTAC collected logs and gcore.

## diagram

![image](https://user-images.githubusercontent.com/2038044/39323030-81705e14-4959-11e8-92fc-a169178a36b6.png)
![image](https://user-images.githubusercontent.com/2038044/39680840-24c722c0-5173-11e8-86a6-b6fdbc7f1620.png)

## logs/gcore collected

    pings@svl-jtac-lnx01:~/case/2018-0425-0642$ ls -lt
    total 1284120K
    -rw-r--r-- 1 jtac support 1279392280 Apr 27 07:38 alp1r24c005_gcore_dump #<----- gcore file
    -rw-r--r-- 1 jtac support 4305980 Apr 26 14:13 alp1r24c005_Junper_output.log #<---- troubleshooting logs, traces
    -rw-r--r-- 1 jtac support 3938 Apr 26 09:15 DCAE_issue_D2IPE_output.txt
    -rw-r--r-- 1 jtac support 6418575 Apr 25 14:16 alp1r24c005.alp1b.cci.att.com-var_log-contrail-20180425-2112.tgz
    -rw-r--r-- 1 jtac support 14365 Apr 25 14:03 alp1_DCAE_issue.txt
    -rw-r--r-- 1 jtac support 42038 Apr 25 14:01 ALP1B_issue_diagram.pptx #<--- diagram showing the issue
    -rw-r--r-- 1 jtac support 6359981 Apr 25 14:01 alp1r24c010._Working.log #<--- working compute logs
    -rw-r--r-- 1 jtac support 13130986 Apr 25 14:01 alp1r24c005_nonWorking.log #<--- nonworking compute log

Password of this below server is "Juniper"

    root@comp45:~/cases/2018-0425-0642# ls -lt
    total 1279060
    -rw-r--r-- 1 801 20062 1279392280 Apr 27 07:38 alp1r24c005_gcore_dump
    -rw-r--r-- 1 801 20062 4305980 Apr 26 14:13 alp1r24c005_Junper_output.log
    drwxr-xr-x 3 root root 4096 Apr 26 13:48 var
    -rw-rw-r-- 1 801 20062 63008 Apr 26 13:25 ist.py
    -rw-r--r-- 1 801 20062 3938 Apr 26 09:15 DCAE_issue_D2IPE_output.txt
    -rw-r--r-- 1 801 20062 6418575 Apr 25 14:16 alp1r24c005.alp1b.cci.att.com-var_log-contrail-20180425-2112.tgz
    -rw-r--r-- 1 801 20062 14365 Apr 25 14:03 alp1_DCAE_issue.txt
    -rw-r--r-- 1 801 20062 42038 Apr 25 14:01 ALP1B_issue_diagram.pptx
    -rw-r--r-- 1 801 20062 6359981 Apr 25 14:01 alp1r24c010._Working.log
    -rw-r--r-- 1 801 20062 13130986 Apr 25 14:01 alp1r24c005_nonWorking.log

## suggested recovery steps

* take gcore of vrouter agent (this kernel based) and upload to the case
* restart vrouter agent in the problematic compute #<------issue resolved in this step
* if issue not resolved, bounce the service chain static routes
    - remove
    - save
    - add
    - save

## suspicious flow entries

    bs1971@alp1r24c005:~$ sudo flow --match "107.239.223.197,32.131.196.51:162"
    Flow table(size 322174976, entries 2516992)

    Entries: Created 345930850 Added 345930719 Deleted 15433217 Changed 15436421 Processed 345930850 Used Overflow entries 0
    (Created Flows/CPU: 340725929 111891 696345 52661 175007 181387 54304 170693 183314 181680 180469 185709 840757 53312 52772 61569 55899 52093 53412 52993 53818 53260 55119 52516 464950 55791 56084 56638 62154 58043 54521 56337 823 1312 1085 1072 725131 0 0 0 0 0 0 0 0 0 0 0)(oflows 0)

    Action:F=Forward, D=Drop N=NAT(S=SNAT, D=DNAT, Ps=SPAT, Pd=DPAT, L=Link Local Port)
     Other:K(nh)=Key_Nexthop, S(nh)=RPF_Nexthop
     Flags:E=Evicted, Ec=Evict Candidate, N=New Flow, M=Modified Dm=Delete Marked
    TCP(r=reverse):S=SYN, F=FIN, R=RST, C=HalfClose, E=Established, D=Dead

    Listing flows matching ([107.239.223.197]:*, [32.131.196.51]:162)

        Index Source:Port/Destination:Port Proto(V)
        -------------------------------------------------------------------------------
       181892<=>854544 32.131.196.51:162 17 (17)
                             107.239.223.197:42724
    (Gen: 98, K(nh):523, Action:F, Flags:, QOS:-1, S(nh):497, Stats:0/0,
     SPort 52103, TTL 0, Sinfo 0.0.0.0)

       444724<=>1243828 32.131.196.51:162 17 (15->8)
                             107.239.223.197:42724
    (Gen: 115, K(nh):519, Action:F, Flags:, QOS:-1, S(nh):519, Stats:0/0,
     SPort 55495, TTL 0, Sinfo 0.0.0.0)

       854544<=>181892 107.239.223.197:42724 17 (17)
                             32.131.196.51:162
    (Gen: 182, K(nh):523, Action:F, Flags:, E:1, QOS:-1, S(nh):333, Stats:10/2210, #<------
     SPort 54236, TTL 0, Sinfo 11.0.0.0)

      1243828<=>444724 107.239.223.197:42724 17 (15->8)
            sudo 32.131.196.51:162
    (Gen: 255, K(nh):519, Action:F, Flags:, QOS:-1, S(nh):123, Stats:10/2070,
     SPort 58159, TTL 0, Sinfo 172.29.6.224)

NOTE:

* sourceIP: 107.239.223.197
* destination IP: 32.131.196.51
* V17 is right vrf MNS-25180-P-ALPHGA02:MNS-25180-P-ALPHGA02_oam_direct_net_1
* V15 is left vrf; MNS-25180-P-ALPHGA02:MNS-25180-P-ALPHGA02_oam_protected_net_1
* V8 is left service vrf; MNS-25180-P-ALPHGA02:MNS-25180-P-ALPHGA02_oam_protected_net_1:service
* 333 NH: to sourceIP
* 523 NH: to compute zalp1bfrwl01oam008

## S(nh) 333 -> source 107.239.223.197

in this NH resolution, local tap interface does not show up, which leads to the problem.

    bs1971@alp1r24c005:~$ sudo nh --get 333
    Id:333 Type:Composite Fmly: AF_INET Rid:0 Ref_cnt:257 Vrf:17
                  Flags:Valid, Ecmp,
                  Valid Hash Key Parameters: Proto,SrcIP,SrcPort,DstIp,DstPort
                  Sub NH(label): 217(24) 107(30) -1 157(24) -1 41(24) 99(37) -1

    Id:217 Type:Tunnel Fmly: AF_INET Rid:0 Ref_cnt:140 Vrf:0
                  Flags:Valid, MPLSoUDP,
                  Oif:0 Len:14 Flags Valid, MPLSoUDP, Data:00 1c 73 00 02 99 14 02 ec 67 fa cd 08 00
                  Vrf:0 Sip:172.29.6.227 Dip:172.29.7.169

    Id:107 Type:Tunnel Fmly: AF_INET Rid:0 Ref_cnt:149 Vrf:0
                  Flags:Valid, MPLSoUDP,
                  Oif:0 Len:14 Flags Valid, MPLSoUDP, Data:14 02 ec 68 3b bc 14 02 ec 67 fa cd 08 00
                  Vrf:0 Sip:172.29.6.227 Dip:172.29.6.230

    Id:157 Type:Tunnel Fmly: AF_INET Rid:0 Ref_cnt:102 Vrf:0
                  Flags:Valid, MPLSoUDP,
                  Oif:0 Len:14 Flags Valid, MPLSoUDP, Data:00 1c 73 00 02 99 14 02 ec 67 fa cd 08 00
                  Vrf:0 Sip:172.29.6.227 Dip:172.29.8.165

    Id:41 Type:Tunnel Fmly: AF_INET Rid:0 Ref_cnt:98 Vrf:0
                  Flags:Valid, MPLSoUDP,
                  Oif:0 Len:14 Flags Valid, MPLSoUDP, Data:00 1c 73 00 02 99 14 02 ec 67 fa cd 08 00
                  Vrf:0 Sip:172.29.6.227 Dip:172.29.6.174

    Id:99 Type:Tunnel Fmly: AF_INET Rid:0 Ref_cnt:149 Vrf:0
                  Flags:Valid, MPLSoUDP,
                  Oif:0 Len:14 Flags Valid, MPLSoUDP, Data:00 1c 73 00 02 99 14 02 ec 67 fa cd 08 00
                  Vrf:0 Sip:172.29.6.227 Dip:172.29.8.229

## static route configured for service chain

    107.239.220.0/22
    107.239.216.0/22
    107.239.216.0/21

### static route to 107.239.220.0/22: bad compute

the one pointing to local tap interface is with priority 100, which is the
problem.

    bs1971@alp1r24c005:~$ python ist.py vr route -v 17 -p 107.239.220.0/22
    107.239.220.0/22
        [172.29.6.39] pref:200
         via [], nh_index:333 , nh_type:ECMP Composite sub nh count: 8, nh_policy:disabled, active_label:-1, vxlan_id:0
        [172.29.6.101] pref:200
         via [], nh_index:798 , nh_type:ECMP Composite sub nh count: 8, nh_policy:disabled, active_label:-1, vxlan_id:0
        [LocalVmPort] pref:100 #<------
         to 2:49:c7:af:f5:b7 via tap49c7aff5-b7, assigned_label:41, nh_index:523 , nh_type:interface, nh_policy:enabled, active_label:41, vxlan_id:0

tap interface is missing in the composite NH pointing to source

    bs1971@alp1r24c005~$ sudo nh --get 333
    Id:333 Type:Composite Fmly: AF_INET Rid:0 Ref_cnt:257 Vrf:17
                  Flags:Valid, Ecmp,
                  Valid Hash Key Parameters: Proto,SrcIP,SrcPort,DstIp,DstPort
                  Sub NH(label): 217(24) 107(30) -1 157(24) -1 41(24) 99(37) -1

    Id:217 Type:Tunnel Fmly: AF_INET Rid:0 Ref_cnt:140 Vrf:0
                  Flags:Valid, MPLSoUDP,
                  Oif:0 Len:14 Flags Valid, MPLSoUDP, Data:00 1c 73 00 02 99 14 02 ec 67 fa cd 08 00
                  Vrf:0 Sip:172.29.6.227 Dip:172.29.7.169

    Id:107 Type:Tunnel Fmly: AF_INET Rid:0 Ref_cnt:149 Vrf:0
                  Flags:Valid, MPLSoUDP,
                  Oif:0 Len:14 Flags Valid, MPLSoUDP, Data:14 02 ec 68 3b bc 14 02 ec 67 fa cd 08 00
                  Vrf:0 Sip:172.29.6.227 Dip:172.29.6.230

    Id:157 Type:Tunnel Fmly: AF_INET Rid:0 Ref_cnt:102 Vrf:0
                  Flags:Valid, MPLSoUDP,
                  Oif:0 Len:14 Flags Valid, MPLSoUDP, Data:00 1c 73 00 02 99 14 02 ec 67 fa cd 08 00
                  Vrf:0 Sip:172.29.6.227 Dip:172.29.8.165

    Id:41 Type:Tunnel Fmly: AF_INET Rid:0 Ref_cnt:98 Vrf:0
                  Flags:Valid, MPLSoUDP,
                  Oif:0 Len:14 Flags Valid, MPLSoUDP, Data:00 1c 73 00 02 99 14 02 ec 67 fa cd 08 00
                  Vrf:0 Sip:172.29.6.227 Dip:172.29.6.174

    Id:99 Type:Tunnel Fmly: AF_INET Rid:0 Ref_cnt:149 Vrf:0
                  Flags:Valid, MPLSoUDP,
                  Oif:0 Len:14 Flags Valid, MPLSoUDP, Data:00 1c 73 00 02 99 14 02 ec 67 fa cd 08 00
                  Vrf:0 Sip:172.29.6.227 Dip:172.29.8.229

### static route to 107.239.220.0/22: working compute

    bs1971@alp1r24c005:~$ ist.py --host 172.29.6.174 vr route -v 3 -p 107.239.220.0/22
    Introspect Host: 172.29.6.174
    107.239.220.0/22
        [172.29.6.38] pref:200
         via ['tape1790263-cf'], nh_index:507 , nh_type:ECMP Composite sub nh count: 8, nh_policy:enabled, active_label:-1, vxlan_id:0
        [172.29.6.39] pref:200
         via ['tape1790263-cf'], nh_index:507 , nh_type:ECMP Composite sub nh count: 8, nh_policy:enabled, active_label:-1, vxlan_id:0
        [LocalVmPort] pref:200 #<------
         to 2:e1:79:2:63:cf via tape1790263-cf, assigned_label:24, nh_index:136 , nh_type:interface, nh_policy:enabled, active_label:24, vxlan_id:0

## tap interface details

the tap interface does has the configured 3 static routes

    bs1971@alp1r24c005:~$ ist vr intf tap49c -d
    ItfSandeshData
      index: 11
      name: tap49c7aff5-b7
      uuid: 49c7aff5-b753-4cc8-a5bf-fefc8b5cc825
      vrf_name: default-domain:MNS-25180-P-ALPHGA02:MNS-25180-P-ALPHGA02_oam_direct_net_1:MNS-25180-P-ALPHGA02_oam_direct_net_1
      active: Active
      ipv4_active: Active
      l2_active: L2 Active
      ip6_active: Active
      health_check_active: Active
      dhcp_service: Enable
      dns_service: Enable
      type: vport
      label: 41
      l2_label: 42
      vxlan_id: 83
      vn_name: default-domain:MNS-25180-P-ALPHGA02:MNS-25180-P-ALPHGA02_oam_direct_net_1
      vm_uuid: 30b0112e-9092-4af1-bfb0-98f9fd2f8cbd
      vm_name: zalp1bfrwl01oam008
      ip_addr: 107.239.238.15
      mac_addr: 02:49:c7:af:f5:b7
      policy: Enable
      fip_list
      mdata_ip_addr: 169.254.0.11
      service_vlan_list
      os_ifindex: 33
      fabric_port: NotFabricPort
      alloc_linklocal_ip: LL-Enable
      analyzer_name
      config_name: default-domain:MNS-25180-P-ALPHGA02:zalp1bfrwl01oam008_vmi_2
      sg_uuid_list
          VmIntfSgUuid
            sg_uuid: a9a4e8e9-f45d-4e3b-913a-4890695250e5
      static_route_list
          StaticRouteSandesh
            vrf_name: default-domain:MNS-25180-P-ALPHGA02:MNS-25180-P-ALPHGA02_oam_direct_net_1:MNS-25180-P-ALPHGA02_oam_direct_net_1
            ip_addr: 107.239.216.0 #<------
            prefix: 21
            communities
          StaticRouteSandesh
            vrf_name: default-domain:MNS-25180-P-ALPHGA02:MNS-25180-P-ALPHGA02_oam_direct_net_1:MNS-25180-P-ALPHGA02_oam_direct_net_1
            ip_addr: 107.239.216.0 #<------
            prefix: 22
            communities
          StaticRouteSandesh
            vrf_name: default-domain:MNS-25180-P-ALPHGA02:MNS-25180-P-ALPHGA02_oam_direct_net_1:MNS-25180-P-ALPHGA02_oam_direct_net_1
            ip_addr: 107.239.220.0 #<------
            prefix: 22
            communities
          StaticRouteSandesh
            vrf_name: default-domain:MNS-25180-P-ALPHGA02:MNS-25180-P-ALPHGA02_oam_direct_net_1:MNS-25180-P-ALPHGA02_oam_direct_net_1
            ip_addr: 2600:308:160:201::
            prefix: 64
            communities
      vm_project_uuid: 367f0f9a-4b62-42e2-bba1-9c8b7aea617d
      admin_state: Enabled
      flow_key_idx: 523
      allowed_address_pair_list
      ip6_addr: 2600:308:160:202::8
      local_preference: 0
      tx_vlan_id: -1
      rx_vlan_id: -1
      parent_interface
      subnet: --NA--
      sub_type: Tap
      vrf_assign_acl_uuid: --NA--
      vmi_type: Virtual Machine
      transport: Ethernet
      logical_interface_uuid: 00000000-0000-0000-0000-000000000000
      flood_unknown_unicast: false
      physical_device
      physical_interface
      fixed_ip4_list
          107.239.238.8 #<------
          107.239.238.15 #<------
      fixed_ip6_list
          2600:308:160:202::3
          2600:308:160:202::8
      fat_flow_list
      metadata_ip_active: Active
      service_health_check_ip: 0.0.0.0
      alias_ip_list
      drop_new_flows: false

### route toward the first fixedIP

route toward the first fixed IP does has all 8 NHs, reprenting 8 computes hosting
the 8 FWs, including self:

    172.29.6.174
    172.29.6.230
    172.29.7.169
    172.29.7.170
    172.29.8.165
    172.29.8.229
    172.29.6.174
    172.29.6.227 (self)

    python ist.py vr route -v 17 -p 107.239.238.8/32
    107.239.238.8/32
        [172.29.6.39] pref:200
         via ['tap49c7aff5-b7'], nh_index:304 , nh_type:ECMP Composite sub nh count: 8, nh_policy:enabled, active_label:-1, vxlan_id:0
        [172.29.6.101] pref:200
         via ['tap49c7aff5-b7'], nh_index:292 , nh_type:ECMP Composite sub nh count: 8, nh_policy:enabled, active_label:-1, vxlan_id:0
        [LocalVmPort] pref:200
         to 2:49:c7:af:f5:b7 via tap49c7aff5-b7, assigned_label:41, nh_index:523 , nh_type:interface, nh_policy:enabled, active_label:41, vxlan_id:0
        [INET-EVPN] pref:100
         nh_index:0 , nh_type:None, nh_policy:, active_label:-1, vxlan_id:0

    bs1971@alp1r24c005:~$ nh --get 304
    Id:304 Type:Composite Fmly: AF_INET Rid:0 Ref_cnt:2 Vrf:17
                  Flags:Valid, Policy, Ecmp,
                  Valid Hash Key Parameters: Proto,SrcIP,SrcPort,DstIp,DstPort
                  Sub NH(label): 41(24) 107(30) 170(46) 217(24) 60(24) 157(24) 99(37) 525(41)

    Id:41 Type:Tunnel Fmly: AF_INET Rid:0 Ref_cnt:98 Vrf:0
                  Flags:Valid, MPLSoUDP,
                  Oif:0 Len:14 Flags Valid, MPLSoUDP, Data:00 1c 73 00 02 99 14 02 ec 67 fa cd 08 00
                  Vrf:0 Sip:172.29.6.227 Dip:172.29.6.174

    Id:107 Type:Tunnel Fmly: AF_INET Rid:0 Ref_cnt:149 Vrf:0
                  Flags:Valid, MPLSoUDP,
                  Oif:0 Len:14 Flags Valid, MPLSoUDP, Data:14 02 ec 68 3b bc 14 02 ec 67 fa cd 08 00
                  Vrf:0 Sip:172.29.6.227 Dip:172.29.6.230

    Id:170 Type:Tunnel Fmly: AF_INET Rid:0 Ref_cnt:128 Vrf:0
                  Flags:Valid, MPLSoUDP,
                  Oif:0 Len:14 Flags Valid, MPLSoUDP, Data:00 1c 73 00 02 99 14 02 ec 67 fa cd 08 00
                  Vrf:0 Sip:172.29.6.227 Dip:172.29.8.224

    Id:217 Type:Tunnel Fmly: AF_INET Rid:0 Ref_cnt:140 Vrf:0
                  Flags:Valid, MPLSoUDP,
                  Oif:0 Len:14 Flags Valid, MPLSoUDP, Data:00 1c 73 00 02 99 14 02 ec 67 fa cd 08 00
                  Vrf:0 Sip:172.29.6.227 Dip:172.29.7.169

    Id:60 Type:Tunnel Fmly: AF_INET Rid:0 Ref_cnt:50 Vrf:0
                  Flags:Valid, MPLSoUDP,
                  Oif:0 Len:14 Flags Valid, MPLSoUDP, Data:00 1c 73 00 02 99 14 02 ec 67 fa cd 08 00
                  Vrf:0 Sip:172.29.6.227 Dip:172.29.7.170

    Id:157 Type:Tunnel Fmly: AF_INET Rid:0 Ref_cnt:102 Vrf:0
                  Flags:Valid, MPLSoUDP,
                  Oif:0 Len:14 Flags Valid, MPLSoUDP, Data:00 1c 73 00 02 99 14 02 ec 67 fa cd 08 00
                  Vrf:0 Sip:172.29.6.227 Dip:172.29.8.165

    Id:99 Type:Tunnel Fmly: AF_INET Rid:0 Ref_cnt:149 Vrf:0
                  Flags:Valid, MPLSoUDP,
                  Oif:0 Len:14 Flags Valid, MPLSoUDP, Data:00 1c 73 00 02 99 14 02 ec 67 fa cd 08 00
                  Vrf:0 Sip:172.29.6.227 Dip:172.29.8.229

    Id:525 Type:Encap Fmly: AF_INET Rid:0 Ref_cnt:9 Vrf:17
                  Flags:Valid,
                  EncapFmly:0806 Oif:11 Len:14
                  Encap Data: 02 49 c7 af f5 b7 00 00 5e 00 01 00 08 00

Jim Reilly (jpreilly)
information type: Proprietary → Public
Revision history for this message
Mahesh Sivakumar (maheshmns) wrote :

The problem is probably due to the path in the agent not updated with the correct preference. Someone from the agent side will be taking a look at this issue.

Thanks
Mahesh

Revision history for this message
Ananth Suryanarayana (anantha-l) wrote :

Hi Raghu,

Can you please have some one from the agent team to triage this route preference issue.

Thanks
Regards

Revision history for this message
Sivakumar Ganapathy (hotlava51) wrote :

Summary of discussions with Jeba

===========

From: Jeba Paulaiyan <email address hidden>
Date: Wednesday, 1 August 2018 at 10:30 PM
To: Vineet Gupta <email address hidden>, Sivakumar Ganapathy <email address hidden>
Subject: Re: Clarification on 5.0.1 Bugs

1633387 – W.r.t. Ubuntu, we need to make sure vrouter.ko is DKMS compatible against any kernel. When 4.x kernel came to market long back, we observed that vrouter does not DKMS compile against that kernel and the bug was filed. However at that time our customers were in 3.x kernels. Recently there are use-cases forced us to fix this and as per my understanding, this is fixed by the commits made already. We will keep it in 5.0.2 scope and close it after assessing all use-case. Mainly AWS, Azure, GCP, vR-vR encryption needs latest kernels.

1769542 – We can move to 5.0.2. However, this need to be worked on for 3.2.12.0 release targeted for Sep end. If possible code complete by End of Aug. Based on the root cause and fix, we need to post the changes to higher branches.

Thanks,
Jeba

From: VineetJnpr Gupta <email address hidden>
Date: Wednesday, August 1, 2018 at 08:52
To: Sivakumar Ganapathy <email address hidden>, Jeba Paulaiyan <email address hidden>
Subject: Re: Clarification on 5.0.1 Bugs

+ Jeba

Hi Jeba,

Can you please comment on these?

Regards,
Vineet Gupta
Engineering Program Manager | Contrail Engineering
m: (202) 600-5234 e: <email address hidden>

From: Sivakumar Ganapathy <email address hidden>
Date: Wednesday, August 1, 2018 at 3:28 AM
To: Vineet Gupta <email address hidden>
Subject: Clarification on 5.0.1 Bugs

Vineet,
I see the following in the 5.0.1 list and not sure why it is critical for 5.0.1. Can you clarify?

1. 1633387 ---- This bug is a compilation issue and almost 2 years old. Why has this been assigned a 5.0.1 scope recently?

2. 1769542 ---- It is open since 3.2. I do realize that this is a customer issue but given the short runway for 5.0.1 and low impact I want to move it to 5.1.0. Ok with you?

===========

Revision history for this message
Kumar Harsh (hkumar) wrote :

not able to access root@comp45 where core files are saved

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.